Managing Project Risks

Identifying Risks

Most people use the term risk to refer to something bad that might happen, or that is unavoidable. The connotations are nearly always negative. But in fact, with risk comes opportunity and new possibility, as long as you can clearly identify the risks you face and employ reliable techniques for managing them. Risks can impact a project's cost and schedule. They can affect the health and safety of the project team or the general public, as well as the local or global environment. They can also affect an organization's reputation, and its larger operational objectives.

More Risk-Related Terms

Risk Capacity: The maximum amount of risk an organization can bear.

Risk Appetite: The maximum amount of risk an organization is willing to assume.

According to Larry Roth, Vice President at Arcadis and former Assistant Executive Director of the American Society of Civil Engineers, the first step toward identifying and managing risks is a precise definition of the term. He defines risk as "the probability that something bad will happen times the consequences if it does". The likelihood of a risk being realized is typically represented as a probability value from 0 to 1, with 0 indicating that the risk does not exist, and 1 indicating that the risk is absolutely certain to occur. According to Roth, the term tolerable risk refers to the risk you are willing to live with in order to enjoy certain benefits.

In daily life, we make risk calculations all the time. For example, when buying a new smartphone, you are typically faced with the question of whether to insure your new device. If you irreparably damage your phone, the potential consequence is the cost of a new phone – let's say $500. But what is the actual probability of ruining your phone? If you are going to be using your phone in your office or at home, you might think the probability is low, and so choose to forgo the insurance. In this case, a risk analysis calculation might look like this:

0.2 X $500 = $100

In other words, you might decide that the risk of damaging your phone is a tolerable risk, one you are willing to live with. The benefit you gain from tolerating that risk is holding onto the money you would otherwise have to pay for insurance.

But what might make you decide that the risk of damaging the phone was not a tolerable risk? Suppose you plan to use your phone regularly on a boat. In that case, the chance of damaging it by dropping it in the water is high, and so your calculation might look like this:

0.99 X $500 = $495

For many people, this make insurance might seem like a good idea.

Your tolerance of risk is partly a matter of personality and attitude. This article describes a range of attitudes toward risk, ranging from "risk paranoid" to "risk addicted".

Source: Board of Regents of the University of Wisconsin System, https://wisc.pb.unizin.org/technicalpm/chapter/managing-project-risks/
This work is licensed under a Creative Commons Attribution 4.0 License.

Threats, Issues, and Risks

Inexperienced project managers often make the mistake of confusing threats, issues, and risks. A threat is a potential hazard, such as dropping your phone in the water. A threat is not in itself a risk. A risk is the probability that the threat will be realized times the consequences.

On the other end of the uncertainty spectrum are issues, which are known potential problems that the project team will definitely have to keep an eye on. For example, the mere possibility of exceeding a project's budget is not a risk. It's a well-known issue associated with any project; part of managing the project is managing the budget. But if your particular project involves extensive use of copper wiring, then an increase in the price of copper is a direct threat to your project's success, and the associated risk is the probability of higher copper prices times the consequences of such an increase. Team members cannot control the price of copper; it is a risk that you'll have to respond to, making decisions in response to the changing situation.

Risk expert Carl Pritchard distinguishes between risks and issues as follows: "A risk is out there in the future, and we don't know if it is going to happen; but if it does happen it will have an impact. Issues are risks realized. They are the risks whose time has come, so to speak". That's not to say that all issues used to be risks. And some things can be issues at an organizational level, but a risk when it comes to your particular project. Pritchard explains:

Table 8-1 compares issues, threats, and risks on different projects.

Table 8-1. Distinguishing between issues, threats, and risks

The Fine Art of Perceiving Risk

A quick perusal of recent articles published in Risk Management magazine hints at the vast array of risks facing modern organizations. If you were asked to generate your own list, you might include environmental disasters, financial setbacks, and data theft as obvious risks. But what about the more obscure dangers associated with patent translations or cyber extortion?

The following examines a few varieties of issues and related risks you might not have considered. Can you think of any issues and risks specific to your industry that you would add this list?

