Best practices for adding planned slack to a project

[AndyGagnon]

Hi All!  

my first post of many to come!

I'm interested in hearing any best practices of how to add planned slack to a project.  I manage a portfolio of about 300 mini-projects for a manufacturing company.  Inevitably, each project slides a bit due to people missing work, miscalculating the amount of effort needed, etc.  

Since we are striving to give customers an accurate eta that they can count on for their projects (our company is a component provider to aerospace), it's frustrating to all when we keep updating our ship date, often a day after we sent them the last update. :(

Currently I add a task called "planned slack" for 3-5d at the end of each mini-project, then either we ship early :) or we eat into that slack to make the eta we committed to.

Any better practices out there?

Thank you!

[#2 · Accepted solution]

@AndyGagnon, what you describe is not too far from accepted best practice, as long as you avoid the term "planned slack" (which implies a completely different concept.)  Conventional schedule risk management would suggest that appropriate terms like "schedule contingency", "schedule buffer", or "time risk allowance" can be added to a baseline schedule as long as they a) are based on a quantitative schedule risk analysis; and b) are allocated to schedule tasks in a way that reflects the true schedule risks.  Ideally, the forecast dates in such a risk-adjusted schedule should reflect a 50% chance of overrun/underrun.  Real-life project sponsors and customers typically demand a much higher probability of underrun, e.g. "promised" or "guaranteed" dates.  Unfortunately, such guarantees typically drive over-conservative buffers/contingencies and reduce the overall project value.

[#3]

Thanks @TomBoyle !!