Project Management

Facilities Management

Agile Project Management – Risk Management

Risk Management tends to take on one of two states in most companies, and as you may suspect are polar opposites.  There are the risk adverse who are fear centric, and the risk oblivious who are….. well just oblivious.  Both of these operating states are very common in my experience.  Based on my own client experiences, I have only come across about 3 or 4 out of 10 clients that have a healthy view of risk in that they recognize the value of good risk management and actively engage all levels in the corporation in risk awareness.

Let’s start with a top down view of a project from the standpoint of metrics and look at how risk may impact each.  At the highest level, the triple constraint evaluates three cornerstone aspects which holistically defines a project and establishes a scalable interaction between the three constraints.  These constraints are:

  1. Scope
  2. Time
  3. Cost

Scope Identified Risk

Scope identified risks should be the easiest to define if the Program Management Plan has a well-defined Scope Management Plan section and a well-defined Scope Baseline.  The risk of a scope change can thereby be restricted to To Be Determined (TBD) or To Be Confirmed (TBC) requirements that were loosely defined at the onset of the project.  This statement may draw some rebuttal, but please read on.  It is understood that the Statement Of Work (SOW) will not reasonably capture all explicit requirements that clearly define all deliverables; however, the derived requirements that were defined by the proposal team form part of the project requirements.  These additional requirements must be clearly stated and captured as part of the official input to the Project.

Time Identified Risk

Risks captured to identify impact to timeline must distinguish a specific tie to schedule.  These are sometimes difficult to distinguish separately from cost, therefore are often combined.  In some cases, the risk may identify a third party service or deliverable that may drive out schedule.  Availability of key resources, or an underestimation of due process could also be fair game here.  Another example may involve a multi-prong development of design options in order to hit specific recurring cost targets.

Cost Identified Risk

Risks captured to identify cost can identify either/or specify costs to execute the project or cost targets for the deliverable in cases where either the expectations or requirements specify this parameter.

Define a Corporate Risk Register Template

When constructing a risk register, there are both guidelines and rules that must be applied in order to build a purposeful risk management process.  Developing a corporate risk register template is very important in order to develop consistency for effective and efficient collection of contributions, ongoing management, and portfolio comparison evaluation.  A risk register must provide a qualitative assessment of project risk.  Qualitative assessment involves two main metrics to establish the probability and impact of each stated risk.  These two main metrics influence cost and/or time against the deliverables defined in the Work Breakdown Structure (WBS).  Each risk will define an Unfactored Cost which sets a Rough Order of Magnitude (ROM) amount.  The Probability defines the likelihood, and sets the calculated Factored Cost amount.  The Impact is a scaled number to categorize the severity of change which usually plays out as a timeline and/or deliverable configuration change.  The risk register must capture a clear impact statement to define the WBS element that is impacted.  In the event that a given risk is realized on a project (i.e. the probability increases to 100% or a pre-set corporate threshold), then this risk is incorporated into the project baseline through a Project Change Request (PCR), and is thereby entirely or partially retired from the risk register.  It is very important that a well-defined identification tagging is established.  In short, here are the minimum recommended risk register fields that need to be identified:

  • Risk ID
  • Risk Title
  • Risk Description
  • Update Date
  • Estimated Start Date
  • Estimated Expiry Date
  • Owner
  • WBS Element Affected
  • Probability
  • Impact
  • Unfactored Cost
  • Impact Breakdown Definition
  • Risk Strategy (ex. Watch/Mitigate/Accept/Transfer etc)

Define Allowable Risk Rules

As far as rules are concerned, the most important rule is that all captured risks must be clearly outside the risk owner’s scope of control.  As a secondary caveat, the risk should also be approved by the Project Manager (PM) before it is officially logged on the risk register.  Another rule that must be established is regarding the category of risk allowable for the formal risk register.  There are three categories of risk as follows:

  1. Known-Known Risk
  2. Known-Unknown Risk
  3. Unknown-Unknown Risk

The first category entails risks that the team knows exist and also knows or has evidence of the existence of that risk.  An example of a Known-Known may be the availability of an internal resource that is conflicting with a known higher priority company project.  Another example may be a foundation development tool that has a known bug that affects the quality of the supplied results.  Known-Known risks are valid.

The second category is likely where most risks will be documented.  These risks will identify challenges in achieving the requirements as defined.  Likewise, the risk register also captures opportunities which would represent the converse situation for a given risk description.  Let’s say that a requirement states a specific performance parameter that is assessed by the project team as over-stated.  If the project is structured to meet operability, then an opportunity could be captured to allowably relax that requirement.  If the cost/time is tight, then it would be captured as a risk. Known-Unknown risks are also valid.

The third category of Unknown-Unknown risks must be avoided.  These types of risks are more often than not based solely on fear and are always situational circumstances that are above the proposer’s pay grade.  The PM must handle proposed risk that falls in this category delicately because team members that identify with these types of stated risks often lack confidence in general.

An important rule is required to set boundaries and thresholds for total risk and individual risk dollar amounts.  There must be an established total risk budget.  For risk adverse companies, the risk register can easily tally up a budget that can work itself to a high percentage of the overall originally estimated project cost.  Individual risk thresholds must be established to ensure the most appropriate strategy is applied.  For example, it should be unacceptable to carry a high value risk as a Watch strategy.  These must be Mitigated and should have a fully developed quantified plan in place that is invoked when the probability trips a pre-determined threshold.

The last rule to set is the cadence for Project Risk Review.  Depending upon the size of the project and the dynamics, the risks must be formally updated to ensure each are current, and that the dates and assessed metrics are correct.

Conclusions

In conclusion, a company must develop a Risk Management Plan that objectively sets a conforming standard by which the risk processes are executed. All too often companies fall into one of the two polar opposite regimes I mentioned at the beginning of this blog post.  Fear based risk management can provide the optics of risk management control, but are easily invalidated if the proposed rules are applied.  As for the risk oblivious, the definition of Agile Project Management may need to be evaluated.  Agility and Risk Management are two essential ingredients to any successful Project.