Project Plan > Risk Management

Release Information

Project: PROJECT-NAME
Internal Release Number: X.Y.Z
Related Documents:
LINKS-TO-RELEVANT-STANDARDS
LINKS-TO-OTHER-DOCUMENTS
Process impact: This document records the major risks to the success of the project and strategies for controlling them. Thinking through risks in the planning phase can help you think of ways to improve the plan. The risk map helps project members identify the most important risks at a glance. A risk can be mitigated by actions that reduce its likelihood or impact: moving it from red toward green. This document does not cover risks to users.
TODO: First, read the sample risks and consider how they apply to your project. Update the risk map to place the sample risks in the appropriate cell. Then, quickly list new risks and add them to the risk map. Come back to think through mitigation strategies. If you don't plan to do anything to mitigate a risk, state that.

Update your project plan with any new tasks needed to mitigate risks. Use an issue tracking tool to assign responsibilities and track status of risks and tasks.

Risk Map

Likelihood \ Impact Catastrophic Critical Significant Marginal
Very likely None R-10 R-05 R-06 None
Likely None R-02 R-01 R-03 R-04 R-11 None
Unlikely None R-07 R-08 R-12 R-13 R-09 None
Very unlikely R-14 None None None

Risk Details

Risk ID Description Mitigation Strategy
R-01 There are significant technical difficulties in this project. This will be a risk because only one person on our team has much experience with NEEDED-TOOL-or-TECHNOLOGY. We will address this risk by scoping and scheduling the project to leave enough time for training and reviews.
R-02 We could exhaust our schedule without producing a release. The schedule for this project is very short.
  • start with a schedule that we all honestly believe is possible
  • scope the release conservatively
  • produce a working subset early
  • plan a series of enhancements that could be slipped to later releases, if needed
  • add resources early, and plan time for training an communications
R-03 The performance of the system will be significantly impacted by the decisions made during database design. None of our current team members has experience with database optimization.
  • plan extra time for training
  • arrange a review meeting with an experienced DBA
  • buy a tool that makes this task easy
  • hire a consultant from the database vendor
R-04 We could be underestimating the effort needed for known tasks.
  • compare the schedule to schedules from previous projects
  • review the draft schedule with MENTOR
  • add buffer time
R-05 We could be underestimating the impact of unknown tasks.
  • compare WBS to recent experience with a similar project
  • add buffer time
R-06 We could be underestimating the dependencies between tasks.
  • review the draft schedule to look for missing dependencies
  • select modularity as a high priority design goal to avoid introducing new schedule dependencies
  • add buffer time
R-07 We could have misunderstood the customer's requirements.
  • continue to work closely with the customer to validate requirements documents
  • create precise and complete SRS documents
  • deploy early access versions to gather more feedback
R-08 The customer could change the requirements.
  • work hard to get the right requirements the first time
  • enforce change control policies that manage requested changes
  • keep the project schedule and scope small, so that we do not expect significant changes within that time period
  • design the system to be flexible and extensible
R-09 We could face major difficulties with the technology chosen for this project.
  • allocate adequate time for training
  • have a technology mentor or consultant to support us
  • evaluate the feasibility of technical choices before allocating resources
  • design the system to allow an alternative technology to be used instead
R-10 We could have low quality that demands significant rework.
  • start with high quality requirements and design
  • reuse high quality components
  • follow a QA plan that both builds quality into the product and tests for defects
  • track defects and actively manage quality throughout the project
R-11 We could incorrectly assess our progress until it is too late to react.
  • start with a schedule that we all honestly believe is possible
  • assess progress in a way that is quantified and transparent
  • revise the schedule and scope as soon as needed
R-12 We could lose resources: e.g., team members could get sick, spend time on other projects, or quit.
  • management will allocate staff for this project and those team members will not work on other projects
  • quickly fill any vacated position
  • we can borrow resources, if needed
R-13 There may be a misalignment of stakeholder goals or expectations.
  • encourage frank and honest discussions with all stakeholders before the project kickoff
  • continue to work closely with all stakeholders
  • identify a single project champion who can work closely with other stakeholders
R-14 A major business change could occur: e.g., the customer goes out of business or we go out of business for reasons unrelated to this project.
  • qualify the customer before the project is approved
R-15 SOMETHING-BAD could happen to PROJECT-ELEMENT
  • MAKE IT LESS LIKELY WELL AHEAD OF TIME
  • MAKE IT LESS LIKELY JUST BEFORE IT HAPPENS
  • REDUCE THE IMPACT OF THE FAILURE
  • FIND AN ALTERNATIVE PATH TO SUCCESS
R-16 SOMETHING-BAD could happen to PROJECT-ELEMENT
  • MAKE IT LESS LIKELY WELL AHEAD OF TIME
  • MAKE IT LESS LIKELY JUST BEFORE IT HAPPENS
  • REDUCE THE IMPACT OF THE FAILURE
  • FIND AN ALTERNATIVE PATH TO SUCCESS
R-17 SOMETHING-BAD could happen to PROJECT-ELEMENT
  • MAKE IT LESS LIKELY WELL AHEAD OF TIME
  • MAKE IT LESS LIKELY JUST BEFORE IT HAPPENS
  • REDUCE THE IMPACT OF THE FAILURE
  • FIND AN ALTERNATIVE PATH TO SUCCESS
R-18 We could exhaust our RESOURCE
  • MAKE IT LESS LIKELY WELL AHEAD OF TIME
  • MAKE IT LESS LIKELY JUST BEFORE IT HAPPENS
  • REDUCE THE IMPACT OF THE FAILURE
  • FIND AN ALTERNATIVE PATH TO SUCCESS
R-19 We could exhaust our RESOURCE
  • MAKE IT LESS LIKELY WELL AHEAD OF TIME
  • MAKE IT LESS LIKELY JUST BEFORE IT HAPPENS
  • REDUCE THE IMPACT OF THE FAILURE
  • FIND AN ALTERNATIVE PATH TO SUCCESS
R-20 We could fail to DO-SOMETHING
  • MAKE IT LESS LIKELY WELL AHEAD OF TIME
  • MAKE IT LESS LIKELY JUST BEFORE IT HAPPENS
  • REDUCE THE IMPACT OF THE FAILURE
  • FIND AN ALTERNATIVE PATH TO SUCCESS
R-21 We could fail to DO-SOMETHING
  • MAKE IT LESS LIKELY WELL AHEAD OF TIME
  • MAKE IT LESS LIKELY JUST BEFORE IT HAPPENS
  • REDUCE THE IMPACT OF THE FAILURE
  • FIND AN ALTERNATIVE PATH TO SUCCESS

Risk Management Checklist

Do the mitigation strategies in the risk list provide enough assurance that the project succeed?
Yes, if the mitigation activities are carried out as planned, we are confident that project can succeed. We will, of course, adjust this plan as needed.
Yes, this plan has risks, but those risks are acknowledged by and acceptable to the project stakeholders.
No, this plan leaves open several risks that the project stakeholders are not aware of, or would not accept.
Has this Risk Control Plan been communicated to the development team and other stakeholders?
Yes, this document is being posted to the project website. It will also be discussed at the first team meeting. Feedback is welcome.
No, that is itself a risk.
Could the likelihood or impact of some risks change for the worse?
Yes, we will reconsider each risk periodically.
No, we already understand these risks very well and have estimated them pessimistically.
TODO: Check for words of wisdom for additional advice on this template.
Company Proprietary
Copyright © 2003-2004 Method Labs. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.