Taming Your Big Beastie Projects (Part 2)

Posted by Megan Cacioppo on September 21, 2016

Taming Your Big Beastie Projects Part 2 Header Image

Last week we started taking a look at one of the most complex and challenging types of projects to manage: Integrated Programs, otherwise known as “Big Beasties”. We reviewed their key characteristics and previewed the three major steps that must be taken to ensure successful execution, going into greater depth around Step 1: Program-Set up.

Today, we’re taking a closer look at the second step in the process – Program Schedule and Risk Analysis.

Program Schedule and Risk Analysis

For a complete and reliable schedule risk analysis, three things are needed: a good quality schedule, duration ranges (called duration uncertainty), and discrete risk events. If any of these pieces is missing, then the schedule risk analysis is not complete and is likely not reliable.

The purpose of a schedule risk analysis is to know what is possible. So, anything that restricts the movement of activities or doesn’t move because of missing logic should be fixed.

What does good quality mean?

  • Complete logic – In an ideal world only the start and finish of the program would have open logic.
  • Minimal constraints – Only “Start On,” “After,” or “Start No Earlier Than”.
  • No lags – Lags can’t be used in the risk analysis model, so they must be converted to an actual activity.

Once the schedule quality is high, the rest of the risk model can be assembled.

For Duration Uncertainty, a minimum duration and a maximum duration are determined for every activity in the program schedule. This is typically done by using a template that uses percentages that multiply by the Remaining Duration to create minimum and maximum durations. When the same Duration Uncertainty Template is used across an Integrated Program, it puts all of the program activities on a level playing field for evaluation. This is very important input from which the schedule risk analysis will determine the schedule drivers.

Likewise, the same Risk Matrix and Risk Register should be used across the Integrated Program. This ensures that discrete risk events are evaluated for probability and impact in a consistent way across the program. Once the Risk Register is populated, the risk events are attached (or mapped) to whatever activity(s) are impacted – regardless of the individual project within the program. This again drives consistency, common language, and determines the actual ‘cost’ in time and money of the risk events.

With the Schedule Risk Analysis model complete, the analysis provides the probability that the program overall, or its components, will be delivered on time.

Stay tuned for next week when we wrap up the series with a deep dive on Step 3: Program Cost Risk Analysis.

Can’t wait until then to learn more? Download our recent white paper on the topic, authored by Lorrie Tietze, Founder & Owner of Interface Consulting, LLC, or tune into the on-demand webinar, How to Tame Your Big Beastie Projects.