Planning Techniques for Estimating Projects
When I worked in a deadline-driven culture, the engineers all said the same thing: Projects should be estimated.
That means breaking the work down into little chunks, adding them up, and understanding the duration. That’s called functional decomposition, and it tends to fail because of emergent work, change, and, of course, we don’t think of the other work we have to do. (For most teams, an eight-hour day is not eight hours of productive work.)
Besides that, the deadline is often set early; the government needs the report on such a day for the company to stay in business, or the customer annual renewal is on such a day and sales already sold the product. The method used in planning here is called commit and figure it out later. It is remarkably common.
Commiting and figuring it out later can work just fine, especially if the company has a large portfolio of projects. If the whole team is committed, most deadlines are easy—the company shifts people and attention to whatever important projects are in danger. Those projects get done on time by starving the lesser projects.
Again, that strategy will work just fine on most projects that require expertise the team already has, like an ERP upgrade. When the company has to do something fundamentally different that requires new expertise, the strategy fails—but decomposition would have failed as well.
What people call the guru method is something more refined. An actual expert compares this project to several other projects and decides this project is somewhere between A and B. This can work exceptionally well if the work doesn’t change much (same people, process, and technology) and if the expert knows the true duration of the project, including the time at the fuzzy front end.
The last major method to estimate is prediction, which looks a lot like functional decomposition, in that we break the work down into small pieces. Instead of measuring our tasks in hours things should take, we count the number of pieces the team is actually getting done and then predict how long the project will take.
There are plenty of methods that don’t involve formal estimating at all. You might, for example, flex scope by funding six weeks of project work, put the features in a priority order, and stop at the end of six weeks. These things do happen, though they are an easier sell when the project is measured in minutes than months.
Today my preference is to flex scope. If I can’t do that, I predict where possible and compare when I can’t.
Sometimes, the deadlines are foisted on us. That is OK, especially in testing, when the key questions more likely have to do with when we should stop testing than how long things will take.
So, there you have some estimating techniques—and a couple of ways to play it by ear—that can expand your options when planning a work effort.
