Tag Archives: Project team

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