Buffers, tolerances - how do you approach them in your project management practice?

Question

• How do you apply them in practice?
• What tools do you use / what would you recommend?

Answer 1

There are a couple of risk management approaches that use impact x probability = buffer style approach. But I take my own minor deviation.

If you are working with a project with limited historical information, you are relying on a series of estimates. There are a lot of people who have had success with Optimistic/Most Likely/Pessimistic formula from PERT where Estimate = (Optimistic + 4x Most Likely + Pessimistic) / 6

I like that approach for the WBS and that generates my first critical path. I then go through my critical path and identify the tasks that appear to have the biggest "gap" between the most likely and pessimistic estimates. In my experience, these seem to be my problem children. I use the gap as the "impact", take an estimate on probability (as a percentage) and that becomes my buffer along the critical chain.

For example: Task A has the following:

• Optimistic: 10 days
• Most Likely: 15 days
• Pessimistic: 30 days

Initial estimate is 16.7 days. That 15 day gap between most likely and pessimistic is a big deal so I would talk. with the person who did the estimate and a couple of other people involved the project (regular risk management type brainstorming). Maybe that task depends on an outside consultant or some internal team and we would guess that there is a 20% chance that they the really worst thing would happen. Then that would mean a 15 days x .20 = 3 Day buffer.

Since I'm only doing this to my first critical path, I know I'm going to be missing some risks and missing some buffers. However, this this is pretty fast and gives some reasonable buffers to work with. I tend not to assign the buffer to the specific task, though. I normally "roll up" the buffers per phase/deliverable/milestone and treat them like a contingency reserve. Once the project gets rolling and you can get tell if your estimates are on track, you can revisit your first analysis.

Answer 2

I have seen rather unsophisticated approaches, e.g., add 20% to all of your estimates, to a very rigorous quantitative risk approach using expected value analysis, non deterministic distributions and Monte Carlo simulations.

I prefer the more rigorous and calculated approach. Using rule-of-thumb buffers that you simply tack on is a rather unprofessional approach in my opinion.

The application of your risk results in several approaches: One, you can calculate contingent reserves (not held at the project level) in dollars that can fund both known- and unknown-unknowns that may be realized. Second, you can calculate management reserves (held at the project level) that can be used to cover in scope but unplanned work. Third, you can target your budget and / or schedule within your probabilistic distribution that satisfies the level of risk you wish to assume.

Some common simulation tools are: @Risk, Oracle's Crystal Ball, and Deltek's WelcomRisk.

Answer 3

Both David and Matthew gave good answers, but I would also add - "it depends".

How complex is your project? How many vendors, new (unknown) vendors, stakeholders, etc.? Is this a new technology or one you routinely do? How long will your project take, a month, five years? All of these are factors, and will help decide how rigorous your risk management will be.

As David said, there are a number of avenues, from quick and dirty (projects where we have a lot of experience and fairly good 'expert judgement'), to far more complex projects that require a more focused and calculated approach.

Answer 4

In Critical Chain Project Management it is common to remove all buffer at the task level and instead add a buffer at the project level that is equal to 1/2 of the critical chain of tasks.

The advantage of this approach is that all of the uncertainty in the project is pooled. As the project proceeds, the objective is to finish tasks as quickly as possible to avoid consuming buffer. However, buffer is available to absorb uncertainty.

Answer 5

Aside from how you compute your buffers for each tasks, I've had an interresting presenting around the idea of buffer aggregation.

Following the student principle (people always do things at last minute), and another law which name I forgot that says : People always take all the time given to perform an activity, the rationale is to group all buffers into one large put at the end of the phase of your project (ie just before your milestone)

Only PM and some stakeholders know the exact content of the buffer, and you reajust its size after risks reviews, etc...

The benefits are :

• only one task in your project to manage buffering. Since this task is at the end you have no rescheduling hassle.
• you reschedule only when you have to, ie only when someone is late. If everything goes by the plan, you don't have to reschedule
• higher productivity as you hide buffers, so people are more likely to use the unbuffered time

Answer 6

Add buffer (visibly!) to any major external deliverable. Commit to the buffered date, and work with the team to deliver to the un-buffered date. Share both with your stakeholders and explain your approach.

I usually add one (and only one) buffer task/item to these milestones. It reflects the overall risk of delivering that milestone. It also acts as a "bank" you can draw down from when problems arise. As your project progresses, the bank will likely contract (sometimes it gets bigger as good things happen!!) Just keep it updated and use that as an indicator of the "health" of the milestone.

If you have two teams (for example Dev and QA) don't forget to include time for both teams on the project even if only one is active. (e.g. Dev needs to fix a bug and QA is blocked for 2 weeks while that happens. You either need to find other work for the QA to bill against for those 2 weeks, or you need to allocate their time in the buffer as well.)

As for tolerances... Not sure I understand what you are asking enough to know if more is needed on this or not.