An incomplete cost graph

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).

My Misunderstanding

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.


3 thoughts on “An incomplete cost graph

  1. We have been estimating stories in points for the past several months and seems to work pretty well. The point scale is a relative scale based on size, complexity and risk. In our system, 1 point is added a new field to a web page and persisting it to the database. This helps a great deal in eliminating time from our estimation. If we need to look at time, we look back and see that for example, a 3 point story takes an average of 8 hours. Without taking time into consideration, we get much better estimates. Since the time it takes to provide the same amount of business value can vary greatly depending on inturruptions, refactoring or skill of the programmer.

  2. This is interesting stuff, it’s reminds me of the utility function we learned about in business economics. I found a site that kind of explains it, but in slightly different context.

    This post focuses on the cost aspect, but in making decisions on appropriate course of action, the cost/benefit analysis would be used, to determine whether the anticipated benefit would make the risk (or cost) worthwhile. The benefit is the part that would be used to get the necessary stakeholders on board, in order to gain commitment.

    As far as overestimating versus underestimating, it is better to slightly overestimate time and resources needed. It’s always better to beat your goals than to have to buy more time or ask for additional funding after the fact. This is true when dealing with both internal and external stakeholders. Better to underpromise and overdeliver than the other way around.

  3. Daniel,

    I think you understood my message best the first time — the graph you cite refers to *either* cost and schedule underestimation.

    I think your blog posting equates “setting an aggressive schedule” with “achieving an aggressive schedule.” What I think you’re missing is that “setting an aggressive schedule” (per the graph you cited) increases the chance of MISSING the schedule altogether. In other words, if you need an aggressive schedule and can choose either (a) estimating aggressively or (b) estimating accurately, you’ll end up with a shorter ACTUAL schedule if you choose option (b). This is the reason that this problem is so insidious. The most effective action is somewhat counter intuitive.

    Hope this helps.

    Steve McConnell

    CEO/Chief Software Engineer
    Construx Software
    “Software Development Best Practices” |

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.