Estimates & Buffers

“A clever person turns great troubles into little ones and little ones into none at all.”

- Chinese Proverb

If you’ve been following the series on the well-formed schedule and the subsequent series of posts, you are aware that from the WBS you create estimates and iteratively refine those estimates by, for example, improving the probability of success and compensating for risk.  One of the PM challenges is how to balance motivating task owners, setting appropriate stakeholder expectations, reporting honestly and doing all of this in a forthright and ethical manner.

To demonstrate, let’s use our example task from Risk Buffers – An Example.  You might estimate that your Most Likely time for the commute is 30 minutes and the Optimistic time is 20 minutes.  However, the Expected (Mean) time might be calculated as 35 minutes (this is the 50% probability of success, where you’re as likely be early as late).  If you toss in one standard deviation to get to a 65% probability of success or two standard deviations to get to a 95% probability of success, the estimate could balloon to 45 or 55 minutes.  On top of this, then, you add those risk buffers, which might add 10-15 more minutes to the estimate.

Let’s take a look at this from your perspective with several of the stakeholders to examine the conflicts.  First, with the task owner:  Physics and Theory X management say that if you put that high estimate on the task, the task owner will take all of it.  In order to motivate the task owner, it is necessary to use, for example, either Most Likely or Expected.  In fact, I’ve managed projects in organizations that insisted that I use the Optimistic estimate and “stay on those team members” or they would just slack off.

Now looking at this from the perspective of your relationship with the project owner or sponsor, if you fill the schedule with fully bloated tasks (“What do you mean it’ll take 65 minutes to drive to the office!  I know full well it only takes 30 minutes.), you’ll lose all credibility.  However, if you use only Optimistic (!) or even Most Likely or Expected estimates, the end (date or cost) is not realistic and you’ve set yourself up for failure (as documented in The Schedule – Probability of Success). 

Some stakeholders want to know when it will really be done and how much it will really cost.  And they want to have realistic progress updates on these realistic completion values.  If you are not using fully weighted estimates, your reporting to these stakeholders will not be accurate.

Finally, another stakeholder that you have to true to is yourself (and the PM community).  How you address these conflicts must be ethical.

The conflict then is how to have individual task estimates that are under-weighted, but have the overall project estimate include the probability of success and risk adjustments.  The solution, of course, is to have “tasks” in the schedule that represent these estimating and risk buffers.  So let’s say you create these buffers and put them all at the end of the schedule.  This also creates reporting problems because there will be the appearance, at the start of the project, of a large gap between the end of the last deliverable and the end of the project.  It will appear as you progress and report completion of deliverables that you are (most likely) late on all of the deliverables.

At a minimum then, you need to distribute these buffers into each deliverable, spreading them over the life of the project.  You, as project manager, own these buffers and you have to deplete them as you go, continually reassessing much has been consumed by actual task overage and underage.

Since these buffers are included in the project (cost and time) budget, they cannot be arbitrarily reduced, eliminated, increased or created except through formal project change control.  They can (depending on the rigor of project change control) be moved between deliverables, but this should be documented.

Before closing I want to mention that the book Critical Chain by Elihayu M. Goldratt describes a formulaic approach to determine the appropriate amount and placement of the buffers.  This approach has been successfully used in many organizations and should be considered as an alternative to the custom and complex approach to buffers I’ve presented.  Further, he goes in to much more detail on the operational practices.

In my next post I’ll conclude this series on buffers and then we can move on to some new topics.

What challenges have you had convincing stakeholders to use realistic schedules?  Do you get pushback that you are just padding your estimates?  How do you handle it?

© 2013 Chuck Morton.  All Rights Reserved.

Risk Buffers – An Example

“President Bush has said that the economy is growing, that there are jobs out there. But you know, it's a long commute to China to get those jobs.”
                                                                                                - Tom Daschle

In The Schedule – Risk Buffers, the concluding post of a series on developing the well-formed schedule, I glossed over the complexity and details of planning project risk buffers.  I’d like to revisit the topic in more depth over the next few posts.

However, before I go into the complexities, I would like to present a very simple example, one I hope everyone can relate to, to demonstrate the concepts.  You are probably quite familiar with your commute:  you’ve driven it many times and you know what time you have to leave to generally get to work on time.  Even so, most commuters are occasionally surprised by unexpected traffic conditions – weather, wrecks, and road work, for example.  To demonstrate how to determine risk buffers, this exercise will touch on four of the six PMBoK Project Risk Management processes:  Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, and Plan Risk Responses.

For this example “project” we’ll only have one task:  Drive to work.  My next post will focus on identifying risks, so I won’t dwell on that step here.  For this exercise, let’s say you have these risks:

