Let’s be frank.
Things usually don’t turn out the way they were planned. Work gets delayed, people get sick and conditions change that are outside of your control. As a result, the plan that you spent hours on can become obsolete from one day to another.
A way to account for this uncertainty is to calculate buffer into your project.
(Sometimes people talk about contingency. It’s the same thing.)
What is project buffer?
Project buffer is the extra time you add to a task, so that even if it gets delayed, it won’t affect the overall project schedule. The buffer-adjusted dates then become binding deadlines you communicate to your team (more about setting project deadlines).
Example:
You are leading a project for building a bridge across a river. An engineer on your tean is working on the drawings which have to be submitted to the authorities by Friday, 30-June.
Theoretically, you could give the engineer the deadline Thursday, 29-June.
But you and I know how risky that would be.
What if ….
- the engineer gets sick one week before submission
- the engineer’s PC crashes 3 days before submission
- you notice a serious mistake in the drawings, 1 day before submission
Do you ever want to get into such a horrible situation?
For sure not. That’s why you factor in sufficient buffer of, let’s say 1 week. The project task create drawings therefore needs to be finished by 23-June. If something goes wrong along the way, you and your team still have time to turn things around and meet the submission deadline.
Here’s how the project buffer will appear on the timeline:
Get my project plan template if you don’t already have a good one.
Do you always need a buffer?
No, you don’t.
It all depends on whether a specific project task is connected to another task, so that it needs to be finished first before the other task can start.
Figuring out how much buffer you need
Here’s some guidance for you.
First off, your buffer-adjusted deadlines will never be the ideal case. Every project manager wants to have 2x the time for their project. But that’s not gonna happen. So, the project buffer is the ‘best you can get’ given that time is limited.
There is no formula that will spit out the ideal buffer. That’s why I’m giving you a few questions that will help with your planning:
- “How much time do we need to turn things around?”
Take our example from above: One of your team members is creating technical drawings that must be submitted by 30-June. If his computer crashed shortly before the finishing line, how many days would you and your team need to set up a new computer, load the drafts and finish the bridge drawings? 2 days? Four days? Or even a week? - “How severe would be the impact of the deadline not being met?”
If the deadline can get pushed further and it doesn’t really hurt anyone, you can calculate a smaller buffer. On the other hand, if major negative consequences can be expected in case of delay (financial impact, project in jeopardy), factor in a larger buffer. - “How much can I trust this person to meet the deadline and to deliver high-quality results?”
Some people are more dependable when it comes to meeting deadlines than others. Set buffer according to the level of trust you have with the person doing the work.
Knowing how much buffer is required is also a matter of experience. The more projects you’ve managed, the more you’ll sharpen your 6th sense, which is to detect and mitigate risk. You’ll naturally come up with solid deadlines that reflect the risk inherent in a task.
Yours,
