Risk Management and Project Success

Successful project managers manage the differing perceptions of risk, and the widespread confusion about its very nature, by engaging in systematic risk management. According to the Financial Times, risk management is "the process of identifying, quantifying, and managing the risks that an organization faces". In reality, the whole of project management can be thought of as an exercise in risk management because all aspects of project management involve anticipating change and the risks associated with it.

The tasks specifically associated with risk management include "identifying the types of risk exposure within the company; measuring those potential risks; proposing means to hedge, insure, or mitigate some of the risks; and estimating the impact of various risks on the future earnings of the company" (Financial Times). Engineers are trained to use risk management tools like the risk matrix shown in Figure 8-1, in which the probability of the risk is multiplied by the severity of consequences if the risk does indeed materialize.


Figure 8-1. A risk matrix is a tool engineers often use to manage risk

This and other risk management tools can be useful because they provide an objective framework for evaluating the seriousness of risks to your project. But any risk assessment tool can do more harm than good if it lulls you into a false sense of security, so that you make the mistake of believing you really have foreseen every possible risk that might befall your project. You don't want to make the mistake of believing that the tools available for managing risk can ever be as precise as the tools we use for managing budgets and schedules, even as limited as those tools are.

Perhaps the most important risk management tool is your own ability to learn about the project. The more you know about a project, the better you will be at foreseeing the many ways the project could go awry and what the consequences will be if they do, and the better you will be at responding to unexpected challenges.

The Risk of Failing to Define "Success" Accurately

Different people will have different interpretations of the nature of risks associated with a company's future earnings, depending on how broadly one defines "success" and consequently the risks that affect the likelihood of achieving success. An example of a company failing to define "success" over the long term, with tragic consequences, is the 2010 BP spill, which poured oil into the Gulf of Mexico for 87 days.

This event, now considered one of the worst human-caused disasters in history, started with a methane explosion that killed 11 workers and ultimately sank the Deepwater Horizon oil rig. After the explosion, engineers counted on a specialized valve, called a blind shear ram, to stop the flow of oil. For reasons that are still not entirely understood, the valve failed, allowing the oil to pour unchecked into the Gulf. Despite the well-known vulnerability of the blind shear ram, and the extreme difficulties of drilling at a site that tended to release "powerful 'kicks' of surging gas," BP chose not to install a backup on the Deepwater Horizon.

In hindsight, that now looks like an incredibly short-sighted design and construction decision, especially considering the fact that nearly all oil rigs in the gulf are equipped with a backup blind shear ram to prevent exactly the type of disaster that occurred on the Deepwater Horizon. The well's installation might have been considered "successful" at the time of completion if it met schedule and budget targets. However, if BP had focused more on long-term protection of the company's reputation and success, and less on the short-term economics of a single oil rig, the world might have been spared the Deepwater Horizon catastrophe. As companies venture into ever deeper waters to drill for oil, this type of risk management calculation will become even more critical.

A New Approach to Risk Management

In traditional, geometric order thinking, risk is a hot potato contractually tossed from one party to another. In capital projects in particular, risk has traditionally been managed through aversion rather than fair allocation. Companies do everything they can to avoid suffering the consequences of uncertainty. Unfortunately, this often results in parties being saddled with risk they can't manage or survive. As explained in an interview with John Nelson, this often means that, in capital projects, customers are unsatisfied because

conflict inherent in improper risk allocation often results in expensive and unwanted outcomes, such as numerous RFIs [Requests for Information] and change orders, redesign, delays, spiraling project costs, loss of scope to "stay in budget," claims and disputes, a changing cast of players, poorly functioning or unmaintainable designs, unmet expectations, productivity losses, and in a worst case: lawsuits.

The essential problem with traditional risk management in capital projects is that it forces each party to

act in its own interests, not in the common interest because there is no risk-sharing that binds together the owner, architect, and constructor. In the traditional model, the owner often unintentionally presumes he will get the minimum ­– the lowest quality of a component, system, etc. ­– that all the other project parties can get away with. So, when a problem occurs, such as a delay, each party naturally acts to protect their own interests rather than look for a common answer.

The traditional approach sees risk as something bad that must be avoided as much as possible. By contrast, a living order approach sees risk as a sign of opportunity, something essential to capitalism and innovation. Rather than tossing a hot potato of risk from stakeholder to stakeholder, a living order approach seeks a more equitable, holistic form of risk-sharing, with the most risk assigned to the party best able to manage it and most likely to benefit from it. In a capital project, for instance, the owner must assume "some of the risk because at the end of the day the owner has the long-term benefit of a completed facility".

Risk Management Calculations Can be Risky

In their book Becoming a Project Leader, Laufer et al. question the usefulness of risk management calculations, positing redundancies as a better method for handling unpredictable events in projects. They point to "Zur Shapira, who asked several hundred top executives (of permanent organizations, not of projects) what they thought about risk management, [and] found they had little use for probabilities of different outcomes. They also did not find much relevance in the calculate-and-decide paradigm. Probability estimates were just too abstract for them. As for projects, which are temporary and unique endeavors, it is usually not possible to accumulate sufficient historical data to develop reliable probabilities, even when the risky situation can be clearly defined".