• Human capital: Turnover among team members is an inevitable issue on long-running projects. People will come and go, and you have to be prepared to deal with that. But some forms of turnover go beyond issues and are in fact real risks. For example, one human capital risk might be loss of a key manager or technical expert whose relationship with the client is critical to keeping the contract. Team members behaving unethically is another human capital risk. Suppose a member on a highway construction project is fired for taking a bribe. This could have effects that ripple through the entire team for a long time to come. Team members might feel that their professional reputations are at risk, or they might decide that the team's manager is not to be trusted. Once team cohesion begins to crumble in this way, it can be hard to put things back together. Other human capital issues include catastrophic work events and negligent hiring practices. For example, the 2013 launch of HealthCare.gov failed, in part, because the project team lacked software developers with experience launching a vast, nationwide website. Meanwhile, departures of vital staff members at the agency responsible for overseeing the insurance marketplace also hampered progress. These unidentified human capital risks brought the project to a standstill. It was ultimately saved by a "hastily assembled group of tech wizards" with the know-how required to get the website up and running.
• Marketing: Project management teams often struggle to communicate with an organization's marketing department. Rather than drawing on the marketing department's understanding of customer needs, project teams often prefer to draw on their own technological know-how to create something cool, and then attempt to push the new product onto the market. But this can be a disaster if the new product reaches the market without the support of a fine-tuned marketing campaign. This is especially true for innovative products. For example, product developers might focus on creating the most advanced hardware for a smart thermostat, when in fact customers primarily care about having a software interface that's easy to use. As in many situations, a pull approach – asking the marketing department to tell your team what the market wants – is often a better option. Of course, this necessitates a good working relationship with the marketing department, which is not something you can establish overnight. Sometimes a marketing risk takes the form of a product or service that only partly serves the customer's needs. For example, one of the many problems with the rollout of the HealthCare.gov website, in 2013, was a design that "had capacity for just a fraction of the planned number of consumers who could shop for health plans and fill out applications".
• Compliance: In many cases, you'll need to make sure your project complies with "rules, laws, policies, and standards of governance that may be imposed by regulatory bodies and government agencies". Indeed, some projects are exclusively devoted to compliance tasks and can "range from implementation of employment laws to setting up processes and structures for meeting and reporting statutory tax and audit requirements to ensuring compliance with industry standards such as health and safety regulations". In any arena, the repercussions of failing to follow government regulations can be extreme. Ensuring compliance starts with learning what regulations apply to your particular project and staying up-to-date on changes to applicable laws. Keep in mind that safety concerns can evolve quickly, as was the case with Samsung's Galaxy Note 7 phone; millions of phones had to be recalled and the company's new flagship smartphone scrapped after lithium-ion batteries caused devices to catch fire.
• Sustainability: Although businesses have always had to deal with issues associated with the availability of natural resources, in the past they rarely questioned the validity of a business model that presumed the consumption of vast amounts of natural resources. But as scientists provide ever more startling evidence that endless economic growth is not a realistic strategy for the human race, businesses have had to focus on issues related to sustainability if they want to survive. For one thing, people increasingly want to work for organizations they perceive as having a serious commitment to sustainability. Indeed, the need to recruit top talent in the automotive world is one motivation behind the on-going transformation of Ford's Dearborn, Michigan campus into a sustainability showcase. Meanwhile, Ford's $11 billion investment in electric vehicles is a bid to remain viable in foreign markets that have more stringent sustainability requirements than the United States. A report on sustainability risks by Wilbury Stratton, an executive search firm, lists some specific sustainability risks:

• Complexity: Complex projects often involve risks that are hard to identify at the outset. Thus, complex projects often require a flexible, adaptable approach to risk management, with the project team prepared to respond to new risks as they emerge. Complex projects can be derailed by highly detailed plans and rigid controls which can "lock the project management team into an inflexible mindset and daily pattern of work that cannot keep up with unpredictable changes in the project. Rather than reduce risk, this will amplify it and reduce [the team's] capacity to achieve [its] goals. The effort to control risk might leave the team trying to tame a tiger while stuck in a straitjacket". Agile was specifically developed to deal with the challenges associated with the kinds of complexity found in IT projects. Pull planning also offers advantages in complex environments, in part because it forces team members to communicate and stay flexible.

Perhaps the hardest risks of all to prepare for are the risks that your training and professional biases prevent you from perceiving in the first place. As an engineer, you are predisposed to identify technical risks. You might not be quite as good at recognizing other types of risks. In Chapter 1 of Proactive Risk Management, Preston G. Smith and Guy M. Merritt list some risks associated with a fictitious product. The list includes marketing, sourcing, regulatory, and technical risks. In summing up, the authors point out two essential facts about the list of risks: "First, it is specific to this project and market at this point in time. Second, it goes far beyond engineering items". Later in the book, in a chapter on implementing a risk management program, they have this to say about an engineer's tendency to perceive only technical risks:

How Team Members Perceive Risk

The role team members play in a project can hugely affect their perception of risk. According to David Hillson, a consultant and author of many books on risk, a project sponsor (upper management or the customer) and the project manager perceive things very differently:

• The project manager is accountable for delivery of the project objectives, and therefore needs to be aware of any risks that could affect that delivery, either positively or negatively. Her scope of interest is focused on specific sources of uncertainty within the project. These sources are likely to be particular future events or sets of circumstances or conditions which are uncertain to a greater or lesser extent, and which would have some degree of impact on the project if they occurred. The project manager asks, "What are the risks in my project?"….
• The project sponsor, on the other hand, is interested in risk at a different level. He is less interested in specific risks within the project, and more in the overall picture. Their question is "How risky is my project?"…. Instead of wanting to know about specific risks, the project sponsor is concerned about the overall risk of the project. This represents her exposure to the effects of uncertainty across the project as a whole.

These two different perspectives reveal an important dichotomy in the nature of risk in the context of projects. A project manager is interested in "risks" while the sponsor wants to know about "risk". While the project manager looks at the risks in the project, the project sponsor looks at the risk of the project.

Even when you think you understand a particular stakeholder's attitude toward risk, that person's risk tolerance can change. For example, a high-level manager's tolerance for risk when your organization is doing well financially might be profoundly different from the same manager's tolerance for risk in an economic downturn. Take care to monitor the risk tolerance of all project stakeholders – including yourself. Recognize that everyone's risk tolerances can change throughout the life of the project based on a wide range of factors.

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.

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

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

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".

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.

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.

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.