Resource Planning and Allocation for Projects

The Resource Planning Challenge

Every project competes for the same finite pool of skilled people. The PM's job is to: 1. Identify what skills and capacity the project needs 2. Secure commitments from resource owners (line managers, other PMs) 3. Plan utilisation realistically (not at 100%) 4. Manage conflicts when multiple projects need the same people 5. Adapt when reality diverges from the plan (it always does)

Building the Resource Plan

Step 1: Define Resource Requirements

For each project phase, identify:

• Roles needed: What skills are required? (Frontend developer, QA engineer, UX designer, DBA, etc.)
• Quantity: How many of each role?
• Duration: When are they needed and for how long?
• Allocation: Full-time (100%) or part-time (specify %)
• Criticality: Which roles are on the critical path? (Delay in securing them delays the project)

Step 2: Map to Available People

Work with resource owners to identify specific individuals:

• Who has the required skills?
• Who is available during the required period?
• What other commitments do they have?
• Are there single points of failure (only one person with a critical skill)?

Step 3: Negotiate and Confirm

Resource allocation is a negotiation. You rarely get exactly what you want. Strategies:

• Start early: Request resources 4-6 weeks before you need them. Last-minute requests get last-priority treatment.
• Be specific: "I need a senior Java developer with payment system experience for 12 weeks starting March 1" is better than "I need some developers."
• Offer flexibility: "I need them full-time for weeks 1-4, then 50% for weeks 5-12" is easier to accommodate than "full-time for 12 weeks."
• Escalate with data: If you can't get what you need, escalate with impact: "Without a DBA, the migration phase slips by 4 weeks, pushing the release from June to July."

Step 4: Plan for Reality

No resource plan survives contact with reality. Build in buffers:

• Availability buffer: People are never 100% available. Plan for 80% (meetings, support, admin consume the rest).
• Ramp-up time: New team members need 2-4 weeks to become productive. Don't plan full output from day one.
• Attrition risk: Key people may leave, get sick, or be pulled to higher-priority work. Identify backup options for critical roles.
• Skill development: If someone needs to learn a new technology, factor in learning time.

Managing Resource Conflicts

When multiple projects need the same person:

The Priority Conversation

Escalate to the portfolio level: "Projects A and B both need [person] full-time in March. Which project takes priority?" This is a portfolio decision, not a PM decision.

The Splitting Approach

Part-time allocation across projects. Works for:

• Advisory roles (architect reviewing designs for multiple projects)
• Specialist skills needed intermittently (DBA for schema changes, security reviewer)
• Stable, low-intensity phases (maintenance, monitoring)

Doesn't work for:

• Core development roles (context switching kills productivity)
• Critical path work (split attention = delayed delivery)
• Complex problem-solving (needs sustained focus)

The Sequencing Approach

If both projects can't have the person simultaneously, sequence the work:

• Project A gets them for weeks 1-6
• Project B gets them for weeks 7-12
• Adjust project timelines accordingly

Resource Utilisation Targets

Target utilisation: 70-80% (not higher)

Why not 100%?

• People need time for learning, collaboration, and creative thinking
• Unplanned work always arrives (production issues, urgent requests)
• Context switching between tasks has a real cognitive cost
• Sustained 100% utilisation leads to burnout and attrition

The utilisation trap: Organisations that optimise for 100% utilisation actually deliver less because:

• No buffer for the unexpected means every disruption cascades
• People have no time to improve processes or learn new skills
• Burnout increases attrition, which is far more expensive than 20% slack

Tracking Resource Performance

• Planned vs actual allocation: Are people spending time on your project as agreed? If not, why?
• Utilisation rate: Actual productive hours ÷ allocated hours. Target: 70-80%.
• Skill coverage: Are all required skills covered? Any gaps emerging?
• Attrition risk: Are any key team members showing signs of disengagement or overload?
• Ramp-up progress: Are new team members becoming productive within the expected timeframe?

Resource Planning Anti-Patterns

The invisible allocation: People are "allocated" to your project but spend most of their time on other work. Fix: get explicit, written commitment from resource owners with specific allocation percentages.

The hero dependency: The entire project depends on one person's unique knowledge. Fix: identify single points of failure early. Cross-train, document, or hire backup.

The late request: Asking for resources the week you need them. Fix: plan 4-6 weeks ahead. Resource owners need lead time to arrange coverage.

The 100% myth: Planning every person at 100% utilisation with no buffer. Fix: plan to 80%. The remaining 20% is not waste — it's resilience.

---

Download the [Capacity Planning template](/templates) to plan team resource allocation across sprints and quarters.