Adding Four Contractors to a Late Payroll Replacement

Baseline arithmetic. Planned total ≈ 16 weeks × 26 points = 416 points. Delivered ≈ 58% × 416 ≈ 241 points. Remaining ≈ 175 points. Current velocity ≈ (19+17+18)/3 = 18 points per week, i.e. 69% of the plan's assumption. Forecast time to finish build ≈ 175 / 18 ≈ 9.7 weeks, so the build finishes around week 20 - four weeks late before the audit parallel run is counted. Data migration is not complete, and the six-week parallel run starts only after migration, so the earliest realistic production cutover is roughly week 27, about eleven weeks beyond the planned finish.

Why adding four contractors in week 11 cannot pull the date forward:

• Ramp-up cost is real. New engineers on an unfamiliar payroll codebase take two to four weeks to become net-positive, and payroll is the domain where domain onboarding is slowest because correctness is legal rather than aesthetic. In a nine-week residual window, that ramp consumes a third to a half of the remaining time.
• Brooks's law. Communication paths grow as n(n−1)/2. Going from five to nine people multiplies coordination paths from 10 to 36 while the schedule shrinks. On a project with three un-started integrations and a shared migration, coordination overhead lands on the critical path.
• The remaining work is not parallel. Three integration points are blocked on a late client-side deliverable, and one six-week parallel run is calendar-bound, not effort-bound. You cannot put more people on elapsed calendar time. The parallel run is the single biggest item in the forecast and it is immune to headcount.
• Two departures in week 12 remove capacity exactly when the new people arrive.

Conclusion: the proposal is not neutral, it is negative in the near term. The honest options are re-scope, phase the go-live, or move the date.

Form of the estimate: a range with a confidence level and stated assumptions, derived from observed velocity - never a single date. 'At the current velocity of 18 points per week, with the assumption that the three blocked integrations start by week 12, we forecast build completion between week 19 and week 22, and cutover between week 26 and week 30 at 80% confidence. The single largest driver is the six-week audit parallel run, which cannot be compressed. A January 1 cutover has an approximately zero probability under any staffing plan.' A point estimate invites the sponsor to negotiate the number; a ranged estimate with drivers invites them to negotiate the scope, which is the only lever that actually moves.

Options to put on the table:

1. Reduce scope to the statutory minimum for a January 1 run - one pay group, no retroactive pay, manual GL export, existing integrations unchanged. Highest schedule relief, real business cost, needs the CFO in the room.
2. Phased go-live by pay group or entity. Migrate 4,000 employees in waves so the first production payroll covers a low-risk population. Preserves the deadline with reduced blast radius. Usually the best value option and frequently the one sponsors have not considered.
3. Move the date to the forecast range, with the parallel run as the binding constraint and weekly burn-up reporting.
4. Add contractors only where work is parallelisable and well specified - not to the blocked integrations, not to the parallel run. Even then, state plainly that this reduces residual risk rather than shortening the calendar.

Also do this: convert the late API documentation into a formally tracked client dependency with a named owner, a dated impact assessment, and a change request. The five-week delay caused the overrun, and it should appear in the project record as a client-side dependency, not be absorbed silently by the team. Recommend option 2 plus option 4, with option 1 as the fallback if the CFO rejects phasing.

Knowledge transfer (weeks 10-12, not week 12). From today, the two contractors stop taking new work and are reassigned to handover. Concretely:

• Map what they uniquely know. Usually it is one or two integrations, a set of undocumented assumptions about a legacy data format, and the operational knowledge of how to run the thing. Write it down as a handover checklist with a named recipient for each item, not a vague 'shadowing' plan.
• Pair rather than document-and-hope. Rotate a permanent engineer into each contractor's area for the full two weeks, with the contractor reviewing and not driving by the second week. Documentation produced without a reader is worthless.
• Record the decision-relevant history - why a mapping is done a certain way, what the middleware vendor got wrong, which edge cases exist in the client's data. That is the knowledge that vanishes.
• Check bus factor before they leave. Any component where the bus factor is 1 and the sole owner is a departing contractor is a project risk to be escalated this week, not discovered in week 15.

The plan. Re-baseline rather than continue reporting against a plan everyone now knows is fiction. A stale plan is not neutral: it makes a competent team look like a failing team every week, and it hides the real forecast from the sponsor. Re-baseline with the sponsor's signature on the new range, the assumptions, and the top three risks, and keep the original baseline in the change log for reference. Preserve the velocity history as the basis for the new forecast.

Also: remove the four-contractor option from consideration unless the sponsor accepts that it buys risk reduction, not schedule. Adding people in the same week two experienced people leave, on the highest-risk integrations, is the worst possible sequencing, and if the sponsor insists, record the recommendation and the accepted risk in writing.