How Long is a Piece of String?

Good morning Andrew.

So, how long is a piece of string? Do you remember when Mom asked you that question last week? Your response was pretty funny - that quizical look with your head cocked to the side and your response of 'huh?' was rather amusing.

It's a pretty silly question, isn't it? But would you believe that questions like that are asked all the time regarding IT projects? And what is even more amazing is that people actually give answers to such vague questions and then they make important business decisions based on them.

Getting back to the string for a minute, if I show you a piece of string and ask you how long it is you can give me a pretty good estimate because you can see the string. If you want to do just a little more work you can get out your ruler and measure the string and give me a pretty precise answer. The frustration of the original question is that there is just not enough information to give a meaningful response.

So how does this question about the length of a string relate to me as a Project Manager? Well, in this analogy the string is my project and the length of the string is the cost and/or duration of my project. There is always an original estimate for the cost and duration of a project and as a PM it is my job to mitigate the risks of the project overrunning these estimates and to validate the accuracy of the original estimates. It is pretty well documented how inaccurate original project estimates are in my business so I won't belabor that point here. But the real problem is that we often don't know how bad our estimates are until way too late in the project.

So how do I know how my project is progressing if estimates can't be trusted? What I have learned as a Project Manager is to stop estimating and start measuring progress on my projects as soon as possible. How soon? Within weeks of the project start date.

The problem with using measurements rather than estimating is most projects are not set up for adequately measuring progress. For example, it is extremely difficult to get meaningful progress measurements during a requirements gathering phase of a project. How do you know when all requirements have been captured? How do you know that requirements won't change? Most often a project will have a requirements gathering phase that is timeboxed, say 3 or 6 months. But 100% complete of the requirements phase does not necessarily mean that all requirements gathering is done. If you end the requirements gathering phase on time just to statisfy the estimates or the project plan, your developers will end up burning their cycles during your development phase chasing down missing requirements, something that you probably did not include in your development estimates.

Another example of what some people think is a measurement is the 90% complete status on a task. This is rarely used as a measure of work complete but is just another estimate of work required to complete the task. And I have seen in my years as a PM that 90% complete often equates to about 50% work left.

Here are some suggestions on how to start measuring a project's progress and stop relying on estimates:

- Start measuring progress as soon as possible. Gather just enough requirements to have developers start coding and continue to gather requirements in a just-in-time fashion to keep developers productive;

- Prioritize requirements so you can work on the most important stuff first and get feedback from the users on the most important stuff right away. Don't wait for months to get their feedback and find out you have missed the mark. That will really blow your original estimates;

- Use working software as the only measure of the progress on a project (no more 90% completed tasks);

- Measure using smaller sized tasks. Smaller tasks give you better measures than larger ones and will also give you a larger sampling of measures that can be used for meaningful statistical evaluations. Smaller tasks are also completed sooner and therefore give you measurements sooner that you can begin to use to extrapolate to a meaningful project complete date.

Just remember this Andrew - estimates are predictions, often with a lot of unknowns and nobody gets all their predictions correct. Completed work is real and measurable and should be used to validate original estimates and then to adapt the plan to reality.