Project Management Institute

Risk management for dummies

managing schedule, cost and technical risk and contingency

img SOFTWARE FORUM
    Harvey A. Levine

Lots of things make me nervous, but none like the sight of a sigma, that weird, E-like gizmo that signifies the sum of a series of (frequently obscure) variables, often raised to the nth power.

I was reminded of this phobia when I browsed through last year's series of articles on Decision Analysis in the PM Network. I‘m wondering if there are other people like me, who prefer a more visual and pragmatic approach. I‘m not knocking Monte Carlo, decision trees, and other probabilistic techniques; but, first of all, I‘m not mathematically oriented, and can't get comfortable with this stuff. I can't even pronounce Taguchi, let alone understand Taguchi methods. (Can we take something called “Fuzzy Logic” seriously?) Along with this discomfort with such mathematical processes, there is also some skepticism. Do these methods really get at the potential areas for risk, and assist us in taking proactive actions to minimize risk?

I wholeheartedly support the premise (PM Network, April 1994, p.20) that CPM and its various network modeling techniques cannot be relied upon as a sole determination of a project schedule or the basis for schedule-driven resource and cost planning. Certainly, we must recognize that we can rarely capture in such a CPM model all of the conditions that can affect the project schedule. It is, in fact, this potential for weakness in our project models that leads me to question these advanced mathematical processes. If we are acting upon suspect data, are we then prone to just moving from erroneous models to very precise errors?

Given the above, and the desire (necessity) to manage project risks, are there pragmatic means, other than these structured probabilistic techniques, that we can use to identify, quantify, and minimize risk? The answer, I believe, is a resounding “Yes!” And these pragmatic means are available to anyone using today's typical project management software and spreadsheet products.

Pragmatic Methods to Control Risk

First, let's agree that it is better to avoid risk (via better planning, not avoidance of opportunity) than it is to manage risk (or problems arising out of insufficient planning and contingency). Risk control requires proactive management rather than reactive management. Here are some of the major components of the Risk Management for Dummies approach.

Employ Strategic Planning Techniques.

•        Identify objectives and constraints.

•   Probe opportunities, threats, and issues.

•   Perform stakeholder analysis.

•   Gather project team early.

•   Gather widespread inputs and gain stakeholder buy-in to strategies.

Remember Murphy's Law: Everything That Can Go Wrong, Will Go Wrong.

Consider all undesirable perturbations and evaluate consequences.

•   Identify reasonable defenses.

•   How can they be avoided?

•   How can damage be minimized?

•   Compute allowances (time, resources, costs, quality) for the above.

Build in a Reasonable Time Contingency. Remember that a CPM or PERT schedule would normally represent the most likely duration of the project. That means, in essence, that the calculated end date is at the mid point of the range of dates that could be achieved. In this case, Zero Float means a 50 percent chance of meeting schedule. Is that good enough? Well, that depends on a couple of things.

The first one is: What is the penalty for missing that date? I can relate this to my philosophy for driving my car to various appointments. For a person who preaches the use of contingency, I am notorious for not allowing any contingency in my planning to get somewhere. My subconscious reasoning, I guess, is that there usually are no deleterious consequences from my being a few minutes late to a doctor's appointment or dinner engagement. In other words, there is an acceptable risk. On the other hand, if I am driving to the train station or airport, I do inject some contingency into my driving schedule. It is worth the time contingency to avoid the risk of missing a flight.

The message, therefore, is to evaluate the potential consequences of a schedule delay, and to factor in a contingency that is consistent with the degree of risk. Certainly, we would take greater schedule precautions in the case of a $10,000 per day penalty contract than we would in a contract without a delay clause.

But, getting back to the 50 percent issue. The project completion date, that is supposedly a most-likely calculation, is based on the workscope that has been defined to the system. If our model has not recognized several activities that might pop up later (a normal situation), doesn't the project completion date have even less than a 50 percent chance? How much time contingency should we allow for unidentified work?

The point is that we must allow a time cushion. How much of a cushion will depend on:

  • The degree of acceptable risk or penalty for delays
  • How complete the definition of the workscope is
  • How well the work will be managed (if pressure is not kept on the schedule, slips of up to 50 percent can be expected)
  • How active Murphy is on your job.

