What's the best way of planning for the possibility that a key member(s) of the team might want to take leave at some point during a project?

I understand one solution is to buffer the project sufficiently so that the project / task can soak up this time without affecting key milestones, however - it strikes me that building in this sort of buffer as standard for all tasks in the project will very quickly start to add a significant amount of bloat into the project.

I also find that buffer time can become "dead time". For example, our validation department operate a fairly tight timetable, therefore if you assume a task has a two week buffer after it - and validation has been booked after that two week period - what happens when that buffer isn't needed (the task runs to time) - that leads to a two week delay before moving to the next activity (the validation team isn't available until the week it was booked for).

Is this just basic project management stuff - i.e. if the buffer isn't used, great - the team move onto something else for two weeks?

Would welcome thoughts on this topic.

4 Answers 4


This is an organic risk of projects, i.e., it is always there, it has always been there, and it will always be there. Trying to dissect this and calculate some type of contingency or buffer is a HUGE waste of your time.

The probabilistic distribution of any task is created by a plethora of random variables that can both favorably and unfavorably affect that task. Resource things make up some of those variables. These things include having less resources than planned, having a skill set gap you did not anticipate, and having a higher than normal attrition. Other things could also be favorable, like having an experienced team who are used to working together and have performed this task 20 times before. Most of these variables are considered stochastic where it is unwise and wasteful to try to chase and control.

So, the target time you ended up choosing for this task, which falls somewhere on that distribution, already has built into it time to handle these unplanned things that will hit you from time to time. Where you fall in that distribution is a function of your risk appetite. Therefore, if you have some concern for this, move your target time to the right a bit.

Part of your PM responsibilities is to build project capabilities that have redundancies and no single point of failure. This means you have capabilities that are running smoothly, predictably, and, if something unplanned happens, you can remove and replace the capability component--human in this case--and keep going with nothing more than a blip on your performance.

The reality is, we all have key resources. Ideally, we would have none. Try to move in that direction.

EDIT: Re. "Text book PM scenario..." It may very well be. Projects and ongoing operations rarely grow their capabilities much above level two of a five-level maturity scale. This is because most organizations do not know how. The only recourse is to rely on the heroic efforts of a few key resources, and if one of them leave, it sends a ripple effect across the organization. So my advice might be ideal and rarely achieved...so try anyway.

  • I really liked your answer, although you kind-of lost me near the end (e.g. Part of your...). This sounds like a textbook PM scenario, but is that realistic given today's climate? It seems that more shops are having to navigate resource/talent shortfalls and struggle with serious upsets in momentum when key talent is not available (for whatever reason). It seems like more and more project teams consist of a lot of individual key personnel. So what to do then, how can this be managed? With respect... I'm not meaning to push-back but I'm just not sure this is a full answer to the question
    – JoeGeeky
    Dec 17, 2011 at 23:34

Take a look at Critical Chain project management. It uses total buffer as a fungible commodity that can be moved around the entire project lifecycle.


What about agreeing with your stakeholders a list of must-have and nice-to-have tasks?

Adopting this approach, your team will have planned tasks for the whole project life as well as will have narrowed down beforehand what is accepted to be postponed for next releases, in case of any unexpected scenario change.

Therefore, you'd be mitigating the problem, without having spare time at the end of the project cycle (although we know that even consider the possibility of having a 'spare time' at the end of the project is a kind of over optimistic approach).

Some further details on this idea (which I've already used in the past) can be found HERE.


You could ask your team members to schedule their time off in advance so you could plan for it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.