How to handle Project Risks that become Realities

Do you see yourself as a realist?

It’s impossible to foresee the future, so why waste time trying…

Or do you see yourself as a compulsive planner, constantly considering a range of possible events that could impact your project?

Apollo 13 or Titanic?

Some project “events” will causally walk up and bite you. No warning growl. No alerting bark. Just a nasty event with its teeth sunk deep into your project’s leg. These are what I call “Apollo 13 events”. Regardless of the planning and preparation, there they are … with an evil grin, standing in the way of your project team … just waiting to explode.

Luckily, most project “events” evolve slowly and, for the observant project manager, provide some time to react before they actually become a reality. Some might retroactively classify the Titanic disaster as an “Apollo 13 event”, but I challenge that. The Titanic’s “unsinkable” myth, created in marketing of the ship, initiated a false sense of security among the crew and passengers. The resulting risks grew in impact as they became linked together.

The Titanic-iceberg event may look similar to the Apollo 13 explosion at its trigger point, both were sudden, dramatic and unexpected events, but the Apollo 13 event had a much more positive outcome.


“Houston, We Have a Problem”

In “Apollo 13”, the movie, the project managers are seen sweeping their work tables clear of charts and tables, to “start over” when the significance of the on-board explosion was understood. Such a dramatic clearing-of-the-decks may have been a realistic reenactment of the scene, it glossed over the “foundation work” upon which the support teams built their success. I agree that risk analysis and planning are not much for The Big Screen and that “foundation work” is often downright boring. But it was the years of planning, training and preparation that went into the management structure supporting that Apollo mission that brought those astronauts home. While the management team did not expect the explosion, they were prepared to act and respond in an organized manner.

To be successful when project risks do become realities, a project team should proactively build a foundation for risk management including risk definition, analysis (of probabilities, impacts) and mitigation/response plans. Working without risk management could be viewed as working without a safety net. You might survive a small misstep, but a fall could prove fatal.

In my project management experience, maintaining the risk register (risk management documentation) is not a popular project task. We all know that it’s important, but few of us particularly like to perform it. It’s not flashy and few people (outside of QA) seem to care much about it, until something goes wrong.

Managing Risks instead of Reacting to Them

Instead of using the risk register as a “QA check off” item, I strongly recommend that teams take its maintenance and update seriously. As noted above, proactive risk management often reduces risk impact and negates the need to react radically.

A single action taken early enough in a risk triggering sequence can completely avoid an event occurrence. The challenge is to see the initiation of the triggering sequence, not the end of the sequence (aka the event trigger). The observation of that initial change can most easily occur if the risks are routinely monitored and updated. (Risk management may be boring, but it can be extremely effective.)

When Your Ship Does Hit an Iceberg …

This is where the preparation pays off! Depending on the event, pre-positioning contingency resources can turn an “impending disaster” into just a “significant event”. Obtaining additional staff resources or additional funding to handle an event takes time. Reacting slowly to an event generally intensifies its negative impact. Preparation and planning are not glamorous tasks, but completed properly, they can plug a hole before “the ship” begins to list.

Clear understanding of the relative importance of project targets and goals can also turn a “major event” into just a “missed target”. When confronted with a the prospect of a missed timeline target, experienced project managers will often drive their teams harder to deliver. In a 2008 Harvard Business Review article, “The Experience Trap“, an international team of researchers highlighted how experienced project managers are often so tied to common delivery constraints (especially budget & time) that they ignore solution options before it is too late to employ them effectively.

though the managers had encountered similar situations on their jobs in the past, they still struggled with them in the simulations

The experienced managers still selected solution paths that maintained cost and timeline targets, in spite of the significant and probable risk to product quality or HR issues. The managers overlooked the option of working with stakeholders (and the project sponsor) to revise a project’s initial targets. A quality product delivery with a missed timeline target can still result in an effective delivery. It just means that the project manager cannot claim achievement of the Holy Trinity (on-time, on-scope, on-budget). A project that delivers on-time and on-budget, but with poor quality can rarely be called “successful”.

While we may not be able to predict the particular iceberg or explosion that might impact our projects, we can identify general risks and prepare accordingly. We can routinely monitor risks (scanning the horizon) to see if probabilities or potential impacts increase. We can prepare (pre-positioning resources / funds) for potentially high impact events and reduce the “surprise” of active triggers with monitoring (setting a bow watch while sailing across the North Atlantic).

As project managers, we don’t have control over everything, but with risk management processes, we do have significant control of our project’s destiny.


Related Articles:

  • The Experience Trap“,  Kishore Sengupta, Tarek K. Abdel-Hamid, and Luk N. Van Wassenhove, Harvard Business Review – February 2008

4 responses to “How to handle Project Risks that become Realities

  1. An interesting and thought-provoking post. I totally agree with your comment about the popularity of maintaining a risk register. In my experience, when things go wrong there are always plenty of people who make comments such as “well, that was always going to happen”, or “I could see that coming”. And when you probe into what they’re saying, they are often absolutely right – they did know that it would go wrong, and they can pull out all the evidence which made it inevitable. But those things never made it into the risk register. The trick is to re-frame the process of compiling the register in the first place. A technique I learned many years ago works like this:
    Instead of starting to compile the register along the lines of “let’s think what might go wrong”, we start by mentally moving the clock forwards to a future date when the project should be complete. And then we assert that the whole thing has gone badly wrong – it’s behind schedule, over budget, massive technical problems etc. We convince ourselves that it has not gone well. Then, in that frame of mind, we ask the question “what went wrong and how did we get into this mess?” It seems that by giving ourselves permission to acknowledge the failure, we make it easier to identify the root causes. And suddenly all those real, legitimate and otherwise unspoken risks come to the surface.
    If you just look at risks at the start of a project, when everything is shiny, new and everyone is full of good intentions and hope, there is a great reluctance to think about the prospect of failure.
    I don’t know who originated this technique, so I’m afraid I can’t attribute it to any particular theorist or practicioner – but I’m very grateful to whoever it was. It’s a brilliant technique and it works well.

    • You offer a great process for pulling “potential realities” out of a team. I agree that it’s often very difficult to get team members and stakeholders to highlight potential issues “when everything is shiny, new and everyone is full of good intentions and hope”.

      The other important component of risk management are the regular reviews of the risk register. Sometimes it takes several passes before team members get into a risk mindset. Once they do become engaged, they become extremely helpful especially in reassessing probabilities.

      Be sure to check out the research study from the Harvard Business Review, It’s a bit disconcerting, especially to those of us who claim to learn from our mistakes … but it makes important points.

      Thank you for taking the time to contribute to this topic.

  2. Gosh, how right you are, Jim – “a bit disconcerting”! Certainly demonstrates how we don’t learn from our mistakes. Perhaps all we’re really learning is how to take those things in our stride. It’s like “yes, we know things will go wrong, and we know we’ll cope whatever the issue, so let’s not worry too much – it’ll be okay”.

    • I don’t know if it’s more appropriate to claim, “It’s OK. I’m just an old guy and tend forget things” or “Don’t worry about. We all do this…”

      “Been there; Done that,” just doesn’t carry the same weight as it used to.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s