The easiest and safest way to build in a time contingency is to extend the project end date to a point where there is a comfortable amount of positive float. But this may not be practical for several reasons: it may not be cost effective; it may not be acceptable to your client; it may not fit with other programs associated with your project. However, it cannot be acceptable to proceed with a zero float plan if meeting the end date is important. If the end date can't be moved, then the work must be replanned to create a schedule with reasonable positive float (time contingency).

Replanning to gain schedule float can involve one or more of the following: selective overlapping of tasks; increased resources or use of overtime; reducing scope; outsourcing; alternate strategies. As the available time cushion is reduced, the alternatives are to take preemptive actions to prevent high-risk perturbations from occurring, or to increase efforts to identify all of the work as early as possible.

Also, when the schedule contingency is too small to allow slippage, more effort must be spent on managing task interfaces. My experience has been that as much time can be lost between tasks as in the execution of the tasks themselves.

Use Accomplishment Value to Supplement Float Analysis. Accomplishment Value, or Earned Value (a.k.a. Budgeted Cost of Work Performed) pertains to the measurement of accomplishment against the plan, once the work is under way. Normally, when we have a critical path schedule, we rely primarily on total float to see how we're doing. If we maintain the desired float, we assume that the schedule progress is satisfactory. This can be a false security. If you read the manuals on the use of the critical path method, you probably were told that CPM analysis helps you to focus on the work that is most critical. The problem is that we can be watching the critical items while the rest of the project gets less emphasis on maintaining schedule.

I monitor this by doing a periodic float analysis to see if more and more tasks are joining the “low float” group. The more tasks there are that have low float, the less room there is to manipulate the work to adjust for problems. This float analysis can be a very important early warning system.

But what if you do not have a critical path schedule, or do not feel comfortable with the float measurements? Are there other ways to measure progress and schedule risk? One alternative is to use earned value.

The EV method requires that we assign some kind of weight factor to each task. This can be resource hours or budgeted cost. Or it can be an arbitrary estimate that allows us to balance the value of each task against the others.

The capability to use earned value measurements is available in most project management software products. But it is rarely used, for two primary reasons. First, it asks the user to learn several new terms and acronyms. How about BCWS, BCWP, ACWP, CPI, SPI, CV, SV, BAC, EAC, and other alphabet soup terms? Second, the use of this feature is usually associated with cost performance analysis, a function that is not universally utilized. But, you need not be scared off by either the terminology or the costing aspects. It is quite easy and practical to employ just part of this earned value protocol, for measuring the rate of work accomplishment against the plan. Here's how.

Forget about the alphabet soup, except for these two terms: BCWS (Budgeted Cost of Work Scheduled) and BCWP (Budgeted Cost of Work Performed). BCWS is really the value of the work that was planned to be accomplished at any point in time, per the target or baseline schedule. BCWP is the budget for the work times the percent complete, at any point of time. In fact, why don't we rename these terms to Planned Accomplishment and Earned Value (or accomplishment value, if you prefer). You may even find that your software uses these terms instead of or in addition to the acronyms. You do not have to have a CPM to use this earned value technique. You do have to have a list of all the work to be performed (identified as tasks in your scheduling database), a schedule for the work, and some kind of weight factor for each task. If you are controlling only labor-based tasks, you can use the planned labor hours as the weight factor. If you are using mixed resource values, you will find that the planned task cost is the lowest common denominator, or weight factor.

To use the EV approach, identify your tasks, assign a cost (or other weight factor) to each task, and schedule all tasks (either manually or by CPM). The computer will calculate the BCWS, or Planned Accomplishment, for any point of time, by multiplying the planned percent complete of each task by the value (cost) of the task. If you are using a work breakdown structure, the computer will roll up the data to any level of detail. By summarizing to the highest level, you can get a weighted planned accomplishment curve for the entire project ... essentially a cash flow, or project expenditure, graph.

Now, when it comes time to progress the schedule, just enter the percent complete of any tasks that have started. The system will multiply the percent complete by the budgeted cost, producing the earned value. This gives us a weighted measure of accomplishment, which can be compared to the planned accomplishment. If the earned value (BCWP) is less than the planned accomplishment (BCWS), work is not being accomplished as fast as planned, and you can say that the project is behind schedule.

