During the initiation and planning phases of a project we establish the baselines. Once the preliminary scope, schedule and cost baselines are defined we then conduct a risk assessment to identify the critical uncertainties associated with those baselines and incorporate mitigation and contingency actions to protect the project. This becomes the risk baseline. We define, analyze, track, and act on those risks throughout the project. I’m going to refer to this process as Primary Project Risk Management (PPRM), because there is another secondary set of risks that only emerge during the execution and control phase of the project. By “secondary” I don’t mean to imply that they are less important than the planning phase risks, just that they manifest themselves later in the project. In fact, they are just as much of a threat to project success as the primary risks, and, in my experience, they are often overlooked by project teams. I’ll call the process of handling these late emerging risks as Secondary Project Risk Management (SPRM). This blog will offer some insights and tips into SPRM.

The domain of SPRM is the execution and control phase of a project, and its focus is on protecting the project from the potential consequences of variances from the project baselines. Variances from the project baselines can be both intended and unintended. Intended variances are those variances that occur as a result of conscious changes that we make to formal project baselines or the processes we use to create our deliverable products. They can be as obvious as Project Change Board approved changes to technical, schedule, cost or risk baselines, or as subtle as deviations in the sequence and/or location of activities that are performed in well-established processes. I’ll refer to these self imposed changes as Out of Sequence (OOS) and Out of Place (OOP) variances.
Unintended variances are those latent changes that occur in our processes that un-expectedly manifest themselves as Out-of Family (OOF) performance data.

The problem is that OOP, OOS and OOF variances, whether intended or not, always,…yes always, introduce risk. Those secondary risks must be identified, analyzed, and handled with the same rigor and discipline as the primary project risks in order to protect the project.

Here are a few tips you can use for your SPRM:

1) First and most importantly, you must look for them! Provide templates and training to the project team members that will help them step back and look for OOP and OOS conditions and objectively assess their consequences.
2) OOF process behaviors can be very subtle, and it’s easy for those unfamiliar with process control to ignore data that should require action or to take ineffective, or even counter-productive actions. I would strongly recommend that project managers and team members become familiar with the ideas of W. Edwards Deming to better prepare them to recognize real OOF process data and take appropriate action.
3) Introduce the use of independent, or non-advocate reviews to evaluate key project performance records and baseline changes at periodic milestones throughout the project. These reviews should include a strong focus on OOP, OOS and OOF indicators, and should trigger a thorough cause network and consequences assessment when found.
4) “Freeze” critical product build processes. Require that a knowledgeable third party validate proposed process changes. It’s common for people involved in executing those processes to make well intentioned, but inadequately thought-out, and undocumented changes, because of schedule or resource availability pressures. The OOP and OOS risks that emerge from this behavior can be very serious.
5) Pay careful attention to the acceptance or repair of discrepancies that are found during the execution of processes that produce the deliverable products. These are by definition, OOF conditions, and their disposition must ensure that the risk they pose is thoroughly examined.
6) Ensure that process failures are thoroughly investigated and that the causes are understood and addressed. Superficial analysis/correction of an OOF condition, will come back to haunt you. I’m a firm believer that for complex systems, there is no such thing as a root cause (See my May 2012 Blog) for failures. So use a cause network to evaluate problems and address all of the primary contributors.