Project Estimation

Why don’t we just call plans what they really are: guesses. …

When you turn guesses into plans, you enter a danger zone. Plans let the past drive the future. …

The timing of long-range plans is screwed up too. You have the most information when you’re doing something, not before you’ve done it.

– Jason Fried and David Heinemeier Hanson “Planning is guessing” from Rework, page 19

Estimating how long a software project will take is hard. Everyone working in software can agree with this. That’s however where the agreement ends. Is it even possible to make realistic estimates? Is it worth the hassle? Do you estimate big blocks of tasks or do you break the project into small detailed ones before you estimate? How do you deal with changing requirements? Do you estimate the calender time required for a given sub-project or the pure time spend on working on it?

(c)iStockphoto.com/pidjoe

All of these questions are highly debatable and even though they are phrased as simple binary decisions, the answers are most likely on a continuum between yes and no. Most software professionals will, for example, respond to the first questions with something between the extremes “It cannot be done” and “You can get it exactly right”.

The article quoted above is not specifically about planning software projects, but I think these views reflect what many programmers think of planning projects. However, as few projects are implemented in splendid isolation, coordination with colleagues and partners and communication with bosses and customers usually confronts us with the need to present estimates.

Using the past to inform decisions about the future, is not generally seen as negative as Hanson and Fried do. Evidence-based scheduling is a method for using data about estimates and actual work times of past projects to create more accurate estimates for a future project.

The problem that you don’t know enough to make a realistic estimate at the beginning of the project is sometimes called ”Cone of Uncertainty”. The range of uncertainty is enormously wide at the beginning and narrows as the project moves forward.

Cone of Uncertainty (Source: McConnell, Software Estimation, page 28)

In his book Software Estimation Steve McConnell talks about working to narrow down the cone by making decisions that reduce variability.

The Cone narrows only as you make decisions that eliminate variability. … Defining the product vision (including committing to what you will not do) reduces variability. Defining requirements — again, including what you are not going to do — eliminates variability further. Designing the user interface helps to reduce the risk of variability arising from misunderstood requirements. Of course, if the product isn’t really defined, or if the product definition gets redefined later, the Cone will widen, and estimation accuracy will be poorer.

– Steve McConnell “The Cone of Uncertainty” from Software Estimation

Now, this doesn’t sound to hard. But it omits an important problem. Possibly the greatest problem in planning projects: changing requirements. In another book, McConnell acknowledges this problem.

Maybe you think the Pontiac Aztek was the greatest car ever made, belong to the Flat Earth Society, and make a pilgrimage to the alien landing site at Roswell, New Mexico, every four years. If you do, go ahead and believe that requirements won’t change on your projects.

– Steve McConnell “The Myth of Stable Requirements” from Code Complete, page 32

I don’t think this completely invalidates the process of narrowing down the Cone of Uncertainty but I wouldn’t be as optimistic as McConnell about how early you can get to +/- 20%.

When the requirements change, developers or project managers need to update their estimates and fight to get the stakeholders accept that the project will take longer than initially estimated (requirements chages that cause the project to finish earlier are a theoretical possibility – so is life on other planets). Getting this across has a lot more to do with communication than with project estimation.

A major source of communication problems is the confusion of estimates and targets. The estimate is what you think when the work will be done. The often-cited trade show where the finished project is supposed to be introduced is a target. When you’re asked to change your estimate so that you finish in time for the trade show, you’re in a spot of communication bother.