Acquiring Resources

What Good Acquisition Looks Like From the Outside

A project team that moves fast, communicates naturally, and solves problems before they escalate looks effortless from the outside. It is not. That kind of performance is the result of deliberate choices made early: who is on the team, what gaps they fill, and whether the people placed together can function as more than a collection of individual contributors. Many of the decisions that produce it happen before the work ramps up, and others happen repeatedly as new needs, gaps, and constraints surface during execution. The decisions that undermine it are usually visible only in hindsight: a critical role filled too late, a skill gap nobody noticed until it became a missed deliverable, a resource assumed available that was not.

Resources Are More Than People

When project managers talk about acquiring resources, the conversation almost always jumps straight to headcount: who is on the team, what skills they have, when they are available. That pull is understandable. People are the most unpredictable resource and the area where PM effort has the most influence on outcomes. But the project also needs materials, equipment, facilities, and tools, and failing to acquire those properly costs as much as getting the staffing wrong. A project that fails because critical materials arrived three weeks late, after the installation crew has already been paid to wait, got its resource planning wrong regardless of how well the team was selected.

For materials and equipment, the acquisition decision comes down to three options: buy, rent, or borrow. The right choice depends on cost, utilization, and something project managers frequently underweight: sustainment. If you are implementing an assembly line with specialized welding equipment, and that equipment will be used to maintain the line long after the project closes, the client may want to purchase it. The ownership cost is justified by the operational life ahead. If you are in construction and need an excavator for two weeks during site prep, ownership rarely makes sense. The equipment plays a short role, sits idle between projects, requires a dedicated operator and a maintenance program, and the cost-of-ownership calculation almost always points toward renting. These decisions are more predictable than staffing decisions because they are largely mathematical. Run the numbers, factor in what happens after the project closes, and the answer usually becomes clear.

Facilities are a third category that gets overlooked. A project may need temporary office space, a testing lab, a staging area, or access to specialized facilities for part of the work. Securing that access early, as part of resource planning rather than as an afterthought during execution, prevents the kind of mid-project scramble where the team is ready to work and the space is not available. Map all resource types against the schedule: people, materials, equipment, and facilities. The gaps that surface on paper are far cheaper to close than the gaps that surface in execution.

Sustainment — The Longer View

A project, by definition, has a beginning and an end. What comes after the end is the sustainment period: the operational life of the deliverable from project close to end of life. The cost of maintaining that outcome over time is the cost of ownership, and decisions made during acquisition directly affect how large or small that cost becomes. This is not an abstract concern. A system that requires a specialized contractor to service it indefinitely is a different operational burden than one maintained by trained internal staff. A piece of equipment purchased without a maintenance plan becomes a cost center the sponsor did not anticipate. Sustainment belongs in the resource conversation, not just in the handover documentation.

Sustainment changes how you think about staffing. A task performed once during the project and never again afterward is a strong candidate for a contracted resource. A task that will continue after project close, maintaining a system, supporting a deliverable, training end users, managing an ongoing process, is better suited to internal staff whose participation builds the organizational knowledge the sponsor needs to sustain the outcome. A contractor delivers, leaves, and takes their knowledge with them. An internal resource delivers, stays, and becomes part of the operational capability the project was always meant to create. Sometimes the right answer is a hybrid: bring a contractor in to do the specialized work, with an internal resource working alongside them throughout, specifically to absorb the knowledge transfer in real time.

Raising sustainment considerations during resource acquisition is one of the more visible demonstrations of a PM's strategic value. Most resource decisions get made on short-term availability and cost. Sponsors who are used to working with PMs who think that way notice when someone frames the decision around long-term operational impact. The question is not complicated. Not just who can do this work now, but who should own this capability after we are done? That shift in framing is what separates a plan that is easy to justify in the moment from one that actually serves the organization's interests over time.

The Math Comes First

Before thinking about team chemistry or personality fit, do the math. For each role the project requires, three questions need clear answers: what skills does this role demand, can those skills be sourced internally or does the project need to go external, and how much of that person's time does the project actually need? A resource required for two weeks at 50 percent availability is a different planning problem from one needed full-time for six months. The schedule built during planning is the guide. Map the resource requirements against it before negotiating availability with anyone, because the conversation changes significantly when you can show a specific week-by-week demand profile rather than a loose estimate of how much time someone might be needed.