Monitoring the earned value against the planned accomplishment (the Schedule Performance Index) provides an early trend analysis to guard against poor schedule performance. We can assume that if the overall production rate is below par that the computed project end date is in jeopardy. This technique also works very well for monitoring the progress of subcontractors. I use a below par SPI to convince subcontractors to put on additional crews to get back on schedule.

Build in a Managed Cost Contingency. Cost contingency, also called management reserve or “water,” is often frowned upon because it is incorrectly used as a cushion for poor performance, rather than a managed reserve for unidentified work. A properly priced job (where the market will allow it) will have three cost components: the work budget, management reserve, and margin.

The first item is the budget for the identified work. It is the sum of all task budgets in your CPM (or other plan). It does not contain any contingency costs.

Management reserve is funding put aside for unidentified work. In most projects, we are not so perfect so as to clearly identify every work item to be performed. Just as we can surely expect occurrences that add time to our project, we can expect to discover cost items that did not go into the original plan. By excluding this contingency from the task budget, the latter remains pure … for measurement of progress and performance. Only when new work is defined do we move funds from management reserve to the task budget.

A log should be maintained of scope changes and their effect on the task budget, management reserve, and margin (and schedule). If new work is defined that will not be paid for by the customer, then the cost of that work is moved fom management reserve to the task budget. If new work is added by request of the customer, the tasks and their costs are added to the task budget, without touching the management reserve (I use an Excel spreadsheet to record all changes). Managing the contingency precludes any use of those funds unless the new tasks are defined and added to the CPM baseline.

If we put contingency directly into the task budgets at the start, we have no way of managing these dollars, and they eventually are considered as available for spending. If we have no contingency at all, we can almost be assured of overrunning the project budget. The answer is a managed contingency … the management reserve.

Manage Technical Risk. The avoidance and management of technical risk could warrant a whole additional article. Let it suffice here that technical risk must be addressed at least as much as schedule and cost. Here too, we need to take a proactive approach. As we scope out our projects and develop our plans, we need to ask: What if it won't work? What alternatives and options do we have? What is our backup strategy?

I can't help but wonder: if this approach had been taken on the Denver International Airport project, would the problematic baggage-handling situation have caused such a disaster? Are we prone to believing in our own infallibility? Whether schedule, cost, or technical design, we usually develop an appraisal that contains a most-likely scenario, and a potential upside and a potential downside. Then we say that the downside will never happen. Such thinking is suicidal. Preparing for the downside allows us to manage these risks.

Not Very Scientific, But It Works

Time contingency, float management, earned value analysis, management reserve and technical risk analysis are all very basic, nonscientific, practical means of managing and avoiding risk. All of these practices can be supported by commonly available tools such as project management software and spreadsheets. And don't forget the liberal application of common sense.

With over 13,000 readers out there, there should be many other opinions and techniques on risk and contingency management. Share your experiences and comments with me, via CompuServe 76153,1552. ■

Harvey A. Levine, principal, The Project Knowledge Group, Saratoga Springs, New York, has been a practitioner of project management for over 30 years and is a past chairman of the Project Management Institute.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network • October 1995

Advertisement

Advertisement

Related Content

  • PM Network

    Playing with Fire

    By Jones, Tegan With the coastline of an entire continent burning, a scorched-earth urgency had teams across Australia racing to control the damage. Between September 2019 and January 2020, bushfires ravaged…

  • PM Network

    Trees of Life

    By Hendershot, Steve The world needs more trees—and a lot of them—to stem the damage wrought by mass deforestation. Brazil alone is destroying the equivalent of three football pitches per minute in the Amazon rainforest…

  • PM Network

    Rising Risks

    By Nilsson, Ryan For as long as humans have been building cities, they have migrated toward the coasts -- for food, ease of transportation and any number of ecological benefits. Today, it's estimated that more than…

  • PM Network

    From the Rubble

    By Thomas, Jennifer Puerto Rico's infrastructure woes began long ago. But a series of earthquakes this year coupled with hurricanes Irma and Maria in 2017—which racked upUS$139 billion in damage—exacerbated the U.S.…

  • PM Network

    Trading Transformed?

    Blockchain—the technology that made cryptocurrency mainstream—is now entering the U.S. stock market. In November, the U.S. Securities and Exchange Commission approved a pilot project to use…

Advertisement