Recently in Risk Management Category

Part four of my taking-on-the-myths series will challenge our statistically minded segments: the risk managers.
 
Myth 4: Using Monte Carlo simulations to generate contingency budgets or schedules is an appropriate approach and should be more widely adapted.
 
Truth: Monte Carlo simulations are needlessly complex and shouldn't be used.
 
Of the three most common risk analysis methods used in creating a contingency schedule or budget--risk classification, decision tree analysis or Monte Carlo analysis--the latter is by far the most complex, so naturally it has the reputation for being the most robust.
 
But is it really?
 
Consider the data points your Monte Carlo simulation driver asks of you: original budget (or duration), one or two "things-going-wrong" alternatives, their odds and costs, and at least one "things-go-great" scenario, with its odds and estimated costs.
 
This is the exact same data set that would support a single-tiered decision tree analysis, except that the Monte Carlo version invokes a random-number generator to fill in hundreds (or even thousands) of other data points, which can then be used to analyze confidence intervals--at least supposedly.
 
But all of these other data points are artificial! The ensuing confidence intervals are far from reliable, hoopla notwithstanding.
 
Myth 3: Risk management is so important to project management that it should be employed throughout the project's life cycle.
 
Truth: After the baseline is set, formal risk management is pretty useless.
 
This last assertion is guaranteed to invoke a passionate debate, but consider your personal performance. Do you function better when you are confident or when you are worried? And what does formal risk management bring to the table once the project is underway, other than institutional worrying?
 
Analyzing ominous trends or performance information indicating a problem in order to head off threats to project success is what project managers do on a daily basis. Spending excess time quantifying those threats doesn't improve your odds of success.

I've been discussing stakeholders and communication for some time now without focusing on the key question: Why do stakeholders matter? Well, on most projects, stakeholders equate to risks.

There are a few risks that don't involve people--inclement weather, for example--but 90 percent of the risks on most projects are caused by one or more people:

•    Quality risks  almost always occur because people do not follow or not understand processes.

•    Design risks are usually the result of people not communicating.

•    Time and cost risks typically tie back to the performance of people doing the work.

•    Even inclement weather is influenced by people's perceptions--what's deemed "too wet to work" in a temperate climate may be seen as okay in a tropical monsoon climate.

People also determine if a risk is acceptable or not. Whether a risk is perceived as acceptable or not is 100 percent inside a person's mind.

As project managers, our job is to reduce risks to a level that gives the project the best overall chance of success. Yet extreme risk aversion will kill a project more effectively than a gung-ho attitude.

Of course, what constitutes a sensible level of risk is totally dependent on the perceptions and risk attitude of your key stakeholders.

That's why a central part of effective stakeholder management is ascertaining the risk attitude of your stakeholders. And then you must either adapt the project to fit within these parameters or provide the necessary information to help the stakeholder change his or her perceptions of what is acceptable.

The more that people feel they understand a situation, the more willing they are to accept risks.

Similarly, if you have a trusting relationship with someone, you're more likely to rely on their capability to safely manage risks on your behalf.

The most useful risk management strategy you can use on your project is effective stakeholder management supported by good communication. What has your experience been?

Time and again we see projects with a trail of issues that, if not dealt with, build up into this "issues bag," as I call it. The further you get into the project, the bigger and heavier the bag becomes--making it harder to control.

Carrying around these unsolved issues creates several risks.

1. Schedule risks: The project isn't completed on time because the issues left unresolved have caused delays in project activities or phases.

2. Budget risks: An unresolved issue creates a requirement to redo the work. If this work isn't done within the allocated timeframe--when it's still possible to refine requirements and while keeping the changes within the scope of the project--any changes would require additional funding.

3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team. This would impact other departments--and their time and money.

So how can you make sure the issues bag is empty at the end of the project? Here's what I suggest:

•    Keep track of the issues.
•    Maintain a list of the risks involved with these issues.
•    Keep a list of assumptions about what? and validate them.
•    Maintain a list of all changes executed during the project.
•    Perform quality assurance and close-out any outstanding quality? issues.
•    Ensure appropriate user-acceptance testing phases and garner signoff on the testing.
•    Pay attention to the organizational and business environment your project is impacting and any issues that arise.
•    Notify systems support teams of any impacts that may be caused by your project, directly or indirectly.

In my continuing series on commonly held but, in my opinion, highly suspect project management practices, I want to ask the question: Exactly what do the risk analysts do that improves a project's ability to come in on-time, on-budget?

