A contingency plan is an alternative plan that will be used if a possible foreseen risk event becomes a reality. The contingency plan represents actions that will reduce or mitigate the negative impact of the risk event.
A key distinction between a risk response and a contingency plan is that a response is part of the actual implementation plan and action is taken before the risk can materialize, while a contingency plan is not part or the initial implementation plan and only goes into effect after the risk is recognized.
Contingency Plan
Like all plans, the contingency plan answers the questions of what, where, when, and how much action will take place. The absence of a contingency plan, when a risk event occurs, can cause a project manager to delay or postpone the decision to implement a remedy. This postponement can lead to panic, and acceptance of the first remedy suggested. Such after-the-event decision making under pressure can be potentially dangerous and costly.
- Contingency planning evaluates alternative remedies for possible foreseen events before the risk event occurs and selects the best plan among alternatives. This early contingency planning facilitates a smooth transition to the or work-around plan.
- The availability of a contingency plan can significantly increase the chances for project success. Conditions for activating the implementation of the contingency plan should be decided and clearly documented.
- The plan should include a cost estimate and identify the source of funding. All parties affected should agree to the contingency plan and have authority to make commitments. Because implementation of a contingency plan embodies disruption in the sequence of work, all contingency plans should be communicated to team members so that surprise and resistance are minimized.
Here is an example: A high-tech niche computer company intends to introduce a new “platform” product at a very specific target date.
The project’s 47 teams all agree delays will not be acceptable. Their contingency plans for two large component suppliers demonstrate how seriously risk management is viewed.
One supplier’s plant sits on the San Andreas Fault, which is prone to earthquakes The contingency plan has an alternative supplier, who is constantly updated, producing a replica of the component in another plant.
Another key supplier in Toronto, Canada, presents a delivery risk on their due date because of potential bad weather. This contingency plan calls for a chartered plane (already contracted to be on standby) if overland transportation presents a delay problem.
To outsiders these plans must seem a bit extreme, but in high-tech industries where time to market is king, risks of identified events are taken seriously.
Risk response matrices such as the one shown in the figure below are useful for summarizing how the project team plans to manage risks that have been identified.
Again, the Windows 7 project is used to illustrate this kind of matrix.
The first step is to identify whether to reduce, share, transfer, or accept the risk. The team decided to reduce the chances of the system freezing by experimenting with a prototype of the system. Prototype experimentation not only allows them to identify and fix conversion “bugs” before the actual installation, but it also yields information that could be useful in enhancing acceptance by end-users.
The project team is then able to identify and document changes between the old and new system that will be incorporated in the training the users receive. The risk of equipment malfunctioning is transferred by choosing a reliable supplier with a strong warranty program.
The next step is to identify contingency plans in case the risk still occurs.
For example, if interface problems prove insurmountable, then the team would attempt a work-around until vendor experts arrived to help solve the problem. If the system freezes after installation, the team will first try to reinstall the software.
If user dissatisfaction is high, then the IS department will provide more staff support. If the team is unable to get reliable equipment from the original supplier, then it will order a different brand from a second dealer.
The team also needs to discuss and agree what would “trigger” implementation of the contingency plan.
In the case of the system freezing, the trigger is not being able to unfreeze the system within one hour or, in the case of user backlash, an angry call from top management.
Finally, the individual responsible for monitoring the potential risk and initiating the contingency plan needs to be assigned. Smart project managers establish protocols for contingency responses before they are needed.
This article is part of a much larger post on risk management. If you have landed on this article directly from a search engine I would recommend you head to this article Risk Management Guide, where you can get the full picture on how I have organized the series and have the the correct sequence.
