consolidating repetitive tasks, reducing estimates for similar tasks further along in the schedule, etc.), and considering other economies of scale. Using bottom-up estimating works well when overlaid with the judicious application of delivery techniques (e.g. Naïve perhaps, but more likely this technique is their way to build in contingency, excessive though it may be. The aggregate of the lowest level WBS component estimates, by definition, extends the overall project duration beyond what is truly feasible. 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. I like this technique because it tends to give a more accurate estimation of effort and duration at the tasks and activity level. 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. It relies on project delivery experience to calculate more realistic estimates than some of the other techniques. Three-point estimating is more rigorous and takes more time to derive. The three estimates were then plugged into a formula (which might be as simple as an average of the three) to derive expected durations. pessimistic – the worst-case estimate for this activity.optimistic – the best-case estimate for this activity.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.This method derived three separate estimates to define a range for the activity durations: It wasn’t foolproof, but it often brought us close to the effort and duration that execution would take.Ī third method we used, though less often, was three-point estimating. 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.
Estimate activity durations process code#
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. 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. This worked particularly well during the execution phase of our projects. The result – more projects were delivered successfully on time and within budget, with fewer “death marches” for our staff.Īnother estimating technique that we used was parametric estimating.
Our clients and prospective clients began to rely on our estimation of activity and project durations. As we accumulated historical information, staff effort, and productivity metrics, our ability to estimate and propose new jobs became much more reliable.
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. 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. Perhaps I was fortunate that my consulting career was largely within a single industry. 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.Īs 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. It seems that in the exuberance of estimating a new project, IT providers would conveniently forget this truism. It was certainly true of execution, but what of the estimating process?
Estimate activity durations process software#
Throughout my career I was always aware of Brooks’ Law: “Adding manpower to a late software project makes it later” (Brooks, 1975, p.25). The 4 Best Techniques for Estimating Activity Durations
0 kommentar(er)
