How can I add contingency to tasks in Microsoft Project?

Question

I'm trying to transfer an existing project plan to Microsoft Project (meaning I can't change how it's organised). Each task has a duration in days then a contingency in days showing how much the task might overrun due to complexity, etc:

Task    Duration (days)  Contingency (days)
1       5                2
2       10               5

Is there any way of adding this to tasks in Project?

Answer 1

I have some misgivings about "contingency tasks" - seems to undercut Earned Value Management. I'm not sure how to insert the contingency task automatically; should be possible to do it manually.

I think that Mr. Espina has described using Critical Chain Management to address the problem of managing the risk of task slippage. When I have had a need for similar buffers, I've used two techniques. First is to manually insert a milestone after the task, and move the milestone to manage the slippage. The other is to use PERT Analysis. MS Project allows you to plan the schedule based on weighted estimates. That allows you to display an optimistic/pessimistic/most likely schedule. Not precisely what you're looking for, but the technique may help.

Mechanistically, I'd create: (Here's where I'm trying to answer OP's question directly with minimal assumptions)

• A custom field for each task to track the contingency
• A custom field for each task to track the pessimistic duration (duration + contingency)

I think that will preserve the constraints imposed on the project. The question that remains in my mind is how I would use the information to convey information to my stakeholders. I could run a simplistic estimate that shows the optimistic end date, the pessimistic end date and the PERT end date. (This is what I've done most recently because my stakeholders aren't interested in any more complex analysis, and the quick experiments I've done indicate that the answers converge on the PERT answer anyway).

Because I'm a frustrated quant, I'd probably also record the actual duration for every task/work package and generate a quick distribution of variances and use that to build a monte carlo model for the rest of my project. (e.g. "In the past, 50% of work packages deliver on time, but 30% use most of the contingency, 10% use all of the contingency and 20% exceed the contingency. If I assume that pattern continues going forward, then let's simulate the project end date if future work packages follow the pattern of prior work packages.....)

I'd also look for patterns in the distribution... but I'm way beyond what OP asked at this point, I'm just thinking about how I'd use the data.

Answer 2

I do not believe Project has a method of encoding an explicit contingency into specific tasks. I can think of three work-arounds in addition to the idea in the original question, ranked in what I think is decreasing utility:

1. Add the contingency to the base duration and make this the task duration in Project. The downside of this method is that it blurs the distinction between the base and contingency amount and buries all the schedule margin in the individual tasks. That said, it's more likely to be a realistic schedule than using all the base estimates. If you really want to retain the contingency information you can add an extra column and easily paste the contingency information into your schedule. It would be used for anything by project, but the information will be there for later reference.

2. Remove the contingency and carry all program float at the end. In this method the Project task durations match the base estimates. The resulting project end date will be sooner than in your current tool and the difference will be the total program float to that date. Project will calculate the float (i.e. number of days until a given task will be on the critical path), which can help you see how much contingency each task has before it will begin to impact the project-level end date. The downside of this approach is it represents the most optimistic schedule, and if you have to status your progress to these dates to your management you're definitely going to be behind on some of your tasks and might catch unnecessary hell.

3. Add new tasks for contingency, where each contingency task is finish-to-start linked to the base task. This would double the number of tasks in your project and seems like a terrible idea to me, but it's theoretically a solution. You could also do this only for contingency at the end of a group of tasks, but honestly this is what the float metric is for.

Answer 3

For the sake of transparency in the past I've separated out contingency reserves as separate tasks. This helps communicate the range of dates a given task can be expected to finish without assuming that the team needs/wants to understand Project as well as the PM. This works for critical path management techniques, as David says the "buffer at the end" approach is the critical chain techniques so the articles you've been reading have been talking about apples when it seems you have been looking for oranges.

Answer 4

Theory of Constraints and Critical Chain Project Management talk about adding buffers to the schedule based on theoretical assumptions by E. Goldratt. You can easily google this and find a ton of information. But this may not be what you are talking about.

If you are not reducing your targets by 50% as CCPM suggests, then I would advise not adding buffers in your schedule as your asking.

The planning value you choose in all of your work packages should already contain the degree of risk you are willing to assume for that project at that time. For example, you understand this project to be risky because of the environment and it is a firm fixed price. For package A, you estimate eight to 15 days, most likely 10; for package B, you estimate 12 to 20 days, most likely 16. Since this is higher risk, the planning values you choose for A might be 12 and for B it might be 18. This represents values on the outside of the curve, giving you more probability that you will finish at that day or before then at that day or after.

So your contingency is calculated at each package and built in. In a less risky environment or type of contract, you may choose 9 and 14 days.

The rest of the risk you leave on the table, the balance between your planning value and the very worst scenario + other risk contingency, is capture in dollars and held in reserves. It is not on the schedule or your performance measurement baseline but part of your total allocated budget.

Answer 5

In order to simplify the work in MS-Project and get real EV data as you progress through your project, add contingency into your base task using PERT and risk based analysis. I wouldn't put a separate contingency task after each base task all through my project schedule... it can mess up your schedule reports as well.