Now, as the firestorm I've just ignited races to engulf me, let me be crystal clear about what I'm asserting. I am not saying that risk management is without value. What I am saying is, once the contingency budget and/or schedule have been baselined, the value of the information produced from risk-analysis techniques drops off dramatically.

U.S. General Dwight D. Eisenhower believed that once you're on the battlefield, all plans were out the window. And, while (most) projects don't approach the level of chaos and mayhem associated with a battlefield, I think his ideas are highly applicable in our works. That's what project managers do; they respond to the changes in circumstances, resources, demands, and hundreds of other parameters, every single working day.

The notion that project management decisions can be quantified and reduced to formulaic responses in most circumstances is absurd, and furthering that approach using excessive statistical jargon does not automatically make it legitimate.

As for the assertion that risk management includes an "upside risk" component--a.k.a. opportunity management--I would like to point to the Unabridged Webster's New International Dictionary, Second Edition. Its definition of "risk" reads, in part, "Hazard; danger; peril; exposure to loss, injury, disadvantage or destruction."

Indeed, nowhere in the definition will you find any reference to any possibility of a positive outcome or environ, much less opportunity. And yet, you see people make the comparison risk management equals opportunity management.

I know the risk management aficionados have had a lot of success re-defining the verbiage associated with their area of expertise in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) space, but isn't there another way of furthering risk management notions without pounding away at the lexicon?

Within the realm of project management--or any other complex system, for that matter--accurately identifying failure is difficult to the extreme. There are simply too many parameters to isolate, which makes writing about management a precarious proposition.  

Oh, there are certainly those cases where a project manager insists that no cost or schedule management systems be used, and it doesn't take long to drive that project into the ground. But in most other areas the link between act and consequence is not nearly so stark.

Renowned psychologist, B.F. Skinner, wrote that a variable rate of reinforcement virtually guarantees a behavior will continue. If that is so--and I believe it to be--then it follows that a practitioner who has experienced success using a particular technical approach may be inclined employ that approach over and over--even when it fails over half the time. That same practitioner might also be inclined to join with like-minded project managers to advance a new model or structure for success.

Their assertions may be correct and insightful universally, in some specific environs, or completely off base.

I entitled this post "Part 1" because I intend to take a close look at some conventions that may have been adapted in that spirit and without the scrutiny of an iconoclastic wise guy such as me.  

Next up:  Does risk management really help bring in projects faster, cheaper or with higher quality?

See relevant research from Project Management Journal® as reported in PMI Community Post: Avoiding Project Failure by Managing Organizational Culture

How many times has this happened on your team? An engineer switches off his machine on a Friday evening, enjoys his weekend, only to come back on Monday to find out the computer won't start or connect to the network. It's a very common problem--and for teams like mine that are close to 50 people--it occurs nearly once a month.

It takes the IT team a day to get everything working again, which may push back an already delayed schedule. How do you prepare the mitigation/contingency plan for this kind of risk? It may seem minor, but how many of us even identify these types of little things as risks? We should.
 
In this instance, I suggest the project manager keep a backup machine with the required software and hardware ready for the team. I know it will cost more money, but if you are able to save a day's effort every month then it would be justifiable.

How do you prepare for these seemingly "little risks"?

See the article, Plan for Everyday Risks, Brace for the Ordinary, by Carl Pritchard, PMI-RMP, PMP, published in April in PMI Community Post.

Risk exists at all times. The less planning we do for it, the higher the chance of failure or uncertainty of results.

I am a strong believer in integration. Therefore, risk management must be an integral part of any organization's project management methodology.

Risks are generally identified, assessed and quantified. Risk is then monitored until it is no longer a risk or to ensure that any events identified as a risk do not actually go unanswered. That's where risk response comes into the picture.

Response to risks comes in the form of:

-    Acceptance
-    Rejection
-    Mitigation

Organizations must ensure they:

-    Identify key risk-management processes to map them out to the organization's processes for project delivery
-    Identify risk factors (i.e., elements that cause probability of risk occurrence to increase)
-    Standardize risk identification, assessment and quantification, and documentation across the organization

Think of it this way: Risk equals money. It's the amount of money we are going to spend (or not spend) on either activity A or B. If we identify a risk of executing activity A for a price of X, but have a moderate to high level of confidence in success of this activity, we may choose to forgo doing anything else or delay the activity to remove or reduce the risks.

If risks end up being realized and we end up facing the results of it, the cost of it would be linked to loss of revenue and added support to resolve the issue that was created by unresolved (but accepted) risk.

