Visualizing risk management--a new approach

Abstract

Other than Quality Management, Risk Management is likely the most misused and underutilized knowledge area of A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth edition (Project Management Institute [PMI],2008). The importance of risk in project management is undeniable – poor risk management implementation equals a high probability of project failure. The majority of decisions made by project managers during the Execution phase subconsciously involve a decision to reduce potential risk downstream in the project life cycle.

Yet risk management remains a task that tends to be relegated to an academic exercise, with the exception of risk management in large projects and mature organizations. For those smaller projects that do apply a risk management process, more often than not it is performed early on in the project, and is neglected for the remaining duration.

In the current economic environment, where cutbacks and judicious spending are prevalent, delivering successful projects by addressing risks is critical. There is a need for a better and simpler risk management method to encourage not only initial usage, but also ongoing reviews throughout the life of the project, which will lead to greater chance of project success.

Background

Risk Management in Practice

The 4th edition of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute [PMI], 2008) describes six risk processes: Plan Risk Management, Identify Risks, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, and Monitor and Control Risks. Many organizational risk methodologies use identical or similar steps in sequence. A major problem is that project managers, faced with all other responsibilities, neglect performing the “full” risk management activities. While this is generally acceptable (some risk management is still better than none at all), the lack of maintenance throughout the project opens the door to complacency and for previously identified risks to cause negative impacts to the project.

Risk management is an essential aspect of managing projects, but in practice it just isn't performed on a regular basis. The perception is that risk management is arduous and administrative. “The pressure from both clients and top vendor management to meet tight schedule and budget targets may also result in project managers regarding time-consuming risk response planning activities to be a costly luxury” (Taylor, 2006). While many project managers understand the importance of risk management, the majority prefer making risk-based decisions as opposed to taking a documented approach.

Another issue is that when risk management is implemented, it tends to be performed solely by the project manager. As a result, many team members may not be aware of all project risks. And the corollary effect is that the team will assume that all risk management is the project manager's responsibility. In reality, it is the project team that can readily identify the majority of risks within a project more easily than the project manager.

If the project manager has initiated the risk management effort by himself or herself, the list of risks will be a collection of past lessons learned; but more importantly, this decision will have disregarded team members’ experiences in project risk—and risk management should not be performed in isolation. If the project manager has involved the team in a brainstorming exercise, while this is better than the first scenario, the resulting list tends to have redundancies and is typically wide ranging and unfocused, creating additional work for the project manager to sift through. Both of these scenarios are using a form of risk forecasting, or “crystal ball gazing” to predict what risks could occur. This method has its limitations because of its inherent unstructured nature.

Lastly, many project managers will merely re-use a generic risk management plan to say that they are applying risk management on their project, but then only keep track of risks in their own heads as the project progresses.

Underutilization of Risk Tools

Basic project risk management tools include the risk register, checklist, risk categorization, and prioritization. Risk management practitioners with more experience may also use Probability-Impact matrix, SWOT analysis, expected monetary value calculations, decision trees, and Monte Carlo analyses. But what is the real-life use of these tools?

A study was conducted on various project management tools and techniques and showed that out of 70 techniques, risk tools ranked very low in everyday use (Besner & Hobbs, 2006). These included (in order of usage) risk management documents, ranking of risks, graphic presentation of risk information, and a database of risks. The same paper also stated that these risk tools were among the greatest unexploited potential for increasing project performance.

Therein lies the conundrum: project managers know that to ignore risk is irresponsible, yet they do not practice risk management in “real life.” In the absence of an easy-to-use tool, risk management is largely ignored.

Re-introducing the RBS

A very good tool is the risk breakdown structure, as mentioned in the PMBOK® Guide (PMI, 2008) and also described by Hillson (2002). An RBS would be similar in format and content as a work breakdown structure (WBS) but would include other facets beyond just project deliverables. An RBS could also include market conditions, client past behaviors, team skills, and external environments—more intangible elements of a project. The main benefit of the RBS would be to understand which areas of the project need particular attention, by means of structuring and grouping risk. By effectively combining risk identification and categorization simultaneously, risk becomes more easily identifiable and prioritized.

Still, this tool is inclined to exist among the theoretical realm and is not used as often as it should be.

The Visual Ishikawa Risk Technique (VIRT)

Introducing VIRT

Visual Ishikawa Risk Technique (VIRT) is a technique that is consistent with the Identify Risks process group of the PMBOK® Guide (PMI, 2008) and uses an RBS as its main principle artefact. However, it differs from previously described formats in that it uses the Ishikawa diagram (commonly also known as a fishbone, or cause and effect diagram), for the risk structure, to create a graphic view, as opposed to being text based or tabular. The hierarchical nature of risks is maintained in this format. Depending on the size, complexity, and length of the project, a project can utilize several RBSs to represent different tier levels and appropriate detail.

