Those who are managers know that there are various ways to get an idea of the timing and cost of a project. Those who manage IT projects will be more familiar with agile methodology.
I became familiar with agile methodology in a previous experience. In calls you would create a story, e.g., “the user wants to do X because they want Y etc.” and assign points to this story. The greater the points, the greater the difficulty, the greater the costs on both the time and economic side.
Just as in mathematics there are parentheses to break up problems, in agile methodology one can break up stories to lower points. A debated point in agile methodology lies in how to convert points into man-hours and how much to make them cost the customer.
PERT, also called three-value estimation
I will present a different, more statistical and “old” way, which, as you can anticipate, has its drawbacks. One might exaggerate by saying that it is an ironclad mode, because the PERT mode used to be used by the U.S. military. Today, they use more advanced techniques such as the Monte Carlo method, but they have significantly more complex projects than the non-big companies, which will read this article. This article is aimed at SMEs, roughly like the others.
This technique starts out fairly easy: you begin by establishing
a: the reputedly smallest number of days, hours, etc. to complete a project, activity
b: reputed to be as much as possible, likely
c: the maximum
From which we construct a kind of average M = a+4b+c/6
On the constants of the formula, 4 and 6, we come back to later because we can play with them.
And now comes the most difficult part of this method. With those numbers we can construct a probability distribution, which results in a special case of beta distribution, which in turn is a very special case of normal distribution.
This allows us to be able to calculate, say at 95 percent confidence, how soon we will complete the project or activities, depending on the numbers decided at the beginning. It helps from a contractual point of view and to avoid creating disagreements between the manager and the operations team, which often has disagreements about the estimated timelines.
Constants
Constants can be worked on to make more defensive estimates, which weigh more extreme cases and thus estimates with a wider range. This makes especially sense when few people decide those 3 numbers above, and so they can keep their bias at bay by including this corrective factor. But if you have a medium to large company and at a project those numbers are decided by more than 15 people, including managers and employees, the central limit theorem comes to your rescue, because it simplifies the type of distribution resulting from this interaction, producing an estimate less biased by possible extreme cases
Conclusions
From experience, I can say that the agile method is heavier from the point of view of story description, while the PERT method is heavier from the numerical point of view.
However, there are cases where both methods fail not because of the estimation but because of how you start. And there are no methods that hold: you need experience. As of the date of writing this article, I have recorded 2 cases out of over 26 where I blew the timing estimate. .
One case had to do with an in-process change for data: I had done the analysis on X, reported them to the client, and he realized he wanted those results on something else. He told me to repeat it on Y data, which was not originally planned.
In other case a library required a very thorough knowledge of its documentation and the output errors did not point directly to that suggestion.
Want to try playing with this? I created a dedicated spreadsheet.