And if it is less expensive for an organization to actually accept the risk and deal with its impacts rather than continuously applying resources to making things perfect, then the justification of taking risk from financial standpoint can be very convincing.

How do you work with risk?

The primary capital ship of most blue-water navies is the aircraft carrier. According to Rob Stern, in U.S. Battleships in Action, Part 2 a pair of aircraft carriers can deliver around 35 tons to a target in one hour. A United States Iowa-class battleship can do the same job in 90 seconds.

The U.S. Navy has four of these battleships, but, fortunately for enemies of the United States, only one is in the reserve fleet, while the others have been converted to museums.

Why is such a clearly effective weapon not in use? It may be because of the relative ease with which aircraft carriers sank battleships during World War II, leading to the conclusion that the carriers were superior naval vessels in all respects.

In the epic struggle to advance project management capability within our organizations, I think it's important to recognize that we are in competition with other management approaches and information streams. And in this competition, we may be failing to use the most powerful weapon in our arsenal: the capability of an Earned Value Management System (EVMS) to predict the future.

Accurate prediction of the future is obviously a very useful capability. In the project management world, the key pieces of future information include: How much will this project end up costing, and how long will it take?

These twin brass rings of project management information are hotly pursued in a variety of ways--most of them incorrectly, in my opinion. The most common approach is to re-estimate the remaining costs and duration of an on-going project, and to then add that amount to cumulative costs or duration.

This method, despite being notoriously inaccurate and injecting hundreds (if not thousands) of purely subjective data elements into the mix, is often defended as the only appropriate approach.

Conversely, the best approach--calculating the estimate at completion (EAC)--is commonly derided by so-called project managers, even though it's faster, easier and demonstrably more accurate than its re-baselining counterparts.

The most familiar EAC formula, the Budget at Completion (BAC) divided by the Cost Performance Index (CPI), can be algebraically reduced to dividing the cumulative actual costs by the project's percent complete. This formula works with durations as well: Divide the cumulative duration by the percent complete, and you have an accurate idea of how long a given task will take.

With such an easy, simple and powerful weapon in our arsenal, why aren't we using it more?

Even on Mars, projects budgets and teams are shrinking.
    Five years ago, the U.S. National Aeronautics and Space Administration (NASA) launched its twin Mars rovers, Spirit and Odyssey. Since then, they've been taking a beating. An article published this week in the Columbus Dispatch reports on how the Mars rover project team has seen continual success despite being forced to do more with less, partially due to the resilience of the machines themselves.
    "They're like that old Volvo or Honda in your driveway--they keep running and running," said John Callas, rover project manager at NASA's Jet Propulsion Laboratory in Pasadena, California, USA.
    And it's a good thing, too.
    Earlier this year, NASA proposed slashing US$4 million from the project's US$20 million annual operating budget--which would have meant putting the Spirit rover in "hibernation." But the rover team protested and the cuts to the US$800 million project didn't happen. But the team has seen some brutal cuts in staff numbers. In a five-year period, it has seen its ranks drop from 280 scientists and technicians to roughly 60.
    Going lean means sometimes making do with what's on hand. "We're learning how to make things work for a long time on Mars," said Geoffrey Landis, a scientist at the NASA Glenn Research Center in Cleveland, Ohio, USA and member of the rover science team. "The experience will help us make more capable rovers and eventually put people on Mars."
    What would you do if stakeholders proposed cutting 20 percent of your budget for the year? Would you protest or absorb the cut? And have you been on a long-term project that has seen team size drop drastically?

Ready or not, for most of the world, the busy holiday season is here. And the excitement--and, let's face it, the stress--is pushing work to the back burner.
What's a project manager to do? In some cases, the decision has been made for you.
Take Aspen, Colorado, USA--city law prohibits construction within the city limits for eight days, from 25 December to 1 January.
    "It's really messing my schedule up, and at this time of the year, we need to take advantage of every good day," Gary Wesley, superintendent of a construction project in Aspen, told The Aspen Times. "I had a lot that was going to happen that week."
Project managers and construction workers interviewed by The Aspen Times and Aspen Public Radio this week seem to view the construction prohibition as a recent development.    But the city's Construction Management Plan Requirements Manual, which was revised 19 September 2007 and dated December 2007, clearly states: "No construction is permitted on ... federally designated holidays including: Christmas week (Dec. 25 - Jan. 1)."
    The situation highlights the need to exercise due diligence in the initial stages of project planning. It must may prevent a lot of headaches once delays such as the holiday season strike--and mean one less source of stress.
    How do you plan for the holiday seasons? Does work slow or just stop completely?