MS Project Online
Is there any best practice/recommendation when it comes to setting up a task as a buffer? Both with or without resources assigned.
Is there any reason it has to be a task? Have you considered using a dependency Lag? For ex: Task A has a successor of Task B with a 5 day lag. As such, Task B will start 5 days after Task A finishes.
Kennet, Daryl is correct to define a reason to make it a task rather than a dependency, but it’s a good question. Experts will lean towards a lag but it’s also a personal choice. Let me give you a couple of examples I might use. If the dependency is a set dry time for concrete then I would lean to using a lag. If it is more like a purchase delivery timeline that still has to be managed I might use a task. Anything in the middle, to me, is a personal choice. Hope that helps…
There are two shock absorbers needed ahead of the project’s delivery task to forecast a reliable product delivery date: a lag for an Aggregate Risk Contingency and a Start No Earlier Than (SNET) constraint to cover estimating uncertainties.
A lag is incompressible; so, it is adjusted when a risk actually occurs. however, some risks can recur, e.g. loss of a key resource. In such cases, the Aggregate Risk Contingency needs to be built up again after each occurrence.
To have a Risk Register with risks that would produce delays and to have likelihoods that those risks will occur justifies having an Aggregate Risk Contingency to cover any of the risks that do occur. If task estimates include an allowance for task risks, those should not be included in the Aggregate Risk Contingency to avoid double counting the potential delay. The size of the Aggregate Risk Contingency can be calculated in the Risk Registry if the Registry contains median estimates of potential delays and the likelihoods of occurrence remaining after mitigation efforts to reduce impact and/or likelihood. The calculations are presented in a PMI paper from the 2013 Scheduling Conference.
An Uncertainty Buffer using a SNET constraint on the product delivery task is a compressible shock absorber. In the Critical Chain Method, Goldratt’s policy is to plan schedule recovery if the Uncertainty Buffer is penetrated 1/3. If it is penetrated 2/3rds, then the recovery plan is implemented, building the buffer back to what is needed to complete the project.
To have an estimating Uncertainty Buffer is only appropriate if the task estimates are median values, not conservative estimates. With median value estimates, half the tasks should exceed their median estimate, half should come in below their median estimate. A conservative estimate contain an uncertainty buffer in each task. That buffer is the difference between the median estimate and the conservative estimate. If estimates are conservative, adding an Uncertainty Buffer would be double counting the allowance for delay.
The problem with conservative estimates is that many resources seek to “finish on time” and often delay getting started on a task until there is just enough time left to get the task done by it’s Finish date. Then, when an issue comes up, they’re late or forced into heroic, error prone effort. Better is to use median estimates and to get resources to “start tasks on time,” covering issues with schedule compression or with the portfolio management reserve.
The size of an Uncertainty Buffer can be calculated by inserting custom columns for median and for conservative estimates. Copying the conservative estimates column into the Work column causes the schedule to forecast the product’s conservative delivery date. Copying the median estimates column into the Work column cause the schedule to forecast the product’s median delivery date. A part of this difference, e.g. half the difference, can provide the Uncertainty Buffer sizing. This buffer is added to the schedule when it is set to median values, since it is unlikely all tasks will need their conservative estimates.
Applying an Aggregate Risk Contingency and then an Uncertainty Buffer, together with a schedule recovery policy provides a realistic, shorter project with a more reliable delivery date than with conservative estimates and no allowance for risks of delay.
Thanks for replying Daryl, Larry and Oliver.
I will study your recommendations and get back if necessary.
Using a task as a duration buffer gives you a higher level of visibility in the Gantt. And is easier to understand. Whereas a lag or lead is not as obvious. Whatever you chose, I suggest staying consistent.
I use a duration buffer at the end of the project for my contingency time to protect the project’s completion date.
Similar to David Simon, quite often I use a task near the end of my schedule as a duration buffer to protect the projects completion date. I generally just maintain it manually, but found this article interesting: “Creating a Dynamic Project Buffer in Microsoft Project” – http://www.pmconnection.com/modules.php?name=News&file=article&sid=40
Hope this helps!!
Thanks for your input.
P.s. I cant access that article you are referring to.
I tried the link provided by Rish – and it works for me.