Enhancing Software Project Success with Risk Management

Risk refers to uncertain future conditions or circumstances that may adversely impact a software development project if they occur. A risk represents the possibility, not the certainty, of a future event affecting the success of a software development project. Risk is inherent in all software development projects. By effectively managing risks, the project manager, the business analyst and the software development team can reduce the likelihood that an adverse event will occur and the impact on the project should such an event occur. Risk management is a repeatable, structured process that identifies and systematically addresses risks to minimize their effect on software development projects.

Author: James Ward, James A. Ward & Associates

Risk Management Defined

Per PMI’s PMBOK, “Project risk management is the systematic process of identifying, analyzing, and responding to project risk. It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of events adverse to project objectives. It includes the processes of risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control.”

The implementation and execution section of the risk management plan describes the procedures for dealing with risk for information technology projects. It follows the Project Management Institute Project Management Book of Knowledge (PMBOK), recognized as an industry standard for project management.

The tools section of the risk management plan describes the procedures for information technology projects.

Purpose Of Risk Management

The risk management plan as defined in this document addresses IT projects and their sub-projects. The risk management plan documents the procedures to be performed by the project team as part of the organization’s risk management process.

A proactive project team tries to resolve potential problems before they occur. This is the art of risk management. The purpose of risk management is to identify the risk factors for a project and to then establish a risk management plan that will minimize the probability that risk events may occur and that, should they occur, their impact on the project will be minimized.

Assumptions

All projects have risks. Risk is inherent to project work.

In any given organization or environment, projects will have common risks. In developing a risk management plan for a project, other projects should be reviewed for risk occurrences that can be anticipated and avoided.

Not all identified risk events will occur. Some risk events may occur more than once in the life of a project.

Project teams should perform risk identification processes at project inception, at the start of major project phases or iterations, and when significant changes to the project occur, such as changes in project scope or key personnel.

The project’s top risks should be analyzed by the project team on a regular, ongoing basis and reported to management.

Implementation And Execution

Step 1: Risk Management Planning

Risk management planning is concerned with deciding how to approach and plan risk management activities for a project. The risk management plan is based on identification of risk events followed by risk quantification, response development (mitigation), and response control (contingency planning and execution). Risk Management is an iterative process that is initiated at the start of the project and will continue throughout the project lifecycle.

The project team should consider both the organization’s and the project stakeholders’ tolerance for risk. Some organizations have very high tolerance for schedule or cost overruns, while others have very little.

The project manager is responsible for proactively managing the project’s risks. The key factors of risk identification, quantification, response, and control should be actively managed by the project manager.

Risk review should be an item on the project team meeting agendas. It may also be necessary to convene specific working sessions to assess and manage risk.

Step 2: Risk Identification

At project inception, an initial risk identification should be performed. This should be done by reviewing risks identified (or encountered but not identified) on other projects and by brainstorming with the project team and key stakeholders.

It is essential that customers/users/stakeholders be involved in the risk identification process, as along with members of the project team. This will serve to reinforce the concept that risk is inherent in all projects and that proactively identifying and managing potential risks will increase the likelihood of project success.

At this point, not all details of the project may be known, and these unknowns may constitute potential risks to the project. For example, requirements definition, and therefore project scope, may not be fully completed. Project assumptions and constraints should be carefully reviewed. It is possible that attempting to simultaneously address conflicting constraints could pose a risk to the project.

All potential risks should be reviewed by the project team and key stakeholders to assess the probability of occurrence and impact. The risk management matrix  can be used for recording and analysis of all identified risks. See Qualitative and Quantitative Risk Analysis (below).

All identified potential risk events that are deemed to be relevant to the project are to be recorded using the risk management matrix. The risk matrix maintains a record of “resolved” risks as well as “current” risks. Note that should a previously unidentified risk event occur at any point during the project life cycle, this event should be immediately recorded on the risk management matrix.

The project manager should summarize the project team’s risk assessment and report the findings to the project sponsor using the project risk summary report or the project risk detail report. The project’s “top risks” are also documented at project inception in the project’s statement of work (SOW).

Risk identification must include two elements:

• The risk condition, the cause of a risk event, and
• The risk consequence, the effect of the risk event on the project.

It may be helpful to define a risk condition as one of three types:

• Business Risk–A business condition that that would impact the project. Examples may include introduction of a competitor’s product, a merger, serious business downturn or upswing, reorganization, etc.
• Technology Risk–Introduction of new technology to the organization. This may include system components that are being developed by outside vendors.
• Project Risk–All of the things that can happen on a project, including such factors as personnel turnover, poorly understood requirements, inadequate project plan, insufficient project budget, work outside the project scope, scope creep, etc.

