Wherever I go exploring in Project Management,
I find Software Engineering Institute (SEI)
already returning home.
(paraphrase of a quote on the mind and Plato.
~ source unknown)
Risk Management is a critical part of the software project management process. Simply creating a plan is not sufficient to bring a project in on-time and under budget. Even a simple software project involves many diverse elements - any of which may change during the duration of the project. Such changes most likely will have an effect on the software project. The project manager must consider those risks that may prevent the plan from being successfully completed.
Planning for potential risks is a similar process to creating the project plan. There is an organized, common sense approach readily available to the project manager who is willing to take the time to create a risk management plan. I present an outline of a planning process. However, following a process to create a risk plan is not sufficient. The correct risks must be determined and the plan must address those risks. Following the outline will be a brief description of a taxonomy for software risk management developed by the Software Engineering Institute (SEI).
Risk Planning Process
There are two broad categories of risks in software projects. The first are known as generic risks and the second are project-specific risks. Generic risks are a type of risk that undermines a project at the most fundamental level. A project with these risks is one that is out-of-control. The fundamental planning, monitoring, and control mechanisms are missing or implemented incorrectly. Referring back to the Capability Maturity Model, a generic risk is the type of risk experienced by organizations with a maturity level of Stage 1. All processes are ad hoc and projects are only completed by the heroics of certain individuals.
As an example, a project to trek across Baja California is doomed to failure at an organizational level if the project manager is provided only skis with which to use for transportation. The project can not even get started. However, given the correct transportation, a set of all-terrain vehicles, then the project has a chance of success. The project manager in such a case will focus on project-specific risks such as spare parts for the vehicles. The generic risk is an organizational level risk and not the subject of this essay.
This essay focuses on the second of these two broad categories of risk, namely the project-specific risks. The project manager needs to consider the risks this project are likely to encounter and create a plan to avoid them. This type of risk can be unique to each software project. For example, most software will have some form of user-interface (UI) and there will be risks associated with its creation. So, if a project uses Java technologies, then a UI may be one of several off-the-shelf toolkits and there will be specific risks associated with the use of each particular UI toolkit.
A common-sense approach to risk management is to first analyze the potential risks and then develop a plan to reduce or mitigate their effects. The risk management planning activity is composed of two phases, with three steps in each phase. The two phases are risk assessment and risk control.
A. Risk Assessment Phase
The purpose of the risk assessment phase is to ensure a comprehensive and all-inclusive set of risks are reviewed and a sub-set of project-specific risks is determined. The risk assessment phase is composed of three steps. First is identifying the risks that may affect the current project. Second is analyzing the sub-set for their effect on the project. Finally, the sub-set must be prioritized.
Step 1. Identification
There are several approaches to determining the risks that may affect the current project. The method I prefer is the checklist. I like to work from the top-down and, in the case of risk planning, that means a comprehensive list of possible risks. The entire list is reviewed and the potential project-specific risks are extracted for further analysis.
I prefer the list approach because it also helps me to consider possible new risks - a simple sort of brainstorming tool. For example, consider a particular project that will not have sub-contract work. I should be able to ignore that portion of the checklist. However, if I consider the possible risk of customer-feature-enhancement risk along with the possibility of a schedule compression, then sub-contracting work at some point in the project may be a risk-mitigating strategy. So by having a comprehensive list I can brainstorm possible problems from risk categories that may not appear to affect the current project.
Toward the end of this essay I describe the SEI's list for software risk planning.
Step 2. Analysis
This step is the heart of the risk planning process. The sub-set of risks derived from Step 1 is examined. Each risk is expanded to see what damage it may cause the project or to one or more stakeholders in the project. The following list of questions helps to analyze each risk.
- What is the potential damage this risk may cause?
- What is the dollar cost of that damage?
- What strategies can be implemented to avoid or reduced this risk?
- What are the costs to implement each of those strategies?
There is another very helpful tool that overlaps the analysis and the next step of prioritization. It is the decision tree. I first learned this tool in a Decision Science course as part of my MBA degree.
The decision-tree is a useful tool when a risk is multi-layered such that more than one decision or mitigation action must be performed over a period of time. Decision-trees are also useful when one or more risks interact with each other and that interaction must be managed.
The process is to create a branching diagram with each branch labeled with an alternative. The branching point between the alternatives is a decision point where one path or the other needs to be selected. At the very end of the tree are the final-result points of the earlier decisions. These end-points are known as leafs. These are the ends of the various pathways through the tree. At each such end-point a result is listed - most commonly a cost or benefit expected written in monetary terms.
This part of the tree construction is very helpful to the analysis phase. A risk can be viewed as a series of decisions and some events that occur because of decision made. The interactions can be complex. A diagram showing those interactions and the pathways of making certain decisions along the way is often the only way to analyze the risk.
This tool overlaps with the prioritization step when {probability|probabilities] are attached to branching points that represent events, as opposed to decisions. The various pathways through the tree are prioritized by calculating the benefit or cost of each pathway. At each branching point in the tree, each alternative is labeled with the monetary cost or benefit of the rest of the path after that point. By working backwards to the initial starting point in the tree, one or another branch will be either the lowest cost or the greatest benefit branch. That path then becomes the highest priority.
This step concludes with the selection of a risk mitigation strategy for each of the risks in the project risk sub-set.
3. Prioritization
The final step in the Risk Assessment Phase is to prioritize the risks. While the method of prioritization is straight-forward, the inputs of probability and cost-assessment are difficult. The
input values require both experience on the part of the project manager as well as the existence of a comprehensive
database of previous project results.
The method is a simple formula of
Risk Exposure = Probability of Occurrence x Amount of Loss
The project manager assigns a probability to each risk and multiplies it with the amount of loss determined in Step 2. Experience will guide the
project manager in determining the proper values of the loss probability. An organizational level database of previous project results would be a great aid, if it were available.
This step concludes with the ranking of the risks by their Risk Exposure value derived from the application of the formula. A threshold level for the Risk Exposure Value (RE) may be set and only those above the threshold will be included in the risk management plan.
B. Risk Control Phase
The purpose of the Risk Control Phase is to create formal plans to avoid or reduce the impact of the risks that were identified, analyzed, and prioritized in the first phase. The fourth through the sixth steps are Planning, Implementation, and Monitoring.
Step 4. Planning
The project manager creates a risk management plan document either separately or as a part of the overall project plan. The risk management plan will describe the details of each risk element and the activities that will either prevent the risk from damaging the project, or if it does cause harm, then how it will be reduced.
For each risk to be included in the risk management plan, the following questions will be answered and written out in a format that allows the project manager to either understand input, make a decision, or to initiate some form of action. The questions are:
- What: a description of the risk and the deliverables associated with that risk.
- Why: a description of the rationale for this risk and why it is significant to the project.
- Who: the person or position of the responsible party(s) who will handle this risk.
- When: describes the time-line for the milestones in the risk mitigation activities.
- With: a description of the resources required to carry out the strategy.
- How: a description of the steps to perform to implement the risk reduction strategy.
The planning step concludes with the written risk management plan document.
Step 5. Implementation
In the implementation step the project manager initiates the risk management plan. This is the activity of informing the required personnel of the plan and initiating their action to perform the steps of each risk mitigation strategy.
Step 6. Monitoring
In the final step, monitoring, the project manager obtains feedback on the progress of the risk reduction strategies. In addition, the project manager is required to keep executives informed of such progress as well.
A useful technique is to keep a Top 10 list of the most critical risks. The status report to the executives will be a summary of the top 10 risks and their stages of avoidance or damage reduction. Such a procedure will ensure the executives are provided only the important information in a summary format.
A software project risk management process involves six steps across two broad phases of Risk Assessment and Risk Control. Following such a process will help the project manager to anticipate risks and work to avoid or reduce their impact on the project.
Taxonomy of Risks
I reviewed the material available from the Software Engineering Institute (SEI) on risk management. Earlier I expressed my preference for checklists and I found such a checklist from SEI entitled Taxonomy-Based Risk Identification. The SEI checklist is a tool for the Risk Assessment Phase, Step 1 Risk Identification as described in the first part of this essay.
It is a technical paper describing the process by which an initial list of risks was established and then its use tested across several projects. The implementation of the list was in the form of a questionnaire filled out by groups of participants at various levels of a software development project. The results were positive and the authors believe the taxonomy-based questionnaire a useful tool for identifying software project risks.
The SEI researchers abstracted out the essence of risk and provided this outline so the project manager can review the categories of different risks and then plan how specific risks in these generalized categories may arise in the specific project currently in the planning stage.
The definition of taxonomy is a scheme that organizes knowledge into categories or pieces and describes the relationships between the pieces.1 The knowledge is organized into three main classes with a total of 13 elements across all three classes, and finally 64 attributes across all elements. An outline2 of the list showing just the three main classes and the 13 elements is
- Product Engineering: technical aspects of the work being done.
- Requirements
- Design
- Code & Unit Test
- Integration & Test
- Engineering Specialties
Development Environment: methods, procedures, tools to create the product.
- Development Process
- Development System
- Management Process
- Management Methods
- Work Environment
Program Constraints: contractual, organization, operational factors within which the project exists, but are generally outside the control of the project team or management.
- Resources
- Contract
- Program Interfaces (relationships to outside groups / stakeholders)
I like the idea of lists. I prefer to work from the top-down in a planning process. A comprehensive list such as the one from SEI, allows me to see the entire spectrum of software project risks. From that large list I can not only zero in on the risks that will be specific to my project, but the remainder of the list forces me to consider possibilities that I may not otherwise consider. It will help brainstorm ideas of new risks that may be hidden behind assumptions I have not considered. The list provides an opportunity to say "What if" on risks that initially appear not to be germane to the present project.
Conclusion
Risks are always present and in many cases are known prior to the initiation of a software development project. However, the project manager needs to perform a comprehensive, organized, planning process to mitigate risk for the project. In this essay I presented two main concepts. The first was a general risk management process presented in class. The second was a specific tool to help in the identification of software project risks.
The general risk management process involves six-steps, three in each of the two phases of Risk Assessment and Risk Control. By following the six steps, the project manager will produce a risk mitigation plan and be able to implement it and monitor the project to ensure its success.
The SEI provides a multitude of resources for software engineering and software project management. In the case of risk management, one tool is the Taxonomy-Based Risk Identification Questionnaire. It provides a comprehensive list of project risks every manager should consider. It is a tool I will use in future projects.
Footnotes:
- Taxonomy-Based Risk Identification, footnote 1, page 1.
- Taxonomy-Based Risk Identification, Appendix A, page A-1 to A-2.
References:
- Carnegie Mellon University Software Engineering Institute The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1994.
- Carr, Marvin J. et al, Taxonomy-Based Risk Identification, Technical Report CMU/SEI-93-TR-6, Pittsburg, PA: Carnegie Mellon University, 1993.