Some co-workers and I recently finished Software Estimation by Steve McConnell (Microsoft Press, 2006).
In Chapter 3, “Value of Accurate Estimates”, the book contains a graph of the extra cost of underestimating vs. the cost of overestimating, something like this:
On the left side, the graph pictures a nonlinear increased costs of underestimating (you don’t schedule enough time for the work; more errors introduced, more status meetings, those types of things). On the right side, the graph pictures a linear increased cost of overestimating: you pay your employees longer before the project is done (Parkinson’s Law). McConnell says “In software, the penalty for overestimation is linear and bounded…But the penalty for underestimation is nonlinear and unbounded“(p. 24).
As I look at it now, I believe that when I looked at McConnell’s graph I failed to distinguish in my mind between the cost of an incorrect estimate of effort and the cost of a too-aggressive or too-leisurely schedule. McConnell is contending that there is great value in having accurate estimates, and great cost to an organization that does not realize the true size of a project it undertakes. What he did not say (but in my mind I extended his statements to say) was that a larger effort estimate translates linearly to a larger project timeline. In other words, in my mind instead of saying
Don’t underestimate your project’s size
I read it as
Don’t go for aggressive project schedules
Again, McConnell did not say the latter, but I inferred it. Let me explain why I think I erred in doing so.
Why An Aggressive Schedule?
There are big costs to an organization that doesn’t develop at a fast enough pace. Here are a couple I can think of:
- The cost of lost business due to your competitors getting ahead of you. This would take the form of lost sales now (the product isn’t ready so your prospect chooses a different solution) as well as lost future sales (if the prospect had chosen you now and were happy with you over time, they would tend to purchase more licenses, buy ancillary offerings, etc.)
- The cost of losing your market leadership position. How valuable is it to a company to be the clear leader among its competitors? Once you lose that status, it must take great effort, possibly over a period of years, to gain it back.
These costs are nonlinear and unbounded as well. Suppose we could estimate the strategic cost to the organization in addition to the technical cost. We might get a cost graph like this, with the schedule increasingly aggressive toward the left and increasingly leisurely toward the right:
(The red is the increasing strategic cost to the organization of pushing the date out.)
This graph assumes that the project schedule corresponds linearly to effort, which is pretty simplistic (there is a whole project management discipline that deals with how you coordinate effort to meet a target date, and project management can be done with varying degrees of excellence or not, which would affect the mapping of effort to schedule)…
There are many costs associated with trying to get the project done on an aggressive schedule — but here we see pictured the potential costs to the organization of not getting it done sooner than the estimate. This helps us see why a more aggressive commitment could be the right choice for an organization. (When I was thinking of McConnell’s estimation error graph as a scheduling graph, on the other hand, I was wondering why executives would ever push for a more aggressive commitment when the numbers were clearly against it!)
Of course, there is a minefield of issues to navigate when you try to complete more work in less calendar time; for instance:
- How do you keep your quality at acceptable levels in the face of staff fatigue?
- What is the cost of lowered morale if the deadlines seem impossible to meet?
- What costly technical and architectural blunders do you commit because you’re focused on meeting the deadline and so you’re not as thoughtful about what you’re producing?
and many others — I think that we should lift these up as appropriate so our executives do get a picture of what kinds of cost we’re taking on as part of the aggressive schedule — but then I guess it’s our executives’ job to weigh the relative costs and so navigate!
It was the excellent last chapter of Software Estimation (Chapter 23: “Politics, Negotiation, and Problem Solving”) that got me thinking about this issue — in that chapter McConnell helps you see through the eyes of an executive and understand the kinds of issues you grapple with at that level.