The risk consequence should define the effect, or “impact,” on the project in terms of the following three variables:

• The Project Scope–Impact on the ability to deliver all or some of the defined functions and features of the product or the performance attributes that have been specified, either explicitly or implicitly, for the product.
• The Project Cost–Impact on the ability to deliver the product within the specified project budget.
• The Project Schedule–Impact on the ability to deliver the product within the defined time frame for the project.

Should the project team be unable to define risk consequences for any of the above three items, it should be assumed that the identified future event does not pose a risk to the project.

The following table may prove helpful in analyzing risks:

IMPACT	SCOPE	COST	SCHEDULE
TYPE
Business	X
Technology		X	X
Project

Risk identification is an ongoing process to document the future risk events. Any new or changed risks should be incorporated into the analysis from a project’s start through its completion. All risks are to be recorded on the Risk Management Matrix.

In addition to project inception, risk identification should take place on a formal basis at the beginning of each major project phase or iteration and any time a significant change to the project occurs, such as a scope change or changes in key project personnel.

Step 3: Risk Analysis

Risk qualification, quantification and analysis make up an ongoing process that evaluates risks to assess the range of possible project outcomes. The evaluation may be conducted as individual assessments by assigned team members with the results presented to the project team and stakeholders for discussion and concurrence, or as working sessions with key project team members where a joint assessment is recorded.

For each risk the project team should address four risk factors:

Identify risk probability

Estimate the probability that the risk event will, in fact, occur. This probability will be defined as:

• HIGH (value = 3): The event probably will occur.
• MEDIUM (value = 2): The event is equally likely to occur or not occur.
• LOW (value = 1): The event is unlikely to occur during the life of the project.

Probability rating is mostly determined by expert judgment based on evaluating the history of other projects and the information available. Preliminary risk evaluation and assessment is executed with the input of project team members and stakeholders.

In this assessment, if an adverse event is virtually certain to occur, it should be treated as either an issue or a constraint by the project team. If an adverse event is extremely unlikely to occur, this may be documented as an assumption.

Identify risk impact

Estimate the impact on each of the three key variables of scope, cost and schedule, should the risk event occur. Note that this impact should be framed primarily in the manner in which it impacts “the customer” and not “the project.” As an example, a schedule impact may have a significant impact on the customer if the project must meet a legally mandated deadline or must support implementation of a new product or service that has been announced to start on a given date. On the other hand, a schedule slippage may have no appreciable impact on the customer but may mean that resources dedicated to this project will not be available as planned to start another critical project. For an effective project risk managment approach, all impacts must be identified and assessed.

The impact of a risk event should be defined as:

• HIGH (value = 3): Critical to the customer or the project; may even force project cancellation.
• MEDIUM (value = 2): Significant, but not catastrophic. The project would be able to recover and meet its objectives at a level that is acceptable to management and the customer.
• LOW (value = 1): Relatively little impact to the project that cannot be successfully dealt with. The risk event, should it occur, is considered to be circumstantial or of slight consequence to the objectives of the project.

Calculate Risk Exposure

Multiply risk probability by the risk impact, yielding a numeric risk exposure. Possible risk exposure results are 1, 2, 3, 4, 6 and 9.

Prioritize risks

Set risk priorities to direct focus where it is most critical. Determine the risks that are potentially the most harmful to the project. The risks with the highest risk exposure rating are the highest priority, or “top risks.”

This process can be done by sorting the risk management Matrix by Exposure Rating, highest to lowest. All risks with an exposure rating of 9 or 6 must be dealt with, by creating mitigation and contingency plans. Risks with an exposure rating of 3 or 4 should be recorded. If these are among the projects “top risks” they should also be addressed proactively. Risks with an exposure rating of 1 or 2 can be dropped from the analysis, but may need to be revisited later in the project. Where risks have an identical exposure rating, they should be prioritized by the project team to produce a top risk list.

About ten risks are the most that a project team can effectively deal with at any one time. If the team finds that more than ten risks have an exposure rating of 9 or 6, they should revisit the entire risk management process and should also seek guidance from management, the project sponsor and stakeholders, as the project may be at high risk of failure.

Step 4: Risk Response Planning

Risk response is an action plan to eliminate, reduce, or minimize the probability of a risk event occurring and/or the impact of a risk event should it occur. The output from this activity is a risk mitigation plan that contains a set of actions directed at minimizing the potential occurrence or impact of risks on a project and a risk contingency plan to be activated should the risk event occur.