1.       There could be rain
2.       There could be snow or ice
3.       Ice could be so bad that your office closes for the day
4.       You are low on gas and need to refill before you can make it all the way to work
5.       There could be a wreck that causes a slow down
6.       There could be road work that causes a slow down
7.       There could be road work that causes a detour

(Do you see anything noteworthy about “risks” three and four?  I’ll have more to say about these in my next post.)

Something that is often missed or glossed over is dealing with Opportunities (the opposite of risk threats).  If your task is estimated to a 50% probability, there is as equal a chance of it coming in early as there is it coming in late, so you need to factor in and exploit (or enhance, share or accept) the opportunities.  For example:

8.       Traffic could be very light
9.       There could be a wreck in a location that causes your commute to be lighter than normal
10.   All the traffic lights could hit perfect for you today

The next step is to qualitatively assess the risks.  The objective of this step is to determine those risks you are going to seriously pay attention to – those that you will quantify, determine the risk response, and monitor.  It is generally done by assigning subjective Low, Medium and High values to probability (the likelihood that the risk event will occur) and impact (how the project is affected if the risk event occurs).  For example, if it’s August, the likelihood of snow or ice (risk #2) is Low.  From this analysis you generally then disregard the Low-Low risks (though note that these values can change over time, so you must periodically re-asses your risks).

The list is now winnowed down to the select risks that will receive attention.  Determine a specific (time, money or both) cost to the project for each remaining risk (including opportunities) if it occurs.

Most of what I read at this point talks about mitigating the risks, but there’s a lot more to risk response than just mitigation.  For example, add tasks to the project (such as check the weather or turn on the radio to get a traffic update).  In addition, risk responses can be transfer (ask a colleague to be there for you in case you can’t get there in time), avoid (reschedule to another day when it won’t rain) or accept (add the time and cost to the schedule).

Finally, and where this has all been leading up to, is to add a risk buffer to the project as part of the risk response.  For example, if there is a 25% chance that a risk will occur that will add twenty minutes to the commute, then you would add a five minute risk buffer to the project (in our example, you would plan to leave five minutes earlier).  You would sum the values for each appropriate risk and opportunity and add a buffer for the total amount.

With this step, you have again increased the probability of getting to the office on time – er, that is, of completing your project on schedule.

I’ll be delving deeper into risks over the next few posts using this example to demonstrate the concepts.  What about risks – threats and opportunities – would you like to understand better?

© 2013 Chuck Morton.  All Rights Reserved.

The Schedule – Risk Buffers

“The first step in the risk management process is to acknowledge the reality of risk.  Denial is a common tactic that substitutes deliberate ignorance for thoughtful planning.”

                                                                                                                - Charles Tremper

With this post, we conclude the series on developing the well-formed schedule.  We have taken the WBS, which defines the project scope, added the task dependencies, estimated the effort for each task, assigned resources to each task, and resource-leveled the task assignments.  The final step to complete the well-formed schedule is to add risk buffers so that the schedule has the intended probability of success.

A schedule without risk buffers has virtually no probability of success.  Since you probably want to present a schedule with some probability of success, it obviously follows that you must add some risk buffers.  So now you probably want me to tell you how many and where.

I’ll briefly identify two common practices for identifying risk buffers.  The first is built from the standard risk management process.  The PMI PMBoK risk management process includes the step “Quantify risks.”  You’ve probably wondered what this means.  For risks that should be mitigated, determine the probability of occurrence (a percentage) and the time and cost that must be added to the project if the risk event occurs.  Let’s say for a specific risk you determine there’s a 25% probability that it will occur and that if it occurs it will add 12 weeks (I’m just going to deal with time in this example, but you can extrapolate for costs) to the schedule.  The 25% probability times the 12 weeks is 3 weeks, meaning that you should add a risk buffer of three weeks to your schedule.

Depending on a variety of factors, you can either add all three weeks to the end of the schedule or spread it in appropriate points over the life of the project.

You repeat this for all significant project risks.

A very common alternative to this approach is to use the Critical Chain approach developed and promoted by Elihayu M. Goldratt.  It uses a formulaic approach to determine the appropriate amount and placement of the risk buffers.

This overview is obviously too high a level for practical application.  But with this post I’ve finally presented enough of the PM foundation so that I can introduce some of the more interesting and complex concepts.  I’ll do this starting with a couple of posts on advanced quantification of the schedules, then maybe transition to more fully explaining the development of risk buffers.

It’s taken me two years of posts to get to “the fun stuff.”  What area of project management best practice would you like me to tackle?