Risk Managment
Business Process Improvement projects usually have significant risks involved. A risk is any potential difficulty or issue that have some impact on the success of the project, or consequential side-effects. Software development projects also have significant risks. Properly managing risk increases the project's predictability and reduces the total cost and timeframe of a project, whilst improving the business value it delivers.
The very first step to successful risk management is to brainstorm the risks involved in the project, and create an initial risk list. The risk list should be reviewed by key members of the project team (including the stakeholders for whom the project is delivering the business value) every one or two weeks. This should be a regularly scheduled activity.
We categorise risks into the following categories (some are applicable to all business improvement projects, others only to software projects):
- Business Process - Risks relating to how well we understand the business processes, or how likely or significant will be any future changes to the business processes.
- Requirements - Risks relating to how well we understand the requirements, or how likely or significant will be any future changes to requirements.
- Resource - Risks relating to the availability of resources, being they personnel, financial, or other resources.
- Constraint - Risks relating to meeting the constraints imposed on the project.
- Development Infrastructure - Risks relating to the tools and infrastructure used by the project team. Examples are the availability of tools, and the level of expertise of the team with the tools.
- Architectural - Risks relating to any new architectures, patterns, libraries, or technologies that have not being used by the project team previously. These are both in relation to the technologies suitability to the purpose, and the team's expertise with the technologies.
- Deployment Infrastructure - Risks relating to the suitability, availability, and reliability of the infrastructure upon which the solution will be deployed.
- Change Management - Risks relating to change. That is changes to processes or tools that affect peoples perceptions or the way they work.
The risk list should be used to drive the project plan. You should plan to mitigate most, if not all of the Business Process, Requirements, Development Infrastructure, and Architectural risks as early as possible in the project. Risks in the other categories should have mitigation strategies and contingency plans defined, but sometimes the mitigation strategies are not able to be executed until later in the project. By mitigating as many risks as possible early in the project, we can expect the bulk of the project to proceed in a more predictable fashion without major surprises (and delays). This contrasts with the more traditional "leave the hard bits until the end" approach, which can lead to the "90% complete, 90% remaining syndrome".
For each risk we maintain the following information:
- Name
- Description
- Category - the category as described above.
- Impacts - a description of the impacts on the project or business should the risk manifest.
- Impact Order - a numeric ranking of the magnitude of those impacts.
- Likelihood - a numeric ranking of the probablility of the risk manifesting.
- Exposure - the numerical product of the Impact Order and Likelihood - this is the primary measure of the significance of the risk and is used for ranking risks, and determining the top 10 risks. The most attention should be given to those risks with the highest Exposure
- Mitigation Strategies - a description of the ways the risk will be mitigated. To mitigate a risk means to employ strategies to reduce the likelihood of the risk, the impacts of the risk, or both.
- Contingency Plans - a description of what will be done should the risk manifest.
- Indicators - a description of symptons that may indicate that a risk has manifested, or is going to manifest.
- Mitigated - Yes/No. Have the mitigation strategies been executed successfully?
- Closed - Yes/No. Is the risk closed? A risk can be closed if its Likelihood is zero. A risk can also be closed if it has manifested, its contingency plans have been executed, and it will no manifest again.
Additional Resources
Online
- Lieberman, B. A. 2002, 'Gambling with Success: Software Risk Management', The Rational Edge, July 2002
