It has long been a given that accurately estimating project effort is virtually impossible without data from other, similar projects. Unfortunately, in the world of Internet time, not many teams have accurate metrics from past projects; moreover, the likelihood that any new project is truly similar to past projects is slim. And likely as not, the people on the project are a "virtual" team; most have probably never worked together before, and only a few team members have done any work similar to the task at hand.
How is the beleaguered project manager supposed to create an estimate with so many unknowns? Too many merely accept the constraints they have been given and massage some vague guesses into a politically acceptable "estimate," then forget about it as soon as the technical work begins. When the schedule slips, it's usually shored up with unreported overtime or by cutting time from crucial processes like testing. The result is that if any metrics are kept, they are wrong, since the technical staff had to work ghost hours to fit the project into the calendar-based time constraints.
Estimate Tasks As Inch Pebbles
Rather than trying to estimate large, nebulous units of work, break the units down into the smallest components possible: inch-pebbles. A general rule of thumb is that if you can't decompose a task into a unit that will take a maximum of a day or two to develop, then it's not a valid inch-pebble. Decompose the task until it can be demonstrated than it can be completed within a day or at most, two days. A task decomposed to this level can be estimated more accurately. Now, rather than trying to estimate each inch-pebble, sort them into groups of complexity. Usually, we sort inch pebbles into three groups: the "low" complexity tasks are those that will require two hours or less to complete, "medium" from two to four hours to complete, "high" from four to eight hours to complete. There are always those tasks that we simply don't know enough about, so we assign these a "Byzantine" complexity that we refine as the project progresses.
Continuously Refine Estimates as the Project Progresses
Regardless of how well we think we understand a task, development is a process of discovery. And part of that discovery is learning the true complexity or simplicity of a system's component parts. After a week or two of development and tracking, you may discover, for example, that the low-complexity inch-pebbles averaged 47 minutes, while the high-complexity tasks were averaging 16 hours each. Once you have these metrics, it's time to revise your estimates based on the new numbers. Use the metrics as you gather them to refine your estimate, and refine your estimate on a regular basis, preferably weekly.
Report Problems Before a Crisis
What's that? Revise an estimate? But you gave the stakeholders a number and they wanted it delivered, right? Right, but if it turns out the estimate was off, even by a little bit, report it to the stakeholders while it is a small problem, rather than waiting for the skewed estimate to drift even further off course.
I don't think it's necessary to remind project managers that an estimate is not a commitment to a schedule; however, it is equally the responsibility of a project manager to remind the project sponsors that an estimate is not a commitment.
--Jeff Gainer