Effective Project Management with MS Project : Planning for the Unexpected

Even the best crafted project plan can be derailed by something unexpected happening, like your main developer becoming sick or losing network connectivity for a day. Such unexpected events can disrupt your project schedule, making you miss your delivery dates which is never good.

To try and mitigate this, it is possible to plan for the unexpected, making provisions in your schedule should something out of the blue happen. This is achieved by adding something called contingency. At it’s core, there are two types of contingency:

• Effort contingency – an extra bucket of effort to your schedule that is used in case extra work is required, or items take longer than originally thought;
• Schedule contingency –  extra duration to your schedule in case of unexpected delays.

Effort contingency

Unfortunately no matter how good your estimation skills are, some tasks in your schedule are going to go over and some are going to come in under. Sometimes it will even out, but most of the time it won’t, so it’s important to make sure you have some effort contingency on your schedule to dip into if necessary, think of it as a planned emergency savings account.

Adding effort contingency to a schedule is incredibly simple, all you need to do is add a new task to your schedule that will contain your effort contingency . The effort amount is usually calculated as a function of the overall project effort, I have worked at organisations where the contingency ranges from 10% through to 50% depending on the riskiness of the project, the number you choose is up to you, but 25%-30% is a good range. When adding a contingency task in a commercial setting, it is important you make sure the task has a costed resource assigned against it, so when any budget or costing information is estimated from the schedule, it includes the effort contingency.

As tasks go over their original estimates, the effort contingency can be drawn down. So for instance if a task goes over by 2 days, the effort contingency will be reduced by 2 days to ensure the original effort remains unchanged.

I will discuss effort contingency in more detail in a later post covering tracking.

Schedule contingency

Typically people develop project schedules with each resource working 100% of the time, so the plan assumes that each resource will come to work each day and work a solid 8 hours on each task. Now in the real world, this simply doesn’t happen, staff can become sick unexpectedly, or need unplanned leave. If you haven’t taken this into account, tasks will start slipping and so will the completion date. With the introduction of schedule contingency you can minimise the impact of these unexpected events (but it doesn’t magically stop them).

There are two ways you can add schedule contingency to a plan.

1. Add a project slack time manually

Slack time can be added throughout a project schedule. Typically it makes sense to add slack at the end of phase or at a logical completion point in the schedule. The diagram below shows some schedule contingency has been added between the completion of Task 2-1 and the Phase 1 Complete Milestone.

This schedule contingency provides a buffer, should the tasks in phase 1 take longer than expected. This buffer will reduce the change of the Phase 1 Complete milestone being missed and the overall project schedule getting blown out. The slack can be added either via a manual constraint or with a formula (<taskid>FS+5d).

2. Change Resource utilisation

The second way of adding schedule contingency is to change the resource utilisation. Project assumes when you add a resource that they will be available 100% of time, however by changing the maximum units it is possible to apply a reduced utilisation rate, which will have the impact of making a task have a longer duration. By reducing the max units to say 80%, a task of 5 days’ work effort will take 6 days to duration to perform, giving a 1 day schedule contingency should the person performing the task be sick.

To change the utilisation of a resource, select the Resource Sheet view and modify the Max Units column from the default 100% down to 80%.

Now each time that resource is scheduled, they will be scheduled at 80% instead of 100%.

Both of these approaches have their relative merits. Personally, I tend to go with the utilisation based approach more often than not, simple because customers are less likely to argue about a project schedule with an implicit schedule contingency in each task, than where there is a 5 day schedule buffer at the end of phase.

Hopefully the next time you develop a project schedule, you will include both effort and schedule contingency to ride out any unexpected events in your project.