Frederick Brooks famously said that adding staff to a late project only makes it later. The reasons are readily apparent. The project is already experiencing difficulties, most of which were not caused by understaffing. The usual culprit is an unreasonable schedule constraint; but starting work before the requirements were well defined, poor change control, or weak configuration management could also be the villains (or at least play a contributing role). None of these root causes is staff related and adding staff does not fix them: it merely adds more bodies to the confusion.
But, how do we determine the most appropriate staffing profile for a software project? Parametric estimation models suggest a way: these models have determined that there is a relationship between the functionality that a project delivers (called size in the software estimation vernacular) and staff. Fitting a regression line through hundreds or thousands of software projects determines an average and deviation from that average. The regression is a reflection of how software projects have performed. This is what has worked. This capability is built into estimation software like SLIM-Estimate. A wise approach is to take the average as a starting point, then adjust the modeling parameters that would increase or lower the staff. A word of caution here: if you find that your adjustments cause staff, effort, or duration to be more than 1 standard deviation above or below average, you are probably being either too optimistic or pessimistic. Don’t do it!
Staffing does not exist in a vacuum. In fact, it has a very close and non-linear relationship with schedule. Schedule also has a relationship with software size: it tends to increase as size grows and there is also some variability around it. There are two laws of software that define the relationship between staff and schedule.
- Law 1: There are finite limits to how long or short a project’s duration can be and how many or few persons can be used to staff it. Again, a parametric model can determine the boundaries of what is impossible (too many bodies, too short of a schedule) and what is impractical (too few bodies and too long of a schedule). We call these the Impossible and the Impractical Zones. The figure below illustrates this concept.
- Law 2: Every unit of schedule compression from what is optimal is purchased at the cost of many units of staff, effort, and expense. And the ratio increases the more the schedule is compressed.
For example, I modeled a 600 function point project including the project schedule from the beginning of analysis until it was ready for implementation, keeping it consistent with industry averages for staff, effort, productivity, and duration. It required 8.1 months to complete, had a peak staff of 7.2, and expended 44 person months of effort. Next, I modeled the same project with 10% schedule compression. It completed in 7.3 months, had a peak staff of 11.2, and required 62 person months of effort. This scenario was well within one standard deviation of average for staff, effort, and schedule. So, the 10% reduction in schedule was purchased by a 41% increase in cost/effort and a 56% increase in peak staff.
In the final analysis, the decisions about staffing and schedule are seldom made by the project team. The two laws of software development need to be internalized by the business leaders and sales teams who negotiate contracts and make commitments. But, remember, whatever the leaders decide, the law is the law and lawbreakers are only inviting trouble.