“Free Staffing Plan Template With Real Examples”

What goes into a staffing plan template?

Ten fields per row, and only ten. Anything more becomes a spreadsheet nobody updates after week two.

The template below is the version that survives real projects: it is short enough to maintain weekly and specific enough to defend in a budget meeting.

Three fields decide whether the plan is real or decorative. FTE allocation because 0.5 of a person is not a junior hire — it is a negotiation about attention. Start week because availability is the constraint everyone discovers late. Loaded rate because a $70 hourly rate is roughly a $100 loaded cost once benefits, tools, and overhead are included.

Keep the plan in the same tool the team uses for delivery. A staffing plan in a slide deck is a forecast; a staffing plan attached to the project is a decision.

Why does headcount overstate capacity?

Because a person and a full-time equivalent are different units, and a new hire is neither for the first three months.

A team of eight sounds generous until you break it down: one is on parental leave from week 12, one is 0.6 on another project, one starts in week 5, and two are contractors who leave at week 30. The plan says eight; the capacity is closer to six and a half, and the capacity curve is worse than the number suggests because the ramp is at the front, where the schedule is tightest.

The productivity curve below is the one worth arguing about, because it drives every downstream number. It is a planning convention, not a law — senior people with domain context ramp faster, juniors slower, and contractors on a well-documented codebase faster still.

Summing that curve gives a useful shortcut: the first four months of a new hire deliver the equivalent of 2.5 full months. So a nine-month engagement by a new starter is worth 7.5 months of a fully productive person — a 17% capacity discount you either plan for or discover.

If you staff the plan at 100% of the curve and the work is front-loaded, you will miss the date and blame estimation. The estimate was fine; the capacity assumption was wrong.

How do you get the role mix right?

Start from the work, then apply ratios as a sanity check — never as a substitute for thinking about the actual deliverables.

The ratios below are rules of thumb from delivery teams of 5 to 60 people. They are not targets for their own sake; they exist so that a plan with eight engineers and no QA gets challenged before it ships.

Three adjustments matter more than the ratios themselves.

Front-load the specialists. A designer at 20% for nine months produces less than a designer at 100% for two months, because context switching costs more than the hours suggest. Sequence the specialist work, then release the person.

Do not split anyone below 0.3 FTE. Below that threshold, the person attends meetings but does not do the work, and the plan quietly overstates capacity by a third of a head.

Count the lead as delivery, not overhead. A tech lead at 50% coding and 50% review is realistic. A tech lead at 0% coding is a manager, and should be planned as one.

What does a nine-month staffing plan look like filled in?

Here is a complete plan for a platform build: 22 engineer-months of scope, a nine-month window, and eight people including two part-time roles.

The cost column is FTE × person-months × 160 hours × loaded rate, and the weeks column shows calendar duration. The tech lead: 9.0 × 160 × $120 = $172,800. Senior backend: 9.0 × 160 × $95 = $136,800. QA: 7.0 × 160 × $75 = $84,000. Designer: 5.0 × 160 × $85 = $68,000. BA: 4.5 × 160 × $80 = $57,600. Delivery manager: 4.5 × 160 × $90 = $64,800.

Use 46–48 productive weeks a year, not 52, and state the assumption in the sheet. Every plan that assumes 52 weeks is overstating capacity by 8–11%.

Two observations from the filled example. First, the specialist rows are short and expensive: the designer costs $68,000 for five months, which is 7% of the budget for the phase where most of the product risk sits. Second, the part-time rows add up: two 0.5 roles cost $122,400, which is more than the QA engineer. Part-time coordination is not cheap, and pretending otherwise is how plans under-budget by six figures.

How much does ramp-up cost in real money?

On the same plan, four engineers starting on day one absorb 30 paid months to deliver 22 effective months — about $121,600 of paid-but-not-yet-productive time.

The curve again, applied to four engineers over nine months: each delivers 0.25 + 0.5 + 0.75 + 1 + 1 + 1 + 1 + 1 + 1 = 7.5 effective months. Four people: 30 effective months. The scope needs 22, so the plan carries an 8-month buffer — which sounds comfortable until you price it at $15,200 per engineer-month: 8 × $15,200 = $121,600.

That is not waste in the moral sense; it is the cost of parallel onboarding and a schedule buffer in the same line item. But it should be a decision, not an accident.

Now stagger one hire. Three engineers start in week 1 and the fourth in week 9. The first three deliver 22.5 effective months in nine months; the fourth delivers 5.5 effective months over seven months (0.25 + 0.5 + 0.75 + 1 + 1 + 1 + 1). Total: 28 effective months — still ahead of the 22 needed, and two months cheaper: 2 × $15,200 = $30,400 saved.

The general rule: hire to the curve, not to the org chart. If the work is heaviest in months two to five, adding a fourth engineer in month one buys buffer you cannot use. If the work is a long plateau, adding people later costs more in coordination than it saves in idle time.

What does a six-week support pod cost?

About $32,800, and the math is short enough to do on the back of a ticket.

