Calculating the durations of a task in a project

Also this is an aspect of project management, which suppose to be know and widely being used in this discipline. In Israel, this can be compared with the predictions of the prophets. The method is very simple, but it requires discipline to maintain it. I use a large database or lists with specific tasks, where I write down three numbers:
  1. A= Worst case estimate
  2. M= Most likely estimate
  3. B= Worst case estimate
The Most Likely Estimate (the fourth factor I'm interested in) is a calculation of a weighted average ((a+4m+b)/6). The art of the whole thing is getting the values for common designing tasks (and not only for the IT industry, this can be applied in any type of project management). There are several methods to get those values in such list or database. The first method is the Delphy method. The method relies on a panel (read here a group of 'smoking' and yelling individuals), who are specialists in their areas, and they will be ;'interviewed in a special designed interactive process, to generate estimates for a common or specific (design) task. I use those methods in more scientific organizations like the NASA to get my scheduling accepted. If I use this method in Israel (which I did once), then I get a circus. Another method is the Wideband Delphy. This is almost the same as the Delphy method, except the way how the panel of experts are being interviewed is different and more specific, so that the estimates might be more practical for that type of project. And then there is the Planning Poker method, which again looks like the Delphy method, except the panel of experts is being replaced with the project members. The good thing is that with those interviews (or sessions), all project members are and will be closer to the project, but the bad thing is that not all project members are specialists and asking them for estimations is a problem at itself (you need to multiple their estimates with at least a factor of 10!

Statistical Delphy method

The Statistical Delphy method is the method I like to use normally and that method is developed by myself. Why? This method does not rely on humans and no panel of specialists or project members. It is based on cold facts and statistics. The good thing about this method is that it produces real estimates, which are very close to the reality, but the bad thing about it is that when you start to use this method, you don't have any (statistical) data (collected).
During the actual execution and implementation of the project, all the estimates of the (common or specific) tasks will be updated.
The good thing is, that when the project manager has this type of data already, and he is setting up and designing the project plan, he or she knows immediately how long a certain task or project will take when he or she enters the expected tasks. This method also requires a good and specially detailed specifications. An example: The developer must make a window with two labels and a button, which closes the window. The task of creating a window takes 2 hours, a label takes 1 hour and a button takes also 1 hour (according the numbers in the estimation database or list and that means that the task is finished in 4 hours. Those numbers from the estimation database or list have already corrections build in, like corrections of a percentage of holidays, sickness, etc. I also like to use additional data, like number of average defects for a given tasks, average productivity, bug density, average lag-time, defects, etc. The estimates are being registered for each task, but also per programming environment and Operating System. Why? There are considerable differences in durations for certain tasks using different programming environments. For example, a task in C++ (VS6) takes six times longer then the simple Visual Basic 6. The same for the modern combination, Visual Studio 2008 C++ takes three times longer then the same, but then in C#.  

No comments:

Post a Comment