Estimate Confidence Buffers, Risk Buffers and Management Reserve

"If confusion is the first step to knowledge, I must be a genius.”
                                                                                                - Larry Leissner

We’re nearing the conclusion of this series that started with the basics of scheduling.  I want to tie up a few loose ends, maybe clarify some inaccuracies and address some confusion I may have introduced.

As I developed this series on scheduling, leading up to the previous post on estimate buffers, I hopefully offered convincing arguments for including appropriate buffers.  In this post, I want to compare and contrast various types of buffers that are common.

I think the discussion I offered on risk buffers is consistent with other authors and industry practices, so I won’t belabor that discussion.  I will point out that risk buffers are included in the project (time and cost) budget and are managed by the Project Manager.

Literature and practices for improving estimate confidence are much rarer.  Therefore, there may be some stakeholder pushback for including these buffers in the schedule.  However, you can demonstrate through logic, reason, science and ethics that, in order to have a realistic schedule, these buffers, like the risk buffers, must be included in the schedule.  Like risk buffers, these confidence buffers are included in the project budget and are managed by the Project Manager.

However, you don’t want to “double count” your risks.  Let’s say you do a lot of similar projects.  For these, there will probably be a common pool of risks that are included.  However, if your estimates are based on historical results and sometimes these risks occur, then there is the potential that your Pessimistic estimates will already account for those risks.  You will need to adjust either the estimates or the risk buffers so they are in the schedule only once.

In contrast to the confidence and risk buffers, some PMs Pad their estimates.  Some project managers, after over-running the project schedule a few times, learn that their estimates are never sufficient and start adding arbitrary amounts.  “We go over by 20% every time, so I’ll just start adding 20% to the schedule.”  This may sound logical on the surface, but is actually bad for their credibility and for the PM profession.  (Look for more discussion on this topic in a future discussion of The Toyota Way.)  Stakeholders learn that the PM is padding and, in response, start cutting the budget or otherwise compensating.  Pad is Bad.

In contrast, neither confidence buffers nor risk buffers are arbitrary.  Hopefully, if you’ve followed the discussion this far, the reasonable, logical and scientific justification for including these in the project are thoroughly explained and documented.

One last buffer that is sometimes seen in large, third-party project contracts is Management Reserve.  Management Reserve is separate from and distinctly different than estimate confidence buffers, risk buffers or pad.  Management Reserve is contingency funds allocated for use by the contract owner (sponsor).  These funds are not part of the project budget and are not available to the Project Manager except after approved project change control to authorize allocation to the project.

I hope this series has been interesting and informative for you.  One last remaining post and then we can move on to new topics.

Was this discussion scheduling and estimating clear and thorough?  Is there anything I missed that you would like me to address or anything that is still not clear that I should expand on?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Manager’s Cycle – Publish the Project Status Report

“Project status this week, in a nutshell, is that we are continuing to stay on schedule, but this is despite your team’s contribution.”  After the initial chit-chat, Srini intentionally opened the status meeting with a statement to get everyone’s attention, especially the Sponsor and Owner Jack.  “Our project team has been working around the delays of returning document reviews and approvals.  We’ve pretty much exhausted the continuing work, though.  As you can see on the status report, there are several deliverables over due for approval and the draft requirements document is held up.  If you think these durations will continue, then I recommend that we extend the time your team is allocated for these activities and extend the time line.”

With this post, we conclude documenting the activities in The Project Manager’s Cycle, the Monitoring and Controlling activities that the project manager performs each reporting cycle for the life of the project.  All of these activities (with the exception of the Client Project Meeting) build each week to the Project Status Report (PSR).  The PSR encapsulates all of the information the Sponsor/Client/Owner and all Stakeholders need into a compact package.

The PSR should document both the current status of the project (in summary) and progress since the last report.  The essential elements of the PSR include an Executive Summary, Accomplishments, Planned Accomplishments (in the next reporting period), Deliverable/Approval Status, Change Request Status, and Issues.  Accomplishments and Planned Accomplishments are reported relative to the plan (project management is the classic example of Management by Objectives).

Note that traffic lights (  Red,  Yellow,  Green) are not in my list of essential elements of the PSR.  I am ambivalent about them.  When used properly they are often valuable, but they are even more often used improperly.  If you use traffic lights, the meaning of each color must be defined clearly and all of the stakeholders reading the PSR must know what each color means.  Further, a single light is really not meaningful.  After all, the ultimate purpose of the lights is to show where external action is needed and one broad status doesn’t provide the specificity needed.  Rather, what I’ve seen that works best are lights representing Schedule, Scope, Budget, Resources, and Closure/Acceptance repeated for each project phase or (preferably) each deliverable.

The PSR is probably the most important document the PM produces and I can’t cover all of the nuances in one post, so expect to see more on other elements of the PSR in the future.

Do you have a project status report best practice to share?  How about a PSR disaster?