Don't leave home without it
WHEN IT COMES TO PROJECTS, the words of management guru Peter Drucker hold true: “If you can't measure it, you can't manage it.” But when it comes to specific risks on those projects, if it can't be identified, it can't be mitigated.
That's why the risk register just may be the handiest tool in the project manager's toolkit.
Yet a 2011 study by risk management services provider Aon found that organizations still rely on senior management intuition and experience (43 percent) over risk registers or risk indicator worksheets (21 percent) to identify and assess major risks.
André Guyer, head of global transformation for Zurich Insurance Company Ltd. in Zurich, Switzerland, maintains that risk registers are important tools on which all projects should be built. “In a way, risk management is project management,” he says. “As a starting point, it helps to do a formal risk assessment and document it in a risk register.”
By anticipating risks—including opportunities—and working to either prevent them or capitalize on them ahead of time, project teams can increase the chances of positive project outcomes. “The benefit is that the probability of successfully completing the project is higher,” Mr. Guyer says.
Just what risks to include and how to present them in the risk register are another matter. While the typical register includes risk identification, probability, severity and mitigation, elements can vary widely across organizations.
Consider how two organizations used their registers to turn risk into reward.
CASE STUDY #1
Company: Zurich Insurance Company
Location: Zurich, Switzerland
Project: Design and implement a global risk engineering workstation that standardizes risk grading methodology and aggregates risk insights across industries and geographies.
The Zurich Insurance Company's risk engineering group consists of more than 800 risk engineers consulting in 25 different industries in 39 countries, and although they have the same job—helping customers identify, assess and minimize risks to property, liability, employee safety and other areas—those risk engineers used disparate local systems to do it. So in 2009, the group launched its global risk engineering workstation (GREW) project to replace disparate systems with a single networked solution. The new solution would allow Zurich to accumulate global risk engineering data and establish risk information globally, which can be used for risk benchmarks across geographies and industries, or for other risk insights.
“There are hundreds of thousands of customer touch points when our risk engineers go on site, so the idea of collecting this into a central database is a very powerful thing,” says Mr. Guyer. “By doing this, we can help our customers reduce their overall loss costs—financial and reputational—and also reduce our losses as an insurance company.”
This large-scale project needed a 360-degree view of potential risks.
As part of Zurich's custom “Risk Checker” tool, project teams answer 261 questions in 12 areas, ranging from “project organization and business case” and “time to deliver” to “legal and regulatory” and “information technology.” They then figure out how to address the risks, including mitigating, accepting, avoiding or exploiting. This questionnaire ultimately results in a high-level summary of the perceived risk in each of the relevant areas, as well as a detailed breakdown of specific risks and mitigation actions. It's based on the same risk analysis methodology that risk engineering has been utilizing for years with customers.
The constraint of having limited time, finite resources and fixed scope heightened the probability that milestones might not be achieved and increased the severity of the consequences. “If the first milestone was not achieved, then everything else would get delayed,” Mr. Guyer says. “So we introduced a timeboxed approach. We said, ‘We'll keep the timeline, but if necessary, we'll make some compromises with scope.’”
The project timeline was rigid because the new system could only be rolled out at the end of a calendar year; starting the project late could force a 12-month delay. “We couldn't just switch the timeline by a month or two, so we decided to use standard software rather than develop the whole thing from scratch,” Mr. Guyer says. “We found something that covered 80 percent of our functionality and had the other 20 percent developed.”
Just before its scheduled rollout in 2010, the GREW project was interrupted by an unrelated problem that impacted the availability of Zurich's central data center. As a result, rollout was delayed by 12 months. Still, the impact was moderate, as the project team had a backup plan that allowed operations to continue on existing legacy systems during the interim. “If we had not anticipated possible infrastructure issues in our planning, the consequences on business operations would have been severe,” Mr. Guyer says.
Because GREW would be Zurich's first globally integrated online business transaction system, the risk of the unknown was apparent. The solution: maintain control over as many project variables as possible. The team conducted in-depth research with field representatives to anticipate potential problems and selected an existing web-based solution that minimized the need for application development.
Suppliers also represented a significant risk. “One of the reasons to have suppliers in the first place is so you don't have to manage everything yourself,” Mr. Guyer says. “On the other hand, you want to make sure what you get is of required quality.” So the project team implemented a thorough quality-assurance process, including a variety of code inspections, to ensure visibility of the suppliers' work.
At Zurich, a companion document to the risk register is the risk map, which offers a visual representation of project risks.
Zurich project teams look at risk severity (from “marginal” to “severe”) and probability (from “almost impossible” to “very high”). “As a company, we are prepared to accept a risk with a very high probability as long as the severity is only marginal (yellow), but would reject the same risk with high severity (red),” Mr. Guyer says.
Project teams cannot accept red risks. “Whenever you have a risk that's in the red area, you need to do a mitigation action to move it to at least the yellow area and possibly to the green area,” Mr. Guyer says.
Changes in business requirements are common and can have dramatic implications for projects—hence the red. To reduce their impact and move them into the yellow, Zurich established a tightly controlled change-management process to manage stakeholder expectations.
One of the worst things that can happen to a project is failure to deliver expected outcomes. “Here, the improvement action is making sure we have the right key people on the team,” Mr. Guyer says. “This is probably the most critical success factor, and you have to do this at the very beginning of the project. If you do, it really reduces the risk of failure—in this case reducing it from high to low.”
CASE STUDY #2
Organization: U.S. Army Corps of Engineers,
Kabul Area Office
Location: Kabul, Afghanistan
Project: Upgrade existing buildings, design a new dining facility and build a new motor pool for an Afghan military base.
In January 2012, the Kabul Area Office (KAO) of the U.S. Army Corps of Engineers broke ground on a construction project on the Afghan National Army military base in Kabul, Afghanistan. The project, slated for completion in 2014, consists of various upgrades to existing buildings; design, construction and site adaptation for a new motor pool, including parking, fencing and related buildings; and completion of a new mess hall. In other words: a typical project in a very atypical place.
“In a non-combat area, the major concerns are to complete projects accurately with properly identified requirements and scope, on time and on budget,” says Lt. Col. Richard Smith, PMP, officer in charge at the KAO. “In a combat area, additional concerns that impact project completion are the diverse stakeholders, project location and access, and security.”
Given that, the project's obstacles aren't just about time, scope and cost; safety is a paramount concern, which makes addressing how to handle risks—from mitigation to acceptance—especially important.
KAO built its risk register based on lessons learned from past projects. For example, during the construction of a U.S. military compound completed in 2011, KAO was required to install split air conditioners—units with components both inside and outside the building—for the offices and billets. The split packs were held in transit, however, because of the closure at the border with Pakistan. A workaround had to be found to install temporary split packs. Lt. Col. Smith says KAO learned its lesson: “Currently, all projects have a medium risk associated with materials due to delays at the border.”
KAO classifies risks as “low,” “medium” or “high.” Whereas many project locations in Kabul would have necessitated high risks, “overall, the risk assessment for this project was low due to its location on an existing Afghan National Army (ANA) base and the high amount of security surrounding the airport,” says Lt. Col. Smith.
For typical off-base projects, security and site access are dire concerns. “When we visit projects, we wear all of our personal protective equipment, including battle armor and weapons,” Lt. Col. Smith explains. On an inspection trip to the ANA military base, a large force of more than 15 armed personnel arrived, and the base commander became upset over the excessiveness. So an alternative security mitigation route was chosen: Access must be coordinated with the local commander, and every worker and vehicle must be on a list.
The project's proximity to Kabul International Airport creates significant risk for delays. Security is provided by the ANA and Afghan National Police, who occasionally delay shipments into the site for three to four hours. “The airport is often closed when senior Afghan personnel are moving in or out,” Lt. Col. Smith says. “This becomes critical if the contractor is trying to deliver concrete.”
KAO emphasized the importance of securing construction materials because of the risk it poses to the project's budget. “Theft is an important consideration for all projects,” Lt. Col. Smith says. “The contractors can usually secure their equipment and materials inside their compound, reducing the risk to low.”
A risk register isn't a static document, Lt. Col. Smith says. “It should be reviewed weekly or monthly to assess new concerns or remove items that are no longer a concern,” he says. For example, the risk that long-lead items will not arrive on time is removed once they are on site. “KAO evaluates risks associated with security daily, safety weekly and long-lead items monthly,” Lt. Col. Smith adds. PM
3 Tips for Registering Risks
As useful as risk registers can be, simply having one doesn't guarantee project success. “If it's garbage you put in, it will be garbage you get out,” says André Guyer, Zurich Insurance Company Ltd., Zurich, Switzerland.
To make sure a risk register offers value, he offers a few risk planning tips:
Start early: “The ability to manage and mitigate project risk is easiest in the beginning of a project. Once a path has been set and project choices made, the resulting cascading impacts can make changes increasingly difficult and expensive to make.”
Engage diverse stakeholders: “You have to include people with different backgrounds—legal, sales, IT, regulatory, human resources, finance—who bring completely different perspectives to risk assessment and identification.”
Regularly revisit and re-evaluate: “A risk register isn't a snapshot that's taken once at the beginning of the project for administrative reasons. The risks must be managed dynamically on a continual basis, because risks can change from one week to the next.”
PM NETWORK NOVEMBER 2012 WWW.PMI.ORG
NOVEMBER 2012 PM NETWORK