Do you ever get the feeling that Murphy, owner of Murphy’s Law, invites himself to every project? Anything that can go wrong, will go wrong, so it’s important to anticipate high-risk areas and determine what buffer can be applied to ensure the project is on time and on budget. One way of doing this is to apply contingency to the project schedule. Through experience, I’ve figured out there is a wrong way and right way to do this! Before we get into that, let’s start at the beginning…
Why Do We Use Contingency?
Contingency is used to help account for the unknown. There are many forms of contingency; such as additional money, additional resources, additional time, additional approach (Plan B), etc. By adding contingency, you are allowing yourself flexibility when things go wrong, or when additional work is necessary, to achieve your goal within the original estimate.
As a rule, the higher the risk or the lower percentage of confidence the more contingency should be applied. Although contingency helps with accuracy, there is also a price to pay. Contingency will cost more, so it needs to be evaluated and used discreetly. The project sponsor should approve where contingency is used and the procedure for applying it.
The contingency is applied at that beginning of the project based on the assumptions, the known risks/issues, and the confidence in execution. Throughout the project, the contingency can be reduced based on the changing project environment. If there is a need to add to the contingency, it should be documented in the change control process and approved by the project sponsor.
Before Determining Contingency…
There are two things that need to be done prior to determining contingency:
- Determine the Project Approach
- Create the Project Schedule
Based on the project objective and requirements, it is important to decide the best way to achieve successful results with the resources available to the project. The team to discuss the project approach should consist of the project Sponsor, project manager (PM), and subject matter experts (SME), at a minimum. Once an approach is determined, it should be discussed with resource managers, accounting, and other departments that can assist in supporting the approach. Their input may confirm the approach or suggest changes that will work better with the organization.
It’s important to determine the project approach development timeframe, as well. Since the project approach process may be iterative, it’s good to determine how much time will be allocated to this process and when a decision should be made. Usually 1 week is a good duration for this task.
Prior to starting the Using Contingency process, the project schedule should be created and reviewed. This schedule must contain all of the components of the work breakdown structure, realistic duration’s and milestones. Resource assignments are optional but task owners are essential. By identifying the task owners in a text field, we can see what areas/departments are impacted by the project approach. The project schedule provides the structure for using contingency in areas that have significant risks and that may jeopardize the delivery target date.
After the contingency is applied, the project schedule should be approved by the sponsor and a baseline taken for future reporting.
How to Determine Contingency
Determining contingency is an information review and gathering exercise with the core project team. For areas requiring contingency, identify what type of contingency is needed:
- Resources; which may increase time and cost
- Approach (Plan B); which may increase time and cost
Contingency opportunities can be discovered by meeting with the core project team to review:
Look at the contingency notes from the reviews to see if all the critical areas were discussed.
Contingency may be applied to the approach, the budget, and/or to the project schedule. This document addresses applying contingency to the project schedule.
Creating A Contingency Plan
Based on the reviews and contingency notes, a contingency plan should be created. This plan lists the areas of concern and what type of contingency should be applied. It should also describe how the contingency will be applied to the project schedule and under what conditions it should be used. In the Contingency List, the contingency line item should also have an owner who is responsible for making the decision, when to use it and how much should be used.
Applying Contingency to the Project Schedule
When applying contingency to the project schedule, it should be clearly visibly so the contingency can be managed. Embedding additional hours in the task’s Work field causes the following issues:
- Original estimate for the task is diluted because of adding the contingency hours
- People work to the task’s finish date, which is artificially extended
- Does not give you the option of not using the contingency, since it’s included in the estimate
One way to include contingency that is easy to manage is to:
- Create a separate contingency task that is a successor to the task needing contingency
- Link the contingency task as a predecessor to the milestone being reported on
- Enter notes on the contingency task to describe how it was estimated and why the contingency is necessary
Contingency Tasks Example
In this example, a week needed to be added to Develop Phase 3, to account for complexity and another week was added to Test/Review to account for resource availability. The Finish Variance from the baseline is 10 days or 2 weeks.
By doing this, the resources still work towards the Develop Phase 3 target date of 7/17/18. If needed, the PM/Dev Mgr have an additional week, if needed. If not needed, the contingency task can be inactivated.
Since the contingency is added prior to the Milestone: Dev Phase 2 Complete, the timeline shows the extended date 8/10/18. When we reporting to management, this date will show, as the developers work towards the 7/17/18 date and the testers/reviewers work towards the 8/3/18 date. If the contingency is not needed, the work will be completed before the reported 8/10/18.
If management would like transparency to the contingency tasks, you may want to display the contingency tasks in a different color in the body of the timeline.
Managing Slipped Tasks
Tasks slip for all types of reason. Typical high-risk reasons are:
- Lack of resource availability or late start
- Resource lacks appropriate skills
- Issues prolong the work
- Requirements are not clearly defined
- Designing and creating for the first time
- Hand-off was late from another department
As tasks slip, there are multiple ways to address the slippage:
- If the late task is not on the critical path, finish as soon as possible
- If the late task is on the critical path, determine if other tasks need to be started without the late task finishing
- Possibly add more resources
- Work more hours in the same duration (evenings, weekends)
- Possibly adjust requirements or scope
- Make up the lost time elsewhere in the schedule
- Use contingency, if available
As you can see, there are many ways to get the project back on track; therefore, contingency should be used as the last resort. Also, once the contingency is used, there is no safety net available while the other options are being applied. It’s important that the sponsor/PM/manager is aware of the strategy for getting the project back on track and that they approve when the contingency is used. After using contingency, update the Contingency List (in the Contingency Plan), to determine what was used, why it was used, and what is remaining.
Contingency benefits the project by increasing the odds of delivering on time and on budget. More times than not, management would like a realistic schedule with contingency built in and managed, rather than an unrealistic schedule.
Contingency applied correctly can be communicated and managed without impacting the original estimate and finish date of the task. This way, the project team is still driven to complete the task on time. This way, if Murphy shows up and there are major issues that can’t be addressed by regular means, contingency provides a safety net until the issue is resolved.