Availability, Scheduling, and the Resource Calendar

Once you know who and what you need, the next question is when. Availability is not a binary. A team member may be 50 percent available for two weeks, then 100 percent for three weeks, then pulling back as a competing project ramps up. An equipment vendor may have a delivery window that does not align with your installation date. A facility may be accessible only during specific hours. Each of these constraints needs to be reflected in a resource calendar: the schedule-level record of when each resource is actually available to the project. Skipping this step and assuming availability is one of the most predictable ways to build a schedule that looks reasonable in planning and fails immediately in execution.

Building a resource calendar means capturing public holidays and organizational blackout dates, individual vacation plans and confirmed absences, percentage allocation for shared or part-time resources, and vendor or equipment delivery and availability windows. Project scheduling tools let you enter this information directly and surface conflicts before they become timeline problems. For smaller projects, a shared spreadsheet works just as well. What matters is that availability information is visible and reflected in the schedule, not assumed. A schedule built on optimistic availability assumptions that then encounters a two-week absence, a backordered material, or a reprioritized shared resource is a schedule that was always going to fail. The resource calendar is where you catch those conflicts in planning rather than as surprises in execution.

Who Can You Actually Work With

Resource acquisition does not happen in isolation. The PM rarely has free authority to choose any resource from any source without constraint. HR processes govern internal assignments, procurement policy governs external contracts, and in unionized environments, collective agreements determine which work is performed by which labor pool. Ignoring those constraints creates organizational conflict that typically costs the project more than the effort spent understanding them upfront would have.

In unionized environments, some work is reserved for specific labor classifications. The PM cannot simply assign a non-union contractor to tasks that fall within a union's bargaining unit without creating a grievance. Work with your sponsor and organizational HR early in execution to clarify which roles are governed by which agreements. This is standard operating reality in many sectors: construction, manufacturing, utilities, and healthcare. Experienced PMs account for it in the schedule and the resource plan rather than treating it as a surprise when it surfaces mid-project.

Some organizations offer internal service arrangements where a department provides staff for project work as a shared service. These can be useful when the skill set is standard and the internal resource brings organizational knowledge a contractor would not have. The downside is prioritization pressure: the same person may be shared across multiple projects or commitments, and their availability is less reliable than a dedicated external resource. Build that uncertainty into your schedule. Available does not mean dedicated, and a schedule that treats shared resources as guaranteed will need to be revised the first time a competing priority takes precedence.

Safety in the Project Environment

Most permanent workplaces have established safety systems: trained staff, defined protocols, committees, and physical environments configured for the work being done. A project environment is different. It is often a temporary, non-standard configuration of people, equipment, and activities in a space not originally designed for what the project is doing. The gap between the organization's permanent safety systems and the project's actual working conditions is a real risk that many office-based PMs underestimate because the work looks familiar.

In industrial, construction, and medical projects, safety planning is non-negotiable and often legally required. In environments with regulated work, organizations maintain formal safety bodies, such as a Joint Health and Safety Committee, that have defined authority and involvement requirements for non-routine work. The PM needs to know whether the project work triggers that involvement and engage proactively rather than treating safety oversight as a bureaucratic step to clear. Even in projects that appear routine, the configuration of resources in a project environment creates hazards that would not exist in the permanent workspace: staging areas, temporary equipment, changed egress paths, and workers unfamiliar with the site.

Before work starts, confirm what safety training is required, what site access credentials are needed, what personal protective equipment applies, and what permits the work requires. Work with your customer's safety staff proactively. A PM who handles safety compliance early avoids the kind of incident that stops a project and damages careers. It is not a checkbox. It is a real protection for the people doing the work.

Lead Time Is a Schedule Risk

