Why do we multiply the “most probable score” by 4 in a three-point score?

I used a three-point rating for one of my projects. Formula

Three Point Estimate = (O + 4M + L ) / 6 

It means that

  Best Estimate + 4 x Most Likely Estimate + Worst Case Estimate divided by 6 

Here

 divided by 6 means, average 6 

and less likely to get worse or better. Of good will, most likely an assessment (M) is what it takes to complete the job.

But I do not know why they use 4(M) . Why did they multiply by 4 ???. Do not use 5,6,7, etc ... why, in all likelihood, is the weighted four times value equal to two other values?

+8
estimation
source share
5 answers

I dug into it once. I cleverly neglected to record the trail, so this is from memory.

As far as I can figure it out, standards documents got it from textbooks. The textbooks got it from the original 1950s in statistical journals. The journal entry was based on an internal RAND report as part of the overall work done to develop PERT for the Polaris program.

And that where the trace caught a cold. No one seems to have a clear idea of ​​why they chose this formula. The best guess is that it is based on a rough approximation of the normal distribution - strictly, it is a triangular distribution. The bell curve basically assumes that the “probable case” is within 1 standard deviation from the true average score.

4 / 6ths approaches 66.7%, which is approximately 68%, which approaches the area with a normal distribution within one standard deviation of the mean.

All of the above has two problems:

  • It essentially made up. There seems to be no reliable basis for her choice. There is some kind of literature on operational research in which alternative distributions are argued. In which universe are ratings generally distributed around the true outcome? I would really like to move there.
  • The effect of increasing the accuracy of the 3-point estimation method / PERT may be more related to the division of tasks into sub-tasks than to any specific formula. Psychologists studying what they call the "fallacy of planning" have found that task disruption - "unpacking" in their terminology - consistently improves grades, increasing them and thereby reducing inaccuracy. So maybe the magic in PERT / 3-point is unpacking, not formulas.
+4
source share

Isn't that a good thumb working number?

the uncertainty cone uses a factor of 4 for the initial phase of the project.

enter image description here

The Software Assessment book by Steve McConnell is based on the "cone of uncertainty" model and provides many "thumb rules." However, each approximate number or thumb rule is based on statistics from COCOMO or similar solid studies, models or studies.

+2
source share

There is a conclusion:

http://www.deepfriedbrainproject.com/2010/07/magical-formula-of-pert.html

If the link does not work, I will provide a brief description here.

So, taking a step back from the question for a moment, the goal here is to come up with a single average (average) figure, which can be said - the expected indicator for any given 3-point assessment. That is, if I tried to execute the project X times and summed up all the costs of the project’s attempts for a total of $ Y, then I expect that the cost of one attempt will be $ Y / X. Please note that this number may or may not be the same as the result (most likely) depending on the probability distribution.

The expected result is useful because we can do things like adding a whole list of expected results to create the expected result for the project, even if we calculated each individual expected result differently.

The mode, on the other hand, is not even necessarily unique for each assessment, so one of the reasons that it may be less useful than the expected result. For example, each number from 1-6 is the “most likely” for a die roll, but 3.5 is the expected average result (only).

The rationale / study of the three-point assessment is that in many (most?) Real-world scenarios, these numbers can be more accurately / intuitively estimated by people than one expected value:

  • Pessimistic Result (P)
  • Optimistic result (O)
  • Most likely result (M)

However, in order to convert these three numbers into the expected value, we need a probability distribution that interpolates all other (potentially infinite) possible results beyond the limits that we created.

The fact that we even perform a 3-point assessment suggests that we do not have enough historical data to simply search / calculate the expected value for what we are going to do, so we probably don’t know what the actual probability distribution is for what we value,.

The idea behind the PERT estimate is that if we don’t know the actual curve, we can connect some normal default values ​​to the beta distribution (which basically is just a curve that we can configure in many different forms) and use these values by default for every problem we may run into. Of course, if we know the real distribution or have reason to believe that the standard beta distribution prescribed by PERT is wrong for this problem, we should NOT use the PERT equations for our project .. p>

The beta distribution has two parameters A and B , which specify the shape of the left and right sides of the curve, respectively. Conveniently, we can calculate the mode, average and standard deviation of the beta distribution, simply knowing the minimum / maximum values ​​of the curve, as well as A and B

PERT sets A and B as follows for each project / evaluation:

If M > (O + P) / 2 then A = 3 + √2 and B = 3 - √2 , otherwise the values ​​of A and B are interchanged.

Now it just so happens that if you make this specific assumption about the shape of your beta distribution, then the following formulas are true:

Average (expected value) = (O + 4M + P) / 6

Standard Deviation = (O - P) / 6

So, in the summary

  • PERT formulas are not based on normal distribution, they are based on beta distribution with a very specific form
  • If the project probability distribution corresponds to the PERT Beta distribution, then the PERT formula is exactly correct, they are not approximations
  • It is highly unlikely that the particular curve chosen for PERT matches any given arbitrary design, so the PERT formulas will be approximate in practice
  • If you don't know anything about the probability distribution of your assessment, you can also use PERT because it is documented, understood by many people, and relatively easy to use.
  • If you know something about the probability distribution of your assessment, which says that something about PERT is inappropriate (for example, 4x weighting in relation to the mode), then do not use it, use what you consider necessary instead.
  • The reason you multiply by 4 to get the Average (rather than 5, 6, 7, etc.) is because the number 4 is related to the shape of the underlying probability curve
  • Of course, PERT could be based on a beta distribution that gives 5, 6, 7 or any other number when calculating the average or even normal distribution or even distribution or almost any other probability curve, but I would suggest that the question is why they chose the curve that they made is beyond the scope of this answer and maybe completely open / subjective anyway
+2
source share

Ideally, these factors for O, M, and L are produced using historical data for other projects in the same company in the same environment. In other words, the company should have 4 projects completed as part of the M assessment, 1 within O and 1 within L. If my company / team received 1 project completed as part of the initial O assessment, 2 projects within M and 2 within L, I would use a different formula - (O + 2M + 2L) / 5. Does it make sense?

+1
source share

The cone of uncertainty was mentioned above ... it is a well-known fundamental element used in flexible valuation methods.

What is the problem with this? Doesn't it look too symmetrical - as if it is not natural, not based on real data?

If you are ever, then you are right. The uncertainty cone shown in the figure above is based on probabilities ... not actual input from real projects (but in most cases it was used as such).

Laurent Bossavit wrote a book and also made a presentation in which he presented his research on how this cone appeared (and other "facts" that we often believe in software development):

Software Development Leprechauns

https://www.amazon.com/Leprechauns-Software-Engineering-Laurent-Bossavit/dp/2954745509/

https://www.youtube.com/watch?v=0AkoddPeuxw

Is there any real data to support the cone of uncertainty? Closest he could find a cone that can rise up to 10x in the positive Y direction (so that we can be 10 times higher than our estimate in terms of a project that is 10 times longer).

It is unlikely that anyone will evaluate a project ending in a finish 4 times earlier ... or ... sigh ... 10 times earlier.

0
source share

All Articles