A key factor in the success of any application development project is the identification of the risks a project might encounter, and the development of a system for managing those risks should they materialize during the project's life cycle. We include a discussion of risk management in this chapter because it begins in the Envisioning Phase. However, the process of managing risks continues throughout the entire project.
Many IT professionals have misconceptions about risk management. At best, they think it is a necessary but boring task to be carried out at the beginning of a project before the real work of writing code begins. At worst, they think it is another form of bureaucratic red tape that prevents the organization from achieving its objectives. Every project has its risks, and taking risks is essential to progress. However, that doesn't mean that attempting to recognize and manage risks is a useless activity or that it will stifle creativity.
Risk is the possibility of suffering loss. For a given project, this loss could be in the form of:
Because risk is a problem waiting to happen, not one that has occurred, effective risk management is a dynamic process rather than a static project management chore.
Team members usually know the risks associated with their project, but often communicate these risks poorly. Typically, communicating risks down the chain of command is easy, but communicating risks up the chain of command is difficult. At every level, people want to know the risks identified at the lower levels, but are wary of communicating the risks they have identified to the people above them. For the risk management process to succeed, the organization must create an environment in which people who identify and communicate project risks are safe from retribution. In a "don't shoot the messenger" environment, team members feel free to express tentative or controversial views, which significantly improves the scope and quality of risk management.
On some projects, reporting new risks can be viewed as a form of complaining or troublemaking. Often the reaction to the risks is seen as a problem with the person making the report rather than a problem with the product. If the organization's unspoken message is to "soften the risk," critical information that would result in better risk mitigation and contingency plans might be stifled.
CAUTION
Remember that risk is the possibility, not the certainty, of loss. Team members might erroneously view a project with a list of 15 to 20 identified risks with skepticism, even though the total risk exposure is modest.
Effective project risk management must take into consideration the business environment in which the project will be carried out. Many IT projects fail not because of faulty technology or bad project management, but because larger organizational pressures were ignored. These organizational pressures come in many forms, such as competition, financial health, and organizational culture. Potential risk sources include:
Possible consequences for the project include:
It is important to remember that different types of projects pose different kinds of risks, and each project's risks must be addressed individually.
Risk management can be approached in three ways:
Obviously the "magic wand" approach is not an example of good risk management. But neither is the reactive approach, because it has no prevention component. Preventing the risks identified for a project from materializing is the hallmark of a good risk management process. Prevention begins in the Envisioning Phase and continues until the product is released at the end of the Stabilizing Phase. For most risks, the goal is to take certain actions to prevent the risks from materializing as problems, as well as to determine in advance what actions will be taken if a particular risk does in fact materialize. To reach mature levels of proactive risk management, the project team must be able to unemotionally evaluate the risks and take actions that address their root causes, not just their symptoms.
It's important to emphasize that no matter how good a job the team does of risk assessment, it is the team's ability to manage risks that will be a determining factor in the project's success.
The risk management process consists of proactive decisions and actions that continually:
An effective project team assesses risks throughout the life cycle of the project and uses them for decision-making in all project phases. As shown in Figure 5.2, the team carries the risks forward until either they are resolved or they turn into problems and are handled as such.
Figure 5.2 Proactive risk management process
Risk identification is the first step in the proactive risk management process. Risks must be identified before they can be managed. Risk identification provides the opportunities, cues, and information that allow the team to expose the major risks that might adversely affect the project.
To identify risks, team members and key stakeholders hold a series of brainstorming and open discussions to identify and rank the risks for the project. To facilitate this process, risk factors can be grouped by focus area, such as custom software development, infrastructure deployment, packaged software deployment, enterprise architecture planning, and component-based development. Within each focus area, risk factors can be further grouped into categories, such as mission and goals factors, decision drivers, organizational management factors, and budget and cost factors.
For example, Table 5.2 identifies three mission and goals risk factors. Each factor has low, medium, and high risk cues. If the low risk cue is in evidence for the project fit risk factor, the project directly supports the customer's mission and goals; if the factor's high risk cue is in evidence, the project does not support or relate to the customer's mission and goals.
Table 5.2 Sample risk factors chart
Risk factor | Low risk cue | Medium risk cue | High risk cue |
---|---|---|---|
Project fit | Directly supports customer's mission and goals | Indirectly impacts one or more goals | Does not support or relate to customer's mission or goals |
Customer perception | Expects team to provide this product | Believes team is not working on expected product | Believes desired product is mismatched with prior team products |
Workflow | Causes little or no change to workflow | Changes some aspect of workflow or has small effect on workflow | Significantly changes workflow or method of organization |
For any risk the team discovers as a result of working through the risk factors chart, it should develop a risk statement and enter the risk on a master list. A risk must be clearly expressed before it can be managed. In stating a risk, the team should consider not only symptoms, but also causes and results. As Figure 5.3 shows, each risk statement should include the problem (the condition), what is causing the problem (the source), and the expected result for both the problem and the project (the consequence).
Figure 5.3 Sample risk statement
The process followed during this step is a powerful way to expose the assumptions and differing viewpoints of various team members and stakeholders. It's unlikely that everyone will agree on the ranking of all risk factors. Depending on their level of experience and area of concern, different team members will see the project differently. If no agreement can be reached, the best approach is a majority vote technique. If the votes are tied, caution dictates that the worst case be used for the risk assessment.
Risk analysis is the process whereby risk data is converted into risk decision-making information. Thorough analysis ensures that the team is working on the right risks.
Risk is primarily composed of two factors:
To evaluate a list of risks, the team must understand the overall threat each risk poses to the project. Sometimes risks that are high in probability are low in impact and can be safely ignored. At other times, risks that are high in impact are low in probability and can again be safely ignored. Risks that have high exposure (high probability and high impact) are the ones worth managing. Reducing the risk exposure can be accomplished by reducing either the risk probability or the risk impact.
To help communicate project risks, team members and stakeholders typically maintain the following items of information in a spreadsheet or database:
Risk analysis weighs the threat of each risk and determines which risks require preventive action. After the risks are ranked by risk exposure, the team should focus on a risk management strategy and how to incorporate risk action plans into the overall project vision. Because managing risk requires time and effort, the key is to identify a limited number of major risks that must be managed. A simple but effective technique is to develop a list of the ten highest risks for the project. This top-ten risk list should be visible to all project team leads. An additional list of major project risks, to raise awareness with the project stakeholders, should be included in the Vision Document created during the Envisioning Phase and the Master Project Plan created during the Planning Phase.
Risk action planning turns risk information into decisions and actions. Planning involves developing actions to address individual risks, prioritizing risk actions, and creating an integrated risk management plan that forms the basis of the Master Risk Assessment Document delivered as part of the Vision Approved Milestone.
During risk action planning, the team should consider four facets of each identified risk:
When the team identifies a risk that needs management, team members have three options:
For those risks within the team's control, the action plan consists of applying the resources needed to reduce the risk. For those risks outside the team's control, the action plan consists of finding workarounds. It may also be possible for the team to transfer the risk by:
As a safety net, the team should also develop a contingency strategy, which is a fallback plan that can be activated in case the action plan fails to contain the risk. For example, suppose a particular commercial product is needed so that software can be deployed on desktop systems, but the release date of the commercial product is uncertain. The team's contingency strategy might be to use an alternate product. In this case, during Planning Phase's design, the team would identify an alternative product to be used if the original commercial product does not meet the release date.
Deciding when to resort to the contingency strategy is a matter of watching the strategy's trigger value. Often the team can establish a trigger value for each contingency plan based on the identified type of risks or the type of project consequences. Table 5.3 shows some typical risks and consequences and their trigger values. When a trigger value is exceeded, the corresponding contingency strategy can be put into action to help mitigate the risk.
Table 5.3 Sample risks and contingency plan trigger values
Type of risk | Trigger value |
---|---|
Schedule slips | Latest date to use contingency strategy Latest date to select another vendor |
Additional resources required | Latest date to allow time to find resources Greatest amount of penalty or fine to incur Greatest amount of effort available for overrun |
Extra cost to customer | Dollar limit |
Learning time | Time limit |
To begin creating the Master Risk Assessment Document, several key items must be identified for each risk. These items are typically entered into an automated risk action form to assist communication between the team members and stakeholders:
Risk tracking is essential to effectively implement an action plan. It is the process by which the project team monitors the status of risks and the actions it has taken to mitigate them. It includes devising the risk metrics and trigger values needed to ensure that the planned risk actions are working. Tracking is the watchdog function of the risk action plan.
NOTE
It is a good practice to include a risk review during regular project reviews and debriefings. Risk review should include an assessment of progress made toward mitigation of the project's top ten risks.
During each project review, the team should report on the major risks for the project and the status of any risk management actions. Ranking risks over time is useful, as well as keeping a record of the number of times a risk appears in the top-ten risk list.
Risk status reporting can identify four possible risk management situations:
As the team takes actions to manage risks, the total risk exposure for the project should decrease.
After the team has defined the risk trigger values and metrics, the difficult part of risk management is over. Risk management melds into project management processes that:
As suggested by Ron Higuera and Yacov Haimes in the Software Engineering Institute paper Software Risk Management,
If the risk management process is not integrated with day-to-day project management, it will soon be relegated to a background activity.