As stated earlier, risk management should not be performed in isolation and must be performed as a group, while being championed by the project manager. VIRT makes use of a group's collective experience in the project and can consist of the project team, stakeholders, functional managers, sponsors, and customers, and may use various techniques such as those indicated in the PMBOK® Guide (brainstorming, facilitated sessions, Delphi technique, etc.).

While there are many similarities to the WBS, the RBS must contain more than just project deliverables. Intangible success categories such as finance, customer satisfaction, product success, and human resource management should be incorporated.

Benefits of VIRT

Visual Presentations and Reporting

The biggest benefit of using the VIRT is that it transforms risk into a graphic format. As the old adage states: “A picture is worth a thousand words.” By making risk visual, it facilitates a fast comprehension of risks and encourages discussion. Rather than displaying a risk register of table with “a thousand” words of text, an Ishikawa RBS can highlight the essential risk areas in seconds via graphics. VIRT will streamline risk reports and presentations for upper management and customers, focusing attention on the “right” risks. By integrating VIRT into organizational assets, the technique actually promotes ongoing risk monitoring and control, simply by being visual.

Team Building and Risk Awareness

When VIRT utilizes facilitation methods that include the project team, it is a form of team-building exercise, which boosts communication and effectiveness. But the more powerful side effect of involving the team is that it instills a sense of risk identification and assessment within the team members’ themselves. Within a project, the team members are typically the eyes and ears of the project manager, and able to come across risks much sooner than the project manager. In real life, team members either do not recognize that a risk has appeared, fail to communicate the risk to the project manager, or simply believe it is not their responsibility to take action. By involving the team in a VIRT risk activity, the team is more likely to work with the project manager in ongoing risk management. Risk awareness is also significantly enhanced among key stakeholders, upper management, customers, and PMOs.

Historical Assets for Organizations

The VIRT will also facilitate harvesting RBSs for use in future projects. Because of the generic and graphic nature of the RBS using the Ishikawa diagram, it can more readily be applied to future projects of similar scope. It is easier to see similarities within a graphic RBS than a tabular one. Lessons learned will also be able to compare actual risks to the RBS model in a post-mortem analysis.

Other Benefits

Lastly, simply applying a risk management technique within a project will produce additional benefits, such as development of assumptions to contain risks and scope, better risk assessments, and aid in change request assessment. Organizations that have weak risk management methodologies stand to gain the most by applying VIRT in their projects.

Implementing and Using VIRT

Overall, VIRT uses very basic tools and techniques that have already been recognized by organizations such as the Project Management Institute. But it is the collection and usage of these tools and techniques that form the end product from using this technique. The following steps should be used in developing and using VIRT for project risk management. A facilitated workshop is the preferred technique for completing VIRT quickly with the highest amount of team buy-in.

Step 1. Create the RBS

The most effective method for creating the RBS is using “what-if” scenario planning to imagine the project as a success, past-tense. This diverges in its use from most publications, which tend to use this technique for negative scenarios such as schedule variations or deliverable failures. By visualizing the best-case scenarios, the RBS can be created more readily than by thinking of events that can go wrong.

Different parts of the group will contribute areas based on their own experiences and expertise. It is important to categorize these ideas at higher levels and at more granular levels, thereby developing multiple-tier level RBSs. Ideally, there will be no more than five to eight “branches” per RBS.

Exhibit 1 is an example of an RBS using the Ishikawa diagram. In this example, a new service was being introduced as an internal capability. The initial implementation and set-up was managed as a project and was funded by three distinct sponsorship groups.

RBS example using Ishikawa diagram

Exhibit 1: RBS example using Ishikawa diagram.

Step 2. Identify Points of Failure

Once the RBS has been finalized by the team, the VIRT continues with the what-if analysis, now shifting to a worst-case scenario prediction. The group is now asked a key question: “What areas, if unsuccessful, would cause the entire project to FAIL?” It is important to highlight that key word “entire,” as this will focus the group's attention on significant risks. The results are gathered and aggregated, and are then identified on the RBS.

As many project management practitioners know, project risk changes with time; some risks expire, risk impacts increase and/or decrease, and some risks evolve and change. The RBS itself should not significantly change throughout the project at the higher tier level. But as the project proceeds, particularly if the project is long in duration, the key points of failure will also evolve and change. For example, at the beginning of a project, finalizing the product requirements will be a critical risk area, but after the requirements phase has been completed, this risk has significantly changed.

Step 3. Identify Significant Obstacles

A second question is now posed to the group: “What areas, if unsuccessful, will cause significant impact, such as schedule delay, cost overrun, or poor customer satisfaction?” The group's awareness is now focused on major risks that can cause hardship to the project if left unmanaged and uncontrolled. Again, as the project proceeds, these major risks will also change over time.

Exhibit 2 shows the key areas after steps 2 and 3 are applied. The red ovals indicate the key points of failure for the new initiative, while the orange boxes indicate areas that must be managed carefully throughout the project.

RBS example with key areas identified

Exhibit 2: RBS example with key areas identified.