A support pod for a product launch: one senior support engineer full-time for six weeks, one part-time engineer at 0.5, and 0.2 of an on-call specialist. FTE total: 1.7. Weeks: 6, at 40 hours = 240 hours per FTE.

• Senior support engineer: 1.0 × 240 h × $70 = $16,800
• Part-time engineer: 0.5 × 240 h × $70 = $8,400
• On-call specialist: 0.2 × 240 h × $95 = $4,560
• Subtotal: $29,760
• Ramp and handover pad at 10%: $2,976
• Total: $32,736

Two things to notice. The on-call specialist costs more per hour than the pod, even at 0.2 FTE, because specialist hours are expensive and unpredictable. And the 10% pad is not padding — the first two days of a launch pod are spent on access, tooling, and learning the escalation path, which is exactly the ramp curve at small scale.

Short engagements are where plans go wrong most often, because the ramp is proportionally huge: a two-week engagement with a new contractor delivers about five days of work for ten days of pay. Either accept that as an onboarding cost or bring in someone who already knows the system.

How do you staff three projects with one scarce specialist?

You allocate by constraint, not by fairness: the specialist goes where the delay costs the most, and everything else gets sequenced around that decision.

Say a designer is needed at 0.6 FTE on Project A for three months, 0.4 on Project B for two months, and 0.3 on Project C for four months. The total is 1.3 FTE in the overlap month — impossible with one person, and the plan must resolve it explicitly.

Three honest options:

Sequence the work. Move Project C’s design phase one month later. Cost: a one-month delay on C, zero additional spend. Usually correct when C has float.

Buy 0.3 FTE. A contractor at $85/hour for 0.3 FTE over four months is 0.3 × 160 × 4 = 192 hours, or $16,320. This is cheap if C’s delay would cost more than that, and expensive if C is a low-priority project.

Cut scope on A. Reduce A from 0.6 to 0.5 and accept a slightly later design freeze. Cost: a design compromise, which is the hardest to price and usually the worst option.

The plan should show the overlap and the decision, with a name against it. A staffing plan that hides a 130% allocation is not a plan; it is a hope with a spreadsheet around it.

Contractor or employee: which belongs in the plan?

Both, in most plans — the question is which risk you are buying down with each.

The mistake is using contractors to avoid headcount while planning them at employee productivity. A contractor who starts in week 30 of a 39-week project delivers roughly two effective months, not nine, and the plan must say so.

A reasonable split for a nine-month build: core engineering and the lead as employees, the specialist design and QA peaks as contractors, and coordination as a part-time internal role. That keeps the knowledge where the product lives and the flexibility where the schedule is uncertain.

What are the most common staffing plan mistakes?

They cluster into five habits, and each one has a measurable cost.

Planning at 100% allocation. A person at 100% has no room for review, incidents, or interviews. Plan delivery work at 75–80% and treat the remainder as the cost of existing.

Ignoring ramp. Assuming a new hire is productive in week one overstates capacity by about 17% over nine months — and more on short engagements, where the discount can exceed 30%.

Staffing the org chart instead of the work. Two juniors are not one senior, and one senior is not two juniors. Match seniority to the ambiguity in the work, not to the budget line.

No named owner per row. A staffing plan without owners is a wish list. Each row needs someone who confirms the person is actually available.

Reviewing it once. The plan is a weekly artefact. Availability changes, scope changes, and a plan reviewed monthly is a plan that is always three weeks stale.

Forgetting the exit. Offboarding, handover, and knowledge transfer take time. A plan that ends at 100% on the last day has no room for the handover that makes the next project cheaper.

How does Doitify support a staffing plan?

Doitify is our product, so treat this as disclosure. It holds projects, tasks, sub-tasks, checklists, owners, and due dates, with Kanban, Gantt, roadmaps, calendars, workload views, reports, and automations — plus Copilot, which turns a stated objective into a plan you can staff.

The staffing-specific value is the workload view. A plan in a spreadsheet says a person is allocated at 0.6; the workload view says whether that is true in week 14, when three other projects also want them. Putting allocations on the same timeline as the delivery dates is what turns a forecast into a decision, and it is the single feature most staffing spreadsheets cannot replicate.

The honest limit: Doitify does not calculate loaded rates or produce payroll-grade cost reports. Keep the money model in a spreadsheet or your finance system, and use the workspace for capacity, ownership, and the weekly review. The two artefacts answer different questions, and merging them usually produces a file nobody trusts.

Conclusion

A staffing plan template is not paperwork. It is the artefact that makes the difference between a plan and an intention: who is available, from when, at what share of their week, and at what cost.

Fill it in FTE, not names. Apply the ramp curve before you promise a date. Check the ratios so that the missing QA is visible before the release. Price the specialists honestly, because five months of design is not a rounding error. And put it next to the delivery dates, where an over-allocation shows up as a red week rather than a surprise in month seven.

If this post on staffing plan template was helpful, you might also enjoy Project Management Software for Content Teams: 2026 Guide and Doitify vs Asana.