Software project estimation is a tough job. If you get it right, great; but if you get it wrong - that's an issue. And, it does not matter whether your team will employ an agile methodology or the Waterfall during the implementation phase. At the estimation stage there are an enormous number of unknowns that are waiting to bury you. For anything but the most trivial, repetitive tasks there is no simple way. Except, math and the experience of other people. In this blog post I will describe an industry-standard Program Evaluation Review Technique (PERT) that can help plan projects more realistically and even calculate expected error of estimation. The mantra of mediocre project-managers is the infamous "most IT projects fail". It is used as a standard excuse for the projects that go months over planned deadlines and thousands of dollars over the estimated budget. Granted, the number of unknowns in a complex IT project is very large and, let's be honest, most clients do not provide requirements documents at even a reasonable level of completeness. Is that a good-enough excuse for poor plannning? What should we do? Give up? Accept defeat? Some "rational" clients go as far as simply doubling an estimate provided by a software team and using that for projections. It may be fine when a project is for $100K, but not for a multi-million project.
For comparison, let's note that even organizations as disciplined and capable as the US Department of Defense have gotten project plans wrong and grossly missed deadlines. The year was 1957 and the Soviet Union launched the Sputnik 1 satellite, the first man-made satellite. The United States had believed itself to be the world leader in space technology. The surprise Sputnik launch and the failure of the first two U.S. launch attempts proved this false. The "Sputnik Crisis" was the trigger of the space race between the United States and Soviet Union that motivated president Dwight D. Eisenhower to establish NASA. But it was also a trigger of another, less-known initiative: to identify project management as an area of inquiry and an object of much scrutiny, leading up to the modern concept of project management and standardized project models such as the DoD Program Evaluation and Review Technique, PERT. PERT was invented by Booz Allen Hamilton, Inc. while under contract to the United States Department of Defense's US Navy Special Projects Office in 1958 as part of the Polaris mobile submarine-launched ballistic missile project. [Wikipedia] PERT is a complex model. For the purposes of this blog post, we are only interested in the estimation part of it.
Estimation is the calculated approximation of a result which is usable even if input data may be incomplete, uncertain, or noisy. - [Wikipedia]
Incomplete input data is a common characteristic of IT projects. It is crucial to understand that, with incomplete data, it is mathematically impossible to come up with an exact answer. We are not trying to advocate fixed-budget projects or claim that we can correctly plan all of them. Our goal is to minimize uncertainty on one hand and equally important - measure the uncertainty. It is much better to tell a client that project will take 4 to 5 months, with certainty, than promise 4 months and go over the deadline by a month, in the end. As usual, communication and transparency are key to customer satisfaction. The beauty of PERT, as a model, is that it is capable of incorporating uncertainty, making it possible to schedule a project while not knowing precisely the details and durations of all activities. It is more of an event-oriented technique rather than start- and completion-oriented, and is frequently used in R&D projects where time, rather than cost, is the major factor.
Inner Workings of PERT
PERT uses notions of optimistic time, pessimistic time and most likely time estimates to calculate the expected time for a particular task. The optimistic (o) and pessimistic (p) times reflect the minimum and maximum possible periods of time for an activity to be completed. The “most likely” (r - realistic) time reflects project team’s “best guess”, based on the experience of completing similar tasks, of time the activity will actually require to complete. Once each of these estimates are made for an activity, an expected time (ET) can be calculated. The equation for expected time is as follows:
As mentioned, not only does PERT help come up with more risk-free, realistic estimates, but it also allows us to calculate a measure of uncertainty, expected standard deviation, giving a client much-appreciated understanding of the reliability of the estimate. The standard deviation of a task is calculated with the formula
How do we use standard deviation? Let's look at an example. Let's say an estimated overall duration of a project, according to the PERT calculations, is 80 days with the cumulative (overall) standard deviation of about 1.5 days. Remembering elementary statistics of normal distributions, three standard deviations (4.5 days) give 99% statistical certainty, so we can communicate to the client that the project will be completed in 80-85 days, with high confidence. Disclaimer: PERT is still sensitive to estimating the optimistic, most likely and pessimistic times for tasks, correctly. Such estimations come only from experience and knowledge of project. No math can cover that, but a "fuzzy" (in mathematical sense) approach of estimating ranges versus trying to guess exact numbers averages risks drastically, leading to much more reliable overall estimates.
* * *