In David Anderson's self proclaimed "bad boy of project management" post on estimating he states that "we should stop estimating and start planning based on capacity." This is a twist on words to make it look like he's objecting to the traditional approach to estimating. He also states in a paper how an internal Microsoft IT department spent 40% of the capacity estimating the effort for work.
Turns out that capacity planning is estimating. The trouble with planning by capacity is you need to know how long something will take to know how long the resource will be consumed - hence how long its capacity will be unavailable.
This internal IT case is an a "poster child" example of doing stupid things on purpose. 40% planning time is either an exaggeration, a gross miss measurement of the sunk cost or the dumbest leader of an IT group I've ever heard of. Any improvement would be dramatic. There is no need to get fancy, just stop doing stupid things on purpose.
Reasons for Developing Estimates
There are many reasons to estimate the work in front of you.
- If you don't you're doing "level of effort" where the passage of time equals progress. This is actually forbidden in the aerospace business. With some form of an estimate the owner of the money can determine if the "value" of the deliverable matches her expectation. "You told me this would cost about $10,000 but you spent $20,000, I'm disappointed - no your contract is canceled"
- Without some estimate of the effort, it is difficult to prioritize the work. If I known the delivered value of a feature and the effort it will take to get that value, then I can make the necessary trade offs needed when the resources and funds are fixed. Trade offs are the heart of Systems Engineering. This "fix capacity" planning process requires both pieces of information.
Now how much effort should be spent on estimating? First ask, how much is this feature worth? If as David suggests all features are worth the same (this seems very contrived to me) then the same amount of effort should be spent on all features. But that doesn't answer the question.
The sunk cost of estimating must be paid back in the execution in some way. There are several ways:
- The estimate is used to prioritize the work and to deliver faster the features that add maximum value to the value stream. This is in fact David's beloved "flow process." It is also the work flow process of almost every manufacturing plant where gross margin is one of the measures of performance Beware Cost Accounting is needed to do this.
- By estimating the cost to deliver a feature the customer can be kept "in the loop" about how her money is being spent. The wise and careful expenditure of funds is pretty much an expected behavior in any business.
- Estimates establish a baseline of performance. If I make some kind of commitment to you for work performed within a defined time and cost, then you can measure (in some way) how well I am doing on my "promise to perform."
I still haven't answered the question of how much effort to put into estimating in any quantifiable term. Well it certainly isn't 40% for an internal IT department. But what is it? It depends on the problem at hand. How much would we spend to estimate the cost of the International Space Station? How about adding a new selection button on a music play list? How about the cost of a new home construction? It depends on the problem.
For International Space Station an 80% estimate is pretty good, same for the new home (assume custom) and probably the same for the simple screen control. So how much does it cost to get an 80% confidence estimate? Ask first - what is this estimate "worth" to the project. Don't pay more than it is worth. That's the answer.
Anyone with a better answer please write, we can use it on our space program cost and schedule estimating efforts.