Laufer et al. also point to the expertise of Brian Muirhead from NASA, who "disclosed that when his team members were asked to estimate the probability of failures, 'many people simplistically assigned numbers to this analysis ­– implying a degree of accuracy that has no connection with reality'".

Furthermore, Gary Klein, in his analysis "The Risks of Risk Management," concluded unequivocally, "In complex situations, we should give up the delusion of managing risk. We cannot foresee or identify risks, and we cannot manage what we can't see or understand". It therefore behooves us to build in some redundancies so that we're able to cope with problems that may arise.

In a report on managing the extensive risks involved in highly complex infrastructure projects, Frank Beckers and Uwe Stegemann advocate a "forward-looking risk assessment" that evaluates risk throughout the project's entire lifecycle. The questions they raise are helpful to ask about any type of project unfolding in living order:

  • Forward-looking risk assessment: Which risks is the project facing? What is the potential cost of each of these risks? What are the potential consequences for the project's later stages as a result of design choices made now?
  • Risk ownership: Which stakeholders are involved, and which risks should the different stakeholders own? What risk-management issues do each of the stakeholders face, and what contribution to risk mitigation can each of them make?
  • Risk-adjusted processes: What are the root causes of potential consequences, and through which risk adjustments or new risk processes might they be mitigated by applying life-cycle risk management principles?
  • Risk governance: How can individual accountability and responsibility for risk assessment and management be established and strengthened across all lines of defense?
  • Risk culture: What are the specific desired mind-sets and behaviors of all stakeholders across the life cycle and how can these be ensured?

When thinking of risk and a project's life cycle, it's important to remember that many manufacturing companies, such as Boeing and John Deere, have begun focusing on making money from servicing the products they produce ­– putting them in the same long-term service arena as software developers. At these companies, project managers now have to adopt a greatly expanded view of a product's life cycle to encompass, for example, the decades-long life span of a tractor. Living as we do in an era when time is constantly compressed, and projects need to be completed faster and faster, it can be hard to focus on the long-term risks associated with a product your company will have to service for many years.

All forms of business are in need of a radical rethinking of risk management. For starters, in any industry, it's essential to collaborate on risk management early on, during project planning, design, and procurement. The more you engage all key stakeholders (e.g., partners, contractors, and customers) in the early identification of risks and appropriate mitigation strategies, the less likely you are to be blindsided later by unexpected threats.

In addition to paying attention to risk early, a good risk manager also practices proactive concurrency, which means intentionally developing an awareness of options that can be employed if things don't work out. This doesn't necessarily mean you need to have a distinct plan for every possible risk. But you should strive to remain aware of the potential for risk in every situation and challenge yourself to consider how you might respond.

At all times, be alert to consequences that are beyond your team's control. Sometimes management's definition of project success is tied to longer-term or broader outcomes, often involving things well outside the control of the project's stakeholders. If you find yourself in that situation, do all you can to raise awareness of the consequences of a threat to the project being realized, emphasizing how they might affect the broader organization. It is then up to the senior management, who presumably has the authority and ability to influence wider aspects, to take action or make adjustments.

Product Development Risks

In product development, the most pressing risks are often schedule-related, where it is essential to get the product out to recover the initial investment and minimize the risk of obsolescence. In this environment, anything that can adversely affect the schedule is a serious risk. A less recognized product development risk is complacency: product designers become so convinced they have created the best possible product that they fail to see drawbacks that customers identify the second the product reaches the market.

An opportunity is the opposite of a threat. For example, anything that can positively affect a schedule is an opportunity.

This famously happened in 2010 with Apple's iPhone 4, which tended to drop calls if the user interfered with the phone's antenna by touching the device's lower-left corner. At first, Apple chose to blame users, with Steve Jobs infamously advising annoyed customers, "Just avoid holding it that way". Eventually, the company was forced to offer free plastic cases to protect the phone's antenna, but by then the damage was done. Even die-hard Apple customers grew wary of the brand, the company's stock price fell, and Consumer Reports announced that it could not recommend the iPhone 4.

Product development firms are especially susceptible to market risks. Maintaining the power of a company's brand is a major issue that can lead to numerous risks. One such risk is the erosion of a long-established legacy of consumer trust in a particular brand. A new, negative association (think of the Volkswagen emissions-control software scandal) can drive customers away, sabotaging the prospects for new products for years to come. Even changing a company logo presents great risks. This blog post describes redesign failures, some of which costs hundreds of millions of dollars. Another market risk is a sudden, unexpected shift in consumer preferences, as occurred in the 1990's, when, in response to an economic downturn, consumers switched from national brand groceries to less expensive generic brand, and never switched back, even after the economy improved. These days, higher quality generic brands, such as Costco's Kirkland brand, are big business ­– a development few analysts saw coming. Market risks can undermine all the good work engineers do in developing a product or service. For example, Uber engineers excelled in developing a system that employs geo-position analytics to enable vehicles, drivers, and riders to efficiently connect. However, the company failed to assess and address key market issues like rider safety, governmental approvals, and data security.

