Project Staffing Optimizer Skills Deadlines Calculator

Staffing arithmetic starts from an identity that is often wrong in practice: effort divided by available time gives headcount. This model corrects the denominator twice before dividing. First it removes overhead, the share of a nominal 40-hour week consumed by meetings, code review, administration and context switching, which time studies commonly place at 20 to 40 percent. Second it applies a productivity factor of 0.5 plus 0.5 times the skill match, so a team matching only half the required skills produces about 75 percent of full output rather than half, reflecting that unfamiliar work costs learning time and rework rather than halting outright. The correction that matters most at scale is communication. A team of N members has N(N-1)/2 pairwise channels, so growing from 5 to 10 people takes the channel count from 10 to 45. Charging roughly half a percent of capacity per channel, capped at 30 percent, reproduces the observed flattening of output past eight or nine people and explains why the two-pizza team convention persists. The model assumes work is perfectly divisible, which it is not: tightly coupled modules and long dependency chains impose a critical path that no amount of headcount shortens. It also assumes new staff are productive on day one, whereas onboarding a developer into an existing codebase typically takes four to eight weeks, which is exactly why adding people mid-project reduces near-term capacity before it increases it.

The governing observation is Brooks law, from Frederick P. Brooks Jr. and his 1975 book The Mythical Man-Month: adding manpower to a late software project makes it later. Brooks drew on his experience managing development of OS/360 at IBM in the early 1960s, a project involving well over a thousand people, and identified two mechanisms, the ramp-up time of new staff and the quadratic growth of communication paths, that make the person-month a misleading unit of exchange between people and time. A twentieth anniversary edition in 1995 added the essay No Silver Bullet, first presented in 1986. Formal effort estimation developed alongside it. Lawrence Putnam published the SLIM model in 1978, based on Rayleigh staffing curves fitted to US Army data, and argued that compressing a schedule much below its nominal length drives total effort up steeply. Barry Boehm published COCOMO in Software Engineering Economics in 1981, calibrated on 63 projects at TRW, expressing effort as a power function of program size and schedule as a power function of effort; COCOMO II followed in 2000 to account for reuse and newer development styles. Agile practice from the late 1990s onward shifted estimation away from absolute hours toward relative story points and empirically measured team velocity, but the coordination limits Brooks described did not change.