Tag Archives: Risk Analysis

Bringing a Project Possessed into Conformity…

[Joining Critical Path and Risk Analysis]

On large projects, it’s often common to have 8 or more parallel, relatively independent work streams active at the same time. While this may seem like a lot to track, it’s really not … until several start to act as if they had minds of their own.

Living In The Moment…

The project plan had been carefully laid out with the assistance of the subject matter experts. The work efforts had been decomposed into appropriate work breakdown structures and the associated resources assigned / scheduled with their functional managers. Life isn’t good, it’s GREAT!

Then, one by one, risk probabilities increase toward realities. On one track, a key resource takes an emergency family leave. On two others, the IT teams, scheduled by external business units, declared that they would be “unable” to meet the timeline on previously-agreed-upon interface development. Three other interfaces show issues with their test environments.

Seemingly overnight, the complex, but achievable, project becomes a project possessed! Everything that could go wrong is! Risk analysis? Yes that had been done, complete with mitigation plans, but no one could have predicted such a concurrent set of events. Where to start?

Not Everything is Equal

Project managers often make the mistake of holding onto what THEY feel are the most important project constraints … Cost, Schedule or Scope … and don’t consider alternatives before it’s too late.

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 resulting in 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.

A project that delivers on-time and on-budget, but with poor quality can rarely be called “successful”. As project managers, do we often become too focused on our own achievements (on-time, on-scope and on-budget), missing solutions or options?

Analyze the Events

When “everything” seems to be going wrong at the same time, look at the situation and your options before acting. Re-examine risk impacts to determine if there are any unexpected impact increases triggered by concurrent events. Your initial risk analysis might have missed something or a mitigation option might no longer available to you.

Critical Path Analysis – Nobody Wants to be Late!

With the initial analysis in hand, start looking for where additional resources and/or modifications might have the greatest impact. A task or group of tasks with missed targeted dates don’t necessarily mean that there will be a day-for-day impact to the project’s completion date.

A project is rarely just a collection of tasks linked together to be executed in a single series order or “path”. A project is usually an aggregation of semi-independent work paths that come together at specific points to deliver a final product or result. The Critical Path is the longest duration path of tasks that leads through the project.

If a delay occurs to a task along the Critical Path (red line in the above example), it can have a significant, day-for-day on the project’s end date. A delay in a task (e.g. Task E or Task I) on a secondary or “feeder” path might be important, but not quite so concerning. That feeder path task, while scheduled to occur on a specific date, might have other dependencies/lags that allow its later delivery without an overall project timeline impact.

To understand where additional resources / modifications can be most effectively utilized, the project’s Critical Path must be identified.

The determination of a Critical Path for a project can be complex if done manually. If a project management tool, like Microsoft Project, is used and the project dependencies are properly configured, it will point to the path for you. While there can be exceptions to this approach, focusing attention on Critical Path tasks first is generally a “best” practice.

Review the Project Priorities

Your project may still be on track today, but the probability of it being there at conclusion might be remote. Where are your flexibilities?

Go back to the documents that initiated the project and look at the priorities. Everyone would like cost, scope and budget to be maintained, but which one or two constraints would the project sponsor and other stakeholders find less important than the others?

It’s not uncommon to find that the prioritization of primary constraints is missing from the project initiation docs. Risk events and mitigation plans are rarely popular topics when the project is “new and shiny”. If that’s the case, go back to the sponsor and stakeholders to capture their priorities. Expect some level of negotiation to occur, as now you’re talking about a likelihood, not just a remote probability of a missed completion target.

“New” marching orders in hand, you can now re-cast your project and bring it into compliance.

[Coming soon … Avoiding Delivery Issues: Critical Chain Project Management]

++++++++++++++

Related Articles:

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.

Why?

“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