In traditional product development, risk management is relegated to research and development, with marketing and other teams maintaining a hands-off approach. But as products grow more complex, this tendency to focus only on technical risks actually increases the overall risk of project failure. In the product development world, the risk of failure is increasingly dictated by when the product arrives in the marketplace, and what other products are available at that time. In other words, in product development, schedule risks can be as crucial, if not more crucial, than technical risks.

In an article adapted from his book Developing Products in Half the Time, Preston G. Smith argues, "When we view risk as an R&D issue, we naturally concentrate on technical risk. Unfortunately, this guides us into the most unfruitful areas of risk management, because most products fail to be commercially successful due to market risks, not technical risks". Even at companies that tend to look at the big picture, "engineers will tend to revert to thinking more narrowly of just technical risk. It is management's job to keep the perspective broad". Companies that lack the broad perspective end up piling risk on risk.

Although others may think of risk as solely a technical issue and attribute it to the R&D department, most risk issues have much broader roots than this. If you treat development risk as R&D-centric, you simply miss many risks that are likely to materialize later. If others try to place responsibility for product-development risk on R&D, they unwittingly mismanage the problem.

Smith advocates for a proactive approach to risk management in which companies identify threats early and work constantly to "drive down" the possibility of a threat actually materializing, while staying flexible on unresolved issues as long as possible. He provides some helpful risk management techniques.

IT Risks

The IT world faces a slew of risks related to the complexity of the products and services it provides. As a result, IT projects are notoriously susceptible to failure. In fact, a recent survey reported a failure rate of over 50%. This figure probably under-reports the issue because it focuses on the success rate for IT projects in the short run ­– for example, whether or not developers can get their software up and running. But as software companies rely more and more on a subscription-based business model, the long-term life cycle of IT products becomes more important. Indeed, in a world where software applications require constant updates, it can seem that some IT projects never end. This in turn, raises more risks, with obsolescence an increasing concern. Add to this the difficulties of estimating in IT projects and the cascading negative effects of mistakes made upfront in designing software architecture, and you have the clear potential for risk overload.

By focusing on providing immediate value, Agile helps minimize risk in software development because the process allows stakeholders to spot problems quickly. Time is fixed (in preordained sprints), so money and scope can be adjusted. This prevents schedule overruns. If the product owner wants more software, she can decide this bit-by-bit, at the end of each sprint.

In a blog post about the risk-minimizing benefits of Agile, Robert Sfeir writes,

Agile exposes and provides the opportunity to recognize and mitigate risk early. Risk mitigation is achieved through cross-functional teams, sustainable and predictable delivery pace, continuous feedback, and good engineering practices. Transparency at all levels of an enterprise is also key. Agile tries to answer questions to determine risk in the following areas, which I will discuss in more detail in a future post:

  • Business: Do we know the scope? Is there a market? Can we deliver it for an appropriate cost?
  • Technical: Is it a new technology? Does our Architecture support it? Does our team have the skills?
  • Feedback (verification & validation): Can we get effective feedback to highlight when we should address the risks?
  • Organizational: Do we have what we need (people, equipment, other) to deliver the product?
  • Dependency: What outside events need to take place to deliver the project? Do I have a plan to manage dependencies?

Keep in mind that in all industries, simply identifying threats is only the first step in risk management. Lots of time and money could be lost by failing to understand probabilities and consequences, causing your team to place undue management focus on threats that have a low probability of occurrence, or that may have minimal impact.

Monetizing Risk

One way to manage risk is to monetize it. This makes sense because risk usually manifests itself as additional costs. If a project takes longer than expected or requires additional resources, costs go up. Thus, to fully understand the impact of the risks facing a particular project, you may need to assign a dollar value to (that is, monetize) the potential impact of each risk. Monetizing risks gives outcomes "real economic value when the effects might otherwise be ignored". Once you've monetized a project's risks, you can rank them and make decisions about which deserves your most urgent attention. Every industry has its own calculations for monetizing risks.

Keep in mind that monetizing certain risks is controversial. In some instances, it is acceptable or even required. One example is the value of a statistical life, which is "an estimate of the amount of money the public is willing to spend to reduce risk enough to save one life". The law requires U.S. government agencies to use this concept in "a cost-benefit analysis for every regulation expected to cost $100 million or more in a year".

In other circumstances, most notably in product safety, it is clearly unethical to make a decision based strictly on monetary values. An example of this is the famous decision by Ford Motor Company in the early 1970's to forgo a design change that would have required retooling the assembly line to reduce the risk of death and injury from rear impacts to the Ford Pinto car. The company's managers made this decision based on a cost-benefit analysis that determined it would be cheaper to go ahead and produce the faulty car as originally designed, and then make payments as necessary when the company would, inevitably, be sued by the families of people killed and injured in the cars. Public outrage over this decision and the 900 deaths and injuries caused by the Pinto's faulty fuel tank clearly demonstrated the need for product safety design decisions to be based on broader considerations than a simple tradeoff analysis based on the cost of improved design versus an assigned value for the value of lives saved.