Throughout my career I was always aware of Brooks’ Law: “Adding manpower to a late software project makes it later” (Brooks, 1975, p.25). We all knew this. It was certainly true of execution, but what of the estimating process?
It seems that in the exuberance of estimating a new project, IT providers would conveniently forget this truism. For some unknown reason, whenever they estimated activity durations that didn’t fit within their clients’ requested timelines, someone (typically a “higher up” who was not responsible for delivery) would invariably say, “throw some extra bodies at it.” Of course, this virtually guaranteed a late project before it even started.
As I noted in my previous article, “Why You Should Educate Management on Estimating Activity Durations,” we project management professionals need to wrestle control back to those of us who are in the trenches to provide realistic timelines for our projects.
Perhaps I was fortunate that my consulting career was largely within a single industry. Given that single industry focus, many of our proposal estimates were able to use a technique called analogous estimating. Using this technique, we were able to use actual activity durations and staff effort from previous project deliveries to derive analogous estimates for the new project.
Notice that I said we used actual, not estimated, work effort from prior projects to develop the duration and resource estimates for the new project. As we accumulated historical information, staff effort, and productivity metrics, our ability to estimate and propose new jobs became much more reliable. Our clients and prospective clients began to rely on our estimation of activity and project durations. The result – more projects were delivered successfully on time and within budget, with fewer “death marches” for our staff.
Another estimating technique that we used was parametric estimating. This worked particularly well during the execution phase of our projects. Over time our teams had developed the ability to rank different modules with varying degrees of complexity, and apply an estimate of expected effort to each complexity. For example, if a simple module required two days to code and unit test on average, and a highly complex routine required 20 days, it was simply a matter of reviewing the design, assigning complexity to each module to be constructed, and then doing the math.
True, this works better using waterfall methodologies than, say, agile methods, but it illustrates the ability for teams to become more proficient in estimating as they find areas in which they can apply parametric estimating. It wasn’t foolproof, but it often brought us close to the effort and duration that execution would take.
A third method we used, though less often, was three-point estimating. This method derived three separate estimates to define a range for the activity durations:
- most likely – a realistic expectation of this activity’s duration based on resource productivity and availability, dependencies on other activities or resources, anticipated interruptions, and other such information
- optimistic – the best-case estimate for this activity
- pessimistic – the worst-case estimate for this activity
The three estimates were then plugged into a formula (which might be as simple as an average of the three) to derive expected durations.
Three-point estimating is more rigorous and takes more time to derive. It relies on project delivery experience to calculate more realistic estimates than some of the other techniques.
Probably my most – and least – favorite estimating process was bottom-up estimating, which begins with estimates at the lowest levels of the Work Breakdown Structure (WBS) and aggregates the results. I like this technique because it tends to give a more accurate estimation of effort and duration at the tasks and activity level.
While I like this technique, I’ve also found that it provides my extremely conservative delivery colleagues with metrics that support their overly cautious belief that projects should take much longer than management expected. The aggregate of the lowest level WBS component estimates, by definition, extends the overall project duration beyond what is truly feasible. Naïve perhaps, but more likely this technique is their way to build in contingency, excessive though it may be.
Using bottom-up estimating works well when overlaid with the judicious application of delivery techniques (e.g. consolidating repetitive tasks, reducing estimates for similar tasks further along in the schedule, etc.), and considering other economies of scale. Doing so rationalizes the aggregation of discrete estimates to an overall project duration that is more feasible.
By now you may be asking what this article has to do with applying the people aspects of project management to the clearly process-oriented and more technical estimation of activity durations. Note that in describing each of the estimating techniques above, I asserted that the experience of project delivery professionals, who are in the trenches and know how to apply historical data, is paramount. The results are more timely deliveries, projects that stay within budget, satisfied clients, and fulfilled IT project staff.
Brooks, Frederick P., Jr. The Mythical Man-month: Essays on Software Engineering. 1975. Reading, MA: Addison-Wesley Publishing Company, Inc., 1982, Print.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.