Contingency, risk and ensuring quality
by Lary A. Mars, PMP
HAVE YOU EVER BEEN on a project that you did not encounter at least one surprise during its life cycle? If so, you are one of the chosen few. If not, this article may help you be more proactive and realistic in planning the project, armed with the ability to manage yet-to-be identified surprises.
The real reason why project end dates slip and cost overruns occur is not so much the result of poor estimating as it is an incomplete project Work Breakdown Structure (WBS); in other words, the problem is not poor estimates on “identified” tasks, but failure to thoroughly recognize “all” tasks—the not-so-obvious (yet identifiable to the astute planner) ones as well as the unanticipated occurrences. Though there are many reasons for this, one of the most common themes is not enough planning time. Can you really plan for, and even estimate, an event that by its very definition—unanticipated—has little clarity? Yes, you can.
Risk Management is the Hot Topic. There has been much talk of late about risk management. Various books have been published on how to plan for risk. Some of these books have a level of complexity that is just not necessary. There are a few, however, that get a lot closer to meeting the day-to-day needs of most project managers.
One of my favorite books is Critical Chain by Eliyahu Goldratt . I had the pleasure of meeting Goldratt this past year, and we discussed Critical Chain in detail. To summarize the book, Goldratt's philosophy is based on the premise that we all include “safety” in our task estimates and the project manager should therefore cut every task estimate in half and tack on the entire amount of safety to the end of the project and call it “project buffer.”
I have both read about and conducted research on how team members estimate their tasks. It is safe to say that more than 50 percent do add safety into their estimates. Yet, others are so aggressive in their estimates that even if allowed their full estimate, they'd be late; so, to cut their estimates by 50 percent makes no sense at all. Since neither group at either extreme is likely to announce, or even admit if asked, its predisposition in making such estimates, the project manager is left in a significant—yet truly unnecessary—lurch. What we need to recognize is this thing called human behavior.
Lary A Mars, PMP, is president of Koala-T Management Consulting Inc., an international project management training and consulting solution provider headquartered in Aurora, Colo. He is also a speaker, trainer, consultant, and author. His Koala-T Management Process is used by several Fortune 100 companies for implementing project management and quality. He can be reached at [email protected].
Try This at Home. The following is something I've actually done to make estimating become real for project managers and teams. Put this estimating phenomenon to the test:
Go out and acquire a unique wooden puzzle, one that very few people have attempted to solve before. Make sure the puzzle is something that can be solved in a relatively short period of time, let's say, five to 15 minutes.
Show it to a group of 20 people. (It will be even more fun if you have a few people from the group have a chance to solve the puzzle on their own without showing anyone else in the group how it was done.) Then, go around the room and ask everyone in the room to estimate how long it would take them, by themselves, to solve the puzzle. Since most of the group have never seen the puzzle before, estimates might range from five minutes to five hours. Or, as one of my finest colleagues openly admits, “This type of puzzle? Never, ever, ever.”
Once you have received estimates from each person in the room, the next question gets a bit more interesting. Ask everyone what they believe is the likelihood that they could solve the puzzle in the time they allotted themselves, or less. If Goldratt is correct, and everyone is answering honestly, everyone will answer 80 percent or more. I believe that you will find that most estimators err on the conservative side, and fewer err on the aggressive side. Thus, you will see that there will be several with confidences of 75 percent or more, others 50 percent, and only a couple brave souls below 25 percent.
One of the keys to a project manager's success is to get everyone on a project team to start thinking consistently about estimating.
Go back around the room and ask everyone to readjust their estimates to 50 percent. This means there is equal likelihood that they will solve the puzzle in less time than their estimate and an equal chance they will take more time than their estimate.
Exhibit 1. This is a simplistic formula for justifying contingency through identifying the risk events, probabilities, and impacts.
You may find some resistance, as many would like to include safety in their estimates; they do not want to appear to be “wrong” 50 percent of the time. Now is a good time to explain to them that a project should not have any safety at the task level, but at the overall project level. Then, true 50 percent estimates even out over the life of a project. Tell them to consider this puzzle as a task in the overall project and that you will show them how to include safety at the overall project level later.
Too often there are multiple and redundant levels of safety, or contingency, embedded into an overall project plan. It is essential to a project manager's success that contingency is highlighted and visible. Hiding contingency only leads to inhibiting successful partnerships on projects.
Once you have received new estimates on the puzzle from each of the members of the group, ask them how confident they feel that their estimates are anywhere near reality. So far you showed them a puzzle that they have never seen before, and yet they were able to give you an estimate, give you a probability that they could or could not solve it, then were able to get them to adjust their estimate to a 50 percent probability!
Too often project managers get estimates from team members and have no idea what they are based on or how accurate they will be. It is important to educate our team members that providing estimates when they are unable to communicate a confidence level in the estimate is a very unhealthy environment to live in. If someone provided an estimate of 30 minutes, there is a difference if they are comfortable that they can get the task done somewhere between 27–33 minutes (tolerance of 3), versus getting it done somewhere between 10–50 minutes (tolerance of 20). I call this improving the “tolerance” of their estimate.
Ask those who gave you an estimate how they can improve the tolerance of their estimate without learning how to actually do the puzzle (just improving their estimates). I hope they will realize that if anyone in the room has already solved the puzzle, they should ask that person how long it took to solve it. Have a bit of fun with the group. If you know that someone solved it and can solve it again really quickly, ask that person, “How long would it take you to solve it right now?” He or she may say, “Less than a minute.” Turn to someone who estimated at least 15 minutes and tell that person that he or she has only have one minute to solve the puzzle. Ask what the more appropriate question would have been. The person may realize that you should have asked the one who solved the puzzle, “How long did it take you to solve the puzzle the first time you attempted to solve it?”
Another essential success ingredient is for the project manager to know who will be available on the team. If we plan a project around a subject matter expert to perform a task, then are supplied with someone less experienced to perform the task, our project will suffer. Either that task will be delivered late, therefore jeopardizing the project schedule, or more often, we will force the team member to perform the task in the allotted time, therefore jeopardizing quality.
Select one of the estimators who estimated at least 20 minutes and tell him or her to complete the puzzle in five minutes—or else look for another job. I'm sure you will hear that you just put them in “crisis management mode,” a state in which we often find ourselves. On the spot, the estimator will probably suggest handing it to someone who has done it before.
Short- or Long-Term Focus. Though the crisis was handled, discuss the difference between short-term and long-term visions. It would be more appropriate to not only involve a subject matter expert in solving the puzzle and the crisis, but also to prevent the crisis from happening again, perhaps through some transfer of knowledge as well as documentation.
Now that this puzzle is solved, take out a similar puzzle—one that looks the same from the surface, though, not visible to most, is unique and has an additional step to it. Ask everyone to estimate once again. You will find that most estimators will come up with however long it took the person to solve the last puzzle.
Now ask someone to solve the new puzzle. This person will most certainly stumble and realize this was a set up! It is important to realize that no two tasks are identical, and that “safety” is surely needed for unforeseen circumstances.
In Critical Chain, Goldratt describes one way of adding safety into the project estimate. After meeting with him and discussing his approach to safety, or “contingency,” we decided to simulate a work environment and put his ideas to the test. What we noticed by the third project, using the same project team, is that human behavior did indeed have an impact. Once the project team realized that the project manager was cutting each task estimate in half, though not realizing that it would later be added as safety to the end of the project, the team members were doubling their estimates to allow themselves what they believed they needed. Does anyone see a potential danger in this vicious cycle of mind reading and “out-strategizing” someone who is (or should be) on your side?
Armed with an understanding of the utility of contingency with identifiable tasks, consider now its use in effective risk management. Project managers need to plan for risks, which can be defined as the cumulative effect of the probability of uncertain occurrences that may positively or negatively affect project objectives. It is also the degree of exposure to negative events and their probable consequences characterized by three factors: risk event, risk probability, and risk impact.
Reader Service Number 005
We do need contingency to be available when risks become realities. Such planning for risk is not as difficult as many make it. The bottom line is that the more risks you are able to identify before you begin your project, the better chance you will have of being in control. If you are unable to identify your project risks before you begin your project, plan on being in a state of chaos. I firmly believe that open, honest communication between project manager, project team, and client is the best formula for success.
In formulating time and cost estimates for projects, it is common to add a contingency figure. This is an allowance for unforeseen time and cost and is a measure of the confidence in the estimate as well as the risk involved in the project. Contingency can be applied to total project estimates, or in the case of larger projects, to the estimates attributed to certain elements. The contingency figure will vary according to the size and type of project, risks involved, and the amount of estimating time and effort. It could vary from less than 5 percent for a low risk, repeat-type project to greater than 20 percent for a high risk, stranger-type project.
When the estimate is complete, the overall contingency figure should be calculated and analyzed. This figure serves as a good indicator of your confidence in the project. If you arrive at a high contingency figure, you may want to reconsider the risk involved with the project. Discuss it with the client to see if you can find ways to reduce the figure, or at least communicate and document the existence of such risk.
Keep in mind that the more detailed the WBS, the more accurate the estimate will be, because more of the project parts have been identified. The more time and effort that goes into planning, the more the project plan and its estimates will reflect reality.
In calculating contingency, it is first important for you to identify each risk event. As many risk events as possible should be identified during the information-gathering portion of your planning process. Once you have identified an event, additional information should allow you to know the probability that the particular event may occur as well as the impact to the project if the risk event becomes a reality. Contingency then takes into account all identifiable risk events. Some will become realities and some may never occur. A simple example is shown in Exhibit 1.
Estimators can be tempted to treat contingency as personal and to bury it where it cannot easily be found. This adds to the perception that estimating is nothing more than pure luck, at best, or, at worst, a way to deceive the client. This is unacceptable to effective project management, and you must seek to remove individual ownership of contingency.
It is also a myth that contingency is a sum of time and money to be consumed by right. Document its initial state in your Document of Understanding and include the process by which contingency will be reported. Communicate when it is being used; if 80 percent is taken in the first 20 percent of the project, it is time to reassess your initial estimates. As important as this knowledge is for you, you will also find a client much more receptive to such negotiations at this point in the process rather than just before scheduled completion!
I BELIEVE THAT our management and our clients will continue to “cut” contingency until we are better able to justify it. I also have seen that the more they “cut,” the more we as project managers “add.” It is a vicious cycle, a lack of communication, and neither we nor our clients or management win.
In the planning phase, we must gather complete information, not only about the scope of the project but also about the risks to project success, and then incorporate what we know we need to do into our WBS. If we can also stay close to the 80-hour-rule, keep our tasks small enough and clearly defined, and involve our project team in this planning process, we will need less contingency. However, we will always need some. Justify it through the Exhibit 1 formula, communicate better to management where it may go, and communicate during the life of the project when it does. You will soon find yourself better able to obtain the contingency needed to manage both the knowns and unknowns of your project. ■
PM Network December 2000