4.10 BOZOKI S RANKING TECHNIQUE AND PERT

---

4.10 BOZOKI'S RANKING TECHNIQUE AND PERT

The next technique has been formed by taking elements of Bozoki's ranking technique and concepts from Putnam's Program Estimating and Reporting Tool, PERT. It can be combined with a Delphi session or can be done by individual estimators. It applies once functional entities of the system have been identified so it should be used during high-level and intermediate design stages. You should also have data from earlier projects relating to at least two similar functional entities that are similar in size and development environment. Do not use more than seven of these reference points or it becomes confusing.

The first thing to do is rank the functional entities, FE's, that is discrete and identified system components such as programs, for the new project in respect of those of the known or reference entities, RE. For example, my first FE may be smaller than one of the RE's but larger than the second. My second FE may fall into the same category but be larger than the first FE.

What I am doing through this technique is reducing the scope of the problem. Rather than having to think about where an entity fits in terms of the whole project or system I am now relating it to the known reference points and to where I have placed my other FE's.

Now expert opinion is used to assign three estimates to each of my functional entities. These estimates are a smallest, a most likely and a largest estimate. Note that these are seldom distributed evenly about the most likely estimate. For instance, I may say that for one of the entities, if all goes really well and we face no problems, the minimum cost is going to be three engineering months. However, I know what things are like on most projects and, being honest, it will probably take us four engineering months. But, if things really hit the fan and that sneaking suspicion I have about the message switching function turns out to be right, then this component could take us eight engineering months. Hang on, if I am right then the only person who has experience of that is Jane and she is on leave for a month when we will need her so make that nine engineering months because she will need time to get back into it! Notice the skew — when things go wrong, they really go wrong.

Once you have your three estimates you draw them together by multiplying the most likely by four, adding the smallest and largest and then dividing the total by six. To get the total cost or size for the whole system you add the results for each of the individual entities.

Let us work through a very simplistic example of this technique. Let us assume that I have an extremely simple development project that consists of two functional entities, Fl and F2. Further, assume that I have data from a previous project of a similar type relating to two functional entities that have been delivered, R1 and R2. The data for these is given below:

ENTITY	COST
R1	50 person days
R2	100 person days

I now consider the work I have to do in terms of the reference entities. Let us say that in my opinion, F2 is a bigger component than R2 and that F1 is bigger than R1 but smaller than R2. So ranking gives me:

R1

F1

R2

F2

In this case the ranking exercise is trivial as we are dealing with so few components but in real life projects of many units it is a worthwhile exercise.

The next step is to produce estimates for the two components that have to be developed. To do this I may use Delphi or analogy or simply expert opinion. The key is to provide the three types of estimates already mentioned, a Minimum, Most Likely and Maximum estimate.

So:

	Min	ML	Max
F1	40	60	90
F2	100	140	200

Notice that the ML estimate does not necessarily fall half way between the Min and Max estimates.

To calculate the estimates for F1 and F2, I apply the formula:

Estimate(Fn) = (Min(Fn) + ML(Fn)*4 + Max(Fn))/6

So:

Estimate(F1) = (40 + 60*4 + 90)/6 = 62

Estimate(F2) = (100 + 140*4 + 200)/6 = 143

Estimate(Total Cost) = 62 + 143 = 205

One word of warning: you should watch out for the accumulation of rounding errors on projects of many functional entities. I suggest you work to four decimal places and then round your final answer to whole days, or months for very large projects.

There are other statistical techniques that you can apply but most practitioners are wary of this as the basis for the whole thing is still subjective opinion and you can convince yourself of "certainties" that, in reality, are built on very weak foundations.

The next technique I suggest is one of my favorites because it is less dependent on personnel opinion and it can be applied and improved very quickly. It depends on historical data but one project gives you enough to start with. It is also very conceptually simple. This is always a good point.

---