The Value of Estimating (Even With Software Projects)

There is a trend in software process commentary to claim that plans and estimates aren't very useful, to admit that most of the plans we make are, in effect, guesses. There is some truth to this. In many cases, the scope of the work is unclear, the staff available to complete it is unclear, and the difficulty of creating the application is unclear.  On the other side of the fence, there are fixed budgets that have to be requested, there is the PMBOK which encourages you to build a Gantt chart including every task on the project with no uncertainty, and there are a lot of people out there that want to describe the software development process as something that is more like a manufacturing or construction project.  In reality, software development projects lack the predictability of those sorts of projects, because they involve invention of something new.

However, it is absurd to say that estimation is impossible. For example, it is fairly easy to give an order of magnitude size estimate of a project based on other similar projects. Even if your own organization is not keeping track of it's historical project performance, industry standard tools such as Construx Estimate can be used to provide some rough guidelines based on their collection of data.  These are overall project estimates, which can be superior to the bottom up estimation that is often done in agile projects.  The estimation process by which each feature or story is individually estimated can problematically leave out costs and time associated with missed requirements, tasks that are not particular to a feature, and the overall drift of iterative processes by which the initial implementation of a feature is not final, but must be refined over time with a refactoring cost that is often not estimated.  Whole project estimation techniques avoid some of these oversights, and can even be tuned to avoid the error in the initial size estimate for the system.

It is also possible to give estimates that demonstrate the uncertainty of the project by including a probability curve or range. The estimate also should not be static, but rather updated as new data comes in.  The Cone of Uncertainty is one common way to represent this process:

 

This particular manifestation of the cone represents a waterfall style process underlying the estimation accuracy, but we can imagine a similar cone being applied to agile methods. When work is done to begin the bottom up estimation process, there is more information available now to map that information to the estimate, and eventually we can switch over to the bottom up estimate when it starts to become more stable than the holistic estimate.

The key thing to remember here is that an estimate is not a commitment.  If you commit to a the 50% confidence estimate, there is a 50% chance you will miss the date.   If you commit to a 90% estimate, the proposed timeline may be unacceptable to your customer, especially if you are willing to admit that there is some failure rate involved in software projects and there is a non-zero probability of not delivering at all.  Making a commitment to a 90% date also introduces the risk of Parkinson's Law coming into play. When someone writes out a Gantt chart that has the 90% confidence date for each individual task, seemingly magically, the work comes in very close to the deadline. Except for those few tasks that don't, the ones that weren't actually started in earnest until the deadline was right upon the developer, but were more complex than expected.  If those were on the critical path, all of sudden your whole project just got pushed out past the 90% confidence date, even if everything else is completed by the deadline.  This where Critical Chain Project Management comes into play, but we'll save that topic for a future post.