Every time a role is filled externally, lead time is involved. In government organizations, procurement for a contract resource can take months. Even in the private sector, sourcing, evaluating, and onboarding someone takes weeks. The trap is treating that lead time as a detail to resolve later, after the role has been confirmed. Front-load the decision. As soon as a role is confirmed as external, involve procurement or HR and establish exactly how long the full process takes. A schedule that assumes a resource will be available the week they are needed, when the actual lead time is six weeks, is a schedule that will fail before execution properly begins. The same logic applies to materials and equipment with long delivery windows: the moment a requirement is confirmed, the procurement clock should already be running. Lead time belongs in the schedule as a planned activity, not as an assumption buried in a note.

Know the Team You Have Before You Build the Team You Need

Before acquiring anyone new, take stock of what is already in place. Every team has patterns: people who drive urgency, people who validate carefully before they act, people who flag risk early, people who push to ship and handle consequences as they arrive. A common staffing mistake is hiring by technical need alone. A developer is needed, so the search is for development skills and stops there. But if the existing team is already execution-heavy and communication-light, the actual gap may be someone who can translate the work between the technical team and the stakeholders, not another builder. Knowing what the team already has tells you what gap to fill, and that gap is almost never purely technical.

Diversity and Synergy

Once the technical decisions are behind you, there is still one more dimension worth considering: the composition of the team as a whole. A technically complete but compositionally uniform team misses real value. Diversity in experience level, professional background, problem-solving approach, and communication style gives teams the ability to see problems from more than one angle and find solutions a more uniform group would not reach. This is not a theoretical observation. A team member who has worked in a different industry brings a different mental model for how problems get solved. A team member newer to the field asks questions that the experienced members stopped asking years ago. Both of those are assets, and a team built exclusively from one profile loses both.

When reviewing candidates for project roles, go beyond the skills checklist. Ask how they have worked in teams that did not think like them. Ask what they do when they are the only person in the room who sees a problem differently from everyone else. The answers tell you about adaptability, confidence, and the ability to work with people whose instincts differ from their own. Those secondary qualities show up when it matters most: in the difficult moments where the path forward is not obvious and the team needs to think its way through rather than follow a playbook it already knows.

Two Modes of Thinking — Both Required

Acquiring a team well requires two modes of thinking that most people find uncomfortable to hold at the same time. The first is clinical: a precise accounting of skill requirements, availability percentages, budget implications, and schedule alignment. The second is human: an honest assessment of character, energy, reliability under pressure, and how a candidate will actually function with the specific people already on this team. Neither mode is enough on its own. A paper-perfect team on a skills matrix can still fail to work together. A team assembled entirely on instinct will miss critical skill gaps. The PM needs both, and learning to move between them without losing either is one of the harder disciplines in resource acquisition.

What the Interview Is Actually For

When evaluating candidates for project roles, look past the resume and the primary technical skill. Ask how they have handled ambiguity on a previous project. Ask what they do when they disagree with a teammate: do they raise it, or do they avoid it and work around the person? Ask them to describe a time they delivered bad news to someone with more authority. The answers reveal secondary skills: communication under pressure, resilience when things go wrong, and the self-awareness to know when they need help. Those predict project performance more reliably than certifications do. The clinical assessment tells you whether a person can do the job. The human assessment tells you whether they will.

What's Next

The next chapter, Developing Your Team, picks up from the moment the team is assembled and addresses what happens next: building the conditions where people perform at their best, establishing how the team works together through a team charter, and creating an environment that sustains that performance across the full length of the project.

Reflect

• In your current or most recent project, how was the internal-versus-contract decision made for each role? Was sustainment part of the conversation, or was the decision made on availability and cost alone?
• When did you last build an explicit resource calendar that captured holidays, vacations, percentage allocation, and equipment delivery windows? What conflicts or gaps did it reveal that assumptions would have missed?
• Have you worked in an environment with union agreements, shared service constraints, or strict procurement rules? How did those constraints change the resource acquisition process, and how early did you know about them?
• Where in a recent project did resource lead time create a schedule problem? What would have changed if procurement had started six weeks earlier?
• Before your last hiring or contracting decision, did you take stock of the patterns already present in the team? What gap were you actually filling, and was it the same gap you thought you were filling?
• Think of a time you evaluated someone primarily on technical skills and were later surprised by their performance. What secondary skill were you missing in your assessment, and how would you look for it now?