7

Say a work package (containing several tasks) is estimated to take between 320 (Most likely) and 480 (Worst case) hours of work (not duration) to complete. Because of some dependencies and the schedule and budget risk involved, you think it is wise to add an intermediate buffer at the end of this work package, besides an overal margin at the end of the project.

How do you determine or calculate this individual work package margin?

Do you use:

  • 2 x the standard deviation, as proposed by Mike Cohn in his book "Agile planning and Estimating", chapter 17.
  • PERT (in that case you also need an optimistic estimate): calculating the expected value for the schedule and a 2 x standard deviation for the margin
  • Just the difference between the Most Likely and the average of the two
  • Monte Carlo simulation, but this calculates schedule margin for the whole project. How can I determine which intermediate margins to use?
  • Any other formula

And what would be your justification for the proposed method? And your success rate ;-)

Thanks

Improve this question
2
  • Are there benchmarks for this activity either industry wide or internally?
    – Mark Phillips
    Mar 9, 2011 at 15:55
  • Could be internally, but not necessarily so. All available knowledge is accounted for in the estimate.
    – Stephan
    Mar 9, 2011 at 16:28

5 Answers 5

Reset to default
4

For me the real question is how good your estimates are. If they are wild-ass guesses nothing will really save them.

Anyway, I don't like:

  • Just the difference between the Most Likely and the average of the two. It seems like some magic formula which I can't really support with reasonable data.

  • PERT. It should probably increase your original estimates a bit but this approach still bases just on some estimates and not any hard data.

Other two seem better to me but they also are more tricky:

  • Standard deviation. To learn what your standard deviation is you need to use historical data for tasks you've completed. For this sole reason it's a better method than two above.

  • Monte Carlo. With this one I'm not sure what your approach is. Again this is a method which bases on some hard data, so I expect you make Monte Carlo simulation using you historical estimates and real working times. If so why don't you just base estimates themselves on Monte Carlo simulation instead of just calculating buffer this way?

If I'm not missing something you do need to use historical data (estimates versus real working times) at least in a couple of proposed methods. If so, my idea would be to use Monte Carlo simulation against your estimates to calculate new, better estimates which include your track record. There's a great article about evidence based scheduling which describes how you may do it.

In this case I would work on schedule you feel good with (whatever probability level makes you feel good). Then if you need some additional safety catch I'd add buffers which are based on schedule with higher probability of success. For example, after Monte Carlo simulation you get following results: 70% probability that you complete work package in 390 hours and 90% probability it'll happen in 475 hours so you have 85 as your buffer.

If you want to split this buffer into a couple of parts after some work is done simply split your work package into smaller parts and do the same analysis for both parts independently and add the result at the end of each one.

Note: I would prefer just to go with 90%-probability schedule instead of adding buffers to less probable one.

I use approach pretty similar to evidence based scheduling and it proved to deliver pretty good results as long as historical data is reliable so that would be my method of choice.

Improve this answer
2
  • Thanks Pawel. Good points to think about. A 90% probability would be good for internal projects, but might it not be a bit uncompetitive for external ones?
    – Stephan
    Mar 9, 2011 at 22:06
  • Percentages were from the top of my head. You and your company has to decide which probability you consider as reasonable one, i.e. not very risky yet low enough to be competitive. Besides often reasons for not being competitive aren't within the schedule itself but are imposed by the way organization as a whole works.
    – Pawel Brodzinski
    Mar 10, 2011 at 7:57
4

I have found a great blog post from Glen Alleman related to this topic, particularly how to use Monte Carlo analysis to calculate risk margin.

You can find it here.

Improve this answer
4
  • His approach is outstanding.
    – David Espina
    Mar 28, 2011 at 20:07
  • Yes. Definitely. I have a long way to go (and a lot to learn) to be up to his standards!
    – Stephan
    Mar 28, 2011 at 20:14
  • He writes to add the delta between the deterministic schedule and the 80% confidence level of the probabilistic schedule as the margin...but how? Buffer tasks? What does that look like and how do you build that in?
    – David Espina
    Mar 28, 2011 at 20:33
  • I believe these are time (duration) buffers, not budget buffers. I guess it are tasks with no assignments. There appears no rule of thumb to determine the lenght of the "inline" buffers, that will be for the PM to decide. But they should total up to the calculated project buffer.
    – Stephan
    Mar 29, 2011 at 9:29
3

What is "intermediate buffer"? What is "overall margin at the end of the project"? There is no such thing as "margin" for a work package.

The terms used in the question indicate that padding is used, which is a problem. In order to avoid padding and keep your schedule/cost realistic you should do risk management. Identify and document all negative and positive (!) events, which, if they occur, may change cost and/or duration of your work package. Estimate probability and impact of these events. Manipulate them all together outside of your work package. All together they will affect your contingency reserves:

enter image description here

Picture is taken from Rita's Course, 6th Ed, page 238.

Take a look at this quote as well (page 189, same source): enter image description here

Improve this answer
6
  • 'intermediate buffer' = a buffer somewhere in the middle of the schedule, to allow for risk and dependencies; "overall margin" = a buffer between the expected end-date and the committed end-date. I don't HIDE the buffers, on the contrary, I make them explicit! I'm afraid your interpretation is wrong.
    – Stephan
    Mar 9, 2011 at 15:12
  • You shouldn't have any buffers in your schedule/cost. It's PMBOK's interpretation, not my personal.
    – yegor256
    Mar 9, 2011 at 16:53
  • As long as contigency buffers are "clearly identified in schedule documentation", PMBOK doesn't care. Besides, Critical Chain is one of the scheduling techniques described, which is based on adding buffers to manage uncertainty. I do something similar, scheduling with most likely estimates, adding buffers where schedule risk is high.
    – Stephan
    Mar 9, 2011 at 22:13
  • 1
    There are no buffers in Schedule, according to PMBOK (If I'm mistaken please give a page number inside PMBOK). "Adding buffers to manage uncertainty" is called padding and shall be totally avoided in project management.
    – yegor256
    Mar 10, 2011 at 8:20
  • I am afraid we misunderstand each other. "Padding" is adding a buffer to individual estimates, but representing it as one figure. Hiding the buffer, in fact. I don't hide anything. On the contrary, because I work with a range of estimates, instead of a single point estimate, I cut out the possible 'padding' from the lower (most likely) estimate. Any buffer I calculate is presented apart from my estimate and is a separate budget. By the way, I you can give me the page number where "padding" is explained in PMBOK, I would be much obliged.
    – Stephan
    Mar 11, 2011 at 8:28
2

I would use the difference between a rough weighted average of the likely and worst case (320 and 480) and the most likely (320). The weights for each one would depend on how severe the downside is if the task runs late.

For example, you mentioned budget risk. If the cost of being late would be huge, use a weighting like 10% and 90% for Most Likely and Worst Case, respectively. If the downside isn't all that bad 50/50 and if its minimal 90/10

I've used this approach many times (for mostly internal calculations) since it accounts for the potential impact of tardiness and gives you room.

Improve this answer
0
2

What I think is very interesting in that regard is what Jurgen Appelo described in his blog: http://www.noop.nl/2009/07/your-project-will-suffer-from-power-laws.html

You might want to consider that as well, since it contains a lot of insight.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.