For risks requiring response, there are two strategies that are considered:

Mitigation, a pre-emptive strategy, is concerned with minimizing the threat posed by a risk by removing the risk, reducing the risk, or avoiding the risk; e.g., set benchmarks for performance, start early, provide training, implement a formal change management process, set expectations, involve customer in early planning sessions. Risk warning flags or risk outcomes can be a part of the mitigation plan.

Risk mitigation strategies include the following:

• Acceptance: The project can live with the consequences of the risk event and deal with it effectively should the event occur.
• Avoidance: Elimination of the risk by doing something less risky. For example, the team may decide to eliminate a non-critical requirement from the initial release of the system if meeting that requirement poses a significant risk to the success of the entire project.
• Reduction: Minimize the likelihood that a risk event will occur (for example, offering a bonus to a key project team member to remain on the team through the duration of the project) or minimize the impact (for example, hiring a backup person for a key team member).
• Transference: Shift the risk to someone else, including the responsibility for response to a risk event. For example, requiring the users to develop a work-around for a non-critical requirement that has been identified as a risk to the project.

Contingency strategy deals with the impact of a risk by creating a contingency plan that will be activated should the conditions or warning flags occur, e.g., expected resolution date exceeded, schedule delays, team is working extended hours, increased staff needs, modified scope.

Contingency plans are necessary for all project risks, including those that have mitigation plans. They focus on the consequences when the risk event has occurred.

Contingency planning has three elements:

• The plan itself, containing specific actions to be taken in the event of an occurrence of the risk event.
• Triggers, to determine when to activate the contingency plan. Triggers may be specific events or conditions (thresholds) that are met. For example, an event that may trigger a contingency plan is the resignation of a key team member. A threshold may be schedule slippage of greater than two weeks.
• Triggers, to determine when to de-activate a contingency plan (not always applicable). For example, contingency plans may be de-activated when the project is back on schedule.

For each risk, the project manager should assign an owner responsible for developing and maintaining its risk mitigation and contingency plans. The project work plan should contain specific tasks with dates for the development of mitigation and contingency plans for all risks.

Step 5: Risk Monitoring and Control

The Project Manager should implement and direct mitigation actions, monitor the mitigation actions to determine their effectiveness, and revise the mitigation strategies as needed. The project manager should:

• Implement the Risk Mitigation Plan – Implementing the Risk Mitigation Plan requires the monitoring of the risk warning flags and reacting quickly to implement the risk mitigation strategies. Effective mitigation is proactive, as problems rarely solve themselves.
• Assess Mitigation Effectiveness – After implementing the Risk Mitigation Plan, the project manager should assess the effectiveness of the risk mitigation actions.
• Reassess Exposure – Evaluating the project’s current risk status on a regular basis will address the dynamic realities of the project. Project team meetings can be venues to raise and report project risk and risk mitigation actions and results.

The Project Manager should address probability of risks and impact changes, as well as any new risks that are identified. Newly identified risks should be subjected to the same risk assessment and management process.

Risks that have been successfully mitigated should be “resolved” and that status should be reflected in the risk management matrix and on project reports. Successful mitigation means reducing risk exposure to a level where the risk is no longer deemed by the project team to be among the project’s “top risks.”

Step 6: Risk Review and Reporting

New risks that have been identified and old risks that have changed within the reporting period should be communicated in project team meetings and should be included in all project status reporting.

Risk changes will include the following:

• Successful mitigation, resulting in retiring or resolving a risk.
• Occurrence of a risk event, either previously identified or unidentified.
• Activation of a contingency plan or de-activation of that plan.
• Re-prioritization of “top risks” based on planned risk identification, risk mitigation or changing project conditions.

Risk Quality Assurance

Risk management quality assurance should measure:

• Total number of risks identified.
• Number and percentage of risks successfully mitigated.
• Number of occurrences of risk events, both identified and unidentified.
• Number and percentage of occurrence of unidentified risk events.
• Impact of the occurrence of risk events on scope, cost and schedule.

About the Author

James A. Ward, Principal Consultant with James A. Ward & Associates, Inc., manages a practice specializing in project management, business systems analysis, technical writing and PMO implementation. Mr. Ward’s seminars and workshops are always well attended and highly recommended by his clients. A frequent speaker at Information Technology and Project Management conferences, Mr. Ward is active in PMI, Agile and Software Process Improvement Network (SPIN) groups. Mr. Ward holds an MBA in Finance from the University of Chicago and is a PMP Certified Project Manager.