Staffing models

Build a project staffing plan around decision points

A project staffing plan should show which outcomes occur in each phase, the skills and authority needed at key decision points, and when people enter or leave. Protect a small core of continuity while bringing specialists in for bounded work. Plan onboarding, review capacity, and handover alongside delivery rather than treating them as administrative tasks.

On this page
  1. Map phases before positions
  2. Protect critical ownership
  3. Model capacity realistically
  4. Plan for a change in team shape
  5. Review staffing at milestones

Map phases before positions

Break the project into discovery, design, build, rollout, and transition, or another sequence that matches the work. For each phase, list deliverables, uncertain decisions, and dependencies. Then identify capabilities. This prevents a launch-phase team from being copied across the whole project and helps managers see where one person provides continuity while another is required only for a particular decision.

Protect critical ownership

Name an accountable outcome owner and the people who can approve scope, quality, and tradeoffs. Temporary specialists still need timely internal decisions. If everyone is assigned tasks but nobody can resolve conflicts, adding staff increases waiting. Keep enough overlap between phases for context to move, and make ownership transfer explicit when a project changes from building to operating.

Model capacity realistically

Record each person's availability, including existing work, leave, onboarding, and review duties. A subject expert allocated for two hours a week cannot silently carry daily decisions. Identify the weeks where several deliverables compete for the same scarce person. Adjust sequence, narrow scope, or add support before the bottleneck becomes an emergency request.

  • Deliverable and acceptance owner by phase
  • Specialist entry and exit dates
  • Required overlap for knowledge transfer
  • Known approval and review bottlenecks
  • Operational owner after project closure

Plan for a change in team shape

Illustrative example: a payments workflow project begins with a product lead, operations analyst, and security specialist. The specialist participates heavily during design, then returns for two review gates. Training and support staff join before pilot rather than after launch. An operations manager shadows decisions throughout and becomes the final owner, so the project does not end with expertise leaving on the same day.

Review staffing at milestones

At each major decision, compare completed work, remaining uncertainty, actual capacity, and the next phase's needs. Release people whose contribution is complete and extend only when the work case is clear. If the project slips, do not automatically keep every role longer; determine which capability the revised plan needs. Publish changes with consequences for budget, delivery, and other teams relying on the same people. Maintain a simple staffing change log with the reason, effective point, and affected deliverables. It helps a new project lead understand why the team shape moved and lets portfolio owners see when several projects depend on the same specialist. Review the log before approving any further overlap. Add one contingency owner for each phase-critical capability, even if the contingency is a scope reduction rather than another person.

Next step

Take one active project and add phase-specific capability, decision ownership, overlap, and exit points to its plan before requesting another person.

A clearer starting point

Turn your next hire into a considered brief.

Start a hiring brief