Project Manager's Contingency?

During a conversation with a fellow Project Manager (PM) I came across an interesting thought about contingency. As a PM, typically we like to have contingency because we know things will not go as we expect and nothing ever goes according to plan. The conversation was similar to this.

Photo by Loic Djim on Unsplash

KS (her initials): The problem is that when you ask a group to estimate project tasks they will add their own buffer to the tasks, but won't tell you that. Something that takes 3 days becomes 5 before it even gets to the Project Manager.

Me: Right, and if the PM isn't familiar with the task or knows to ask the questions, along with getting honest answers, then he or she will likely further pad the tasks, creating the potential for a lot of buffer, and even potentially killing the project.

KS: I agree. It's really about asking the questions about whether or not it will really take that long, or if they are already addressing the "What ifs" like "What if that person get's sick?" or "Yes that's great if the person can dedicate a whole day to the task, but what if they can't?" 

Me: Exactly and then, of course, we always run into the fact that no matter how much the person tells us that they already built a buffer into the task, they always take the full amount of time, or even plus some, to complete the work!

That last comment is what got me thinking. On some of my larger projects, especially Oil and Gas projects, there was an executive contingency built into the project cost and schedule, but not reflected in the project plan or budget. This contingency was not advertised to the project team and was only to be touched for extreme measures or issues. In some cases, the team would be rewarded for not spending the executive contingency. 

So why isn't there a Project Manager contingency? As identified in the conversation, we all know that people are padding their estimates; and we also know that the work will expand to fill these padded estimates because (as Mr. Incredible once said until he almost missed his own wedding in 2004's The Incredibles) people will think: "Yeah, I've got time."

Which quickly becomes:

Followed by:



Followed by the client pointing out:

Instead of enabling the project team to fill the time until the project is late, what if instead we created a contingency for the Project Manager's discretion that, like the Executive Contingency, isn't built into the project plan or budget? This contingency would then be added to the project as a separate factor and available at the PM's discretion. This way the project team is asked to live up to their own estimates and they don't automatically turn into Mr. Incredible in a tux.

This Project Manager's contingency would be available for use at the PM's discretion and used for Risk Management and time/cost overruns without giving the team a sense of a buffer that can be eaten away because it was built into the project plan. This approach does require the PM to have the discipline to use the contingency infrequently and hold the team accountable, but those are steps a PM should be performing regularly anyway.

As an example, a project is slated to start on the 1st of January and run 1 year, according to the estimates provided by the project team to perform the work. That is a 365-day project schedule (or 262 work days excluding weekends, but not including holidays).  With a 20% contingency, the project would run 438 days, which makes the end date the 15th of March (roughly) the following year. In the normal project case, the project schedule would have that contingency built into the tasks to the point where the project plan would end on the 15th of March. This means that each project team member would be looking at the project schedule and basically thinking "Yeah, I've got time."

The difficulty is that, as stated in the original conversation, work expands to fill the time allowed; meaning that if the contingency is built into each task, then each person will work to meet the identified date with contingency rather than work to complete the task as quickly as possible. So, by removing the contingency and keeping it at the PM's discretion, you would keep the Project Plan with the 1 January completion date, but the PM, end users and clients would expect the project to be complete by the 15th of March!

The same approach could be made for budget, where the individual items purchased or the cost of time spent would be factored as estimated (perhaps with a little buffer), but managed with a PM's buffer that could be used in the case of extreme market changes (like the price of steel increases) or because things were severely underestimated (the piece of code is a lot more complex than originally thought, or more testing is required than originally estimated).

With this approach, I would also work to incentivize the team to meet the original estimates and/or save as much of the Project Manager's Contingency as possible. Perhaps a tiered bonus structure around how close the team can keep to the original approved estimate or a portion of the cost/schedule sharing split amongst the team for not touching the contingency?

With the level of project failures in the world today and the difficulties in project estimating, do you think this is a viable approach? Would you prefer to keep things the way they are? What are you doing in your projects to ensure on-time, on-budget delivery? I would love to hear from you. Please share below!