In this example, five major areas were denoted as critical risks. These were:

  • Satisfaction level of the sponsors: each sponsoring department had different ideas of success, and enough influence to shut down the initiative if satisfaction were low.
  • Utilization levels of the internal team: if utilization levels were shown to be lower than expectations, it would not justify the business case to continue. This imposed an incremental growth pattern as opposed to assembling a larger team and then acquiring new business.
  • The perceived value of the new service: existing and potential customers must understand and accept the value of the service. If the perceived value were low, customers would find alternatives to the new service.
  • The new service must establish a high reputation and create “word-of-mouth”: as an internal service, if a low reputation were to form, key “customers” would not recommend the new service to each other.
  • Acquiring the team: because the service was new and had a low cost structure defined by the business case, existing resources needed to be obtained. If internal and external hiring failed, there would not be enough skilled resources to continue the initiative.

At this point, the project manager and team have several high-level priority risk areas.

Step 4. Decompose Points of Failure to Detailed Risks

Now that the key areas have been identified, the project management team must decompose the more granular risks that will become part of the ongoing project risk register. For example, a high-level risk area of “team skills” can be broken down to the following risks:

Team members are not competent for specific technology

Team members have not completed required training prior to xxx date

Team members do not have relevant certification for project role

Lack of skill will result in reworked deliverable and higher cost than planned

New team members take longer than expected to integrate into project team

These risks should be documented in the project risk register. The completion of this step is essentially the completion of the Identify Risks process, with exception of possible minor risks.

Step 5. Complete Following Risk Management Activities

Once the project manager has a list of identified risks, the project management team should perform the remaining risk management processes: Perform Qualitative and Quantitative Risk Analysis and Plan Risk Responses. Again, the project team should be involved in developing potential risk response plans.

The key advantage is that the project management team is now focusing on a set of prioritized risks that are aligned to the project's envisioned success.

Step 6. Apply to Ongoing Status Reports and Recurring Status Presentations

Now that the project manager has used VIRT to complete the set of risks, he or she must monitor and control them. As mentioned earlier, while this is a best practice, many project management practitioners fail to do this on a regular basis. The PMBOK® Guide advises that status meetings should be used as a technique to monitor and control project risks. “Frequent discussions about risk makes it more likely that people will identify risks and opportunities.” (PMI, 2008, p. 311).

For additional visibility, this paper highly recommends that the RBS, with identified critical risks, should be incorporated within project status reports and in recurring status presentations, for medium- to large-sized projects. This builds upon the above statement, and, by integrating the RBS into organizational process assets, creates a higher probability that risk management will be continually performed throughout the project.

Extending and Integrating VIRT

Identify Success Criteria and Metrics

In the VIRT example used in Figures 1 and 2, it is now easy to clearly see the key areas of risk within this project, at a high level. By labelling these risks as “Critical Success Factors” and “Secondary Success Factors,” it pinpoints where attention must be focused throughout the project to deliver it successfully. Just as identifying the schedule critical path aids the project manager in prioritizing decisions, so does identifying the critical success factors aid in a higher probability of project success.

This is a significant benefit when using VIRT properly; in fact, project success criteria and metrics are inherently the flipside of key risk areas. To deliver the project as planned, the project manager must understand how to turn the biggest risks into the greatest opportunities.

Continuing the VIRT example, Exhibit 3 shows a set of key metrics that were derived from the identified critical risks.

Derived tracking metrics

Exhibit 3: Derived tracking metrics.

The tracking metrics were very easily derived from the critical risks. By monitoring these metrics on a recurring basis, typically through status reports, project managers can apply variance analysis, and take corrective action throughout the project.

Conclusion

As stated, one of the biggest problems in project is adoption of regular risk management practices on a regular basis. The consequences are obvious: unplanned events, cost overruns, schedule delays, and overall greater probability of project failure. Due to “higher” priorities, project managers do not wish to spend time on nonvalue added activities, which is, unfortunately, how they often view risk management.

Overall, VIRT is a straightforward risk management technique that manages to focus attention on the critical areas, as opposed to a diverse range of risks that may not impact the overall project success. And yet VIRT's benefits are immense: it can dramatically improve a project's chance for success by promoting continuous risk management, supporting team building and buy-in, providing risk visibility to the sponsor and customer, and enabling an organization to easily reapply risks as historical records.

References

Besner, C., & Hobbs, B. (2006). The perceived value and potential contribution of project management practices to project success. Project Management Journal, 37(3), 12.

Hillson, D. (2002). Use a risk breakdown structure (RBS) to understand your risks. Proceedings of the Project Management Institute Annual Seminars and Symposium. October 3–10, San Antonio, TX, USA.

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® guide) (4th ed.). Newtown Square, PA: Project Management Institute.

Taylor, H. (2006). Risk management and problem resolution strategies for IT projects: Prescription and practice. Project Management Journal, 37(5), 49–63.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010, Rubin Jen
Published as part of Proceedins PMI Global Congress 2010 – Washington, DC

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.