Slack, aka 'buffer', aka 'white space', aka 'early finish', is the last thing to schedule.
After all the other stuff is scheduled.
Why?
Because slack should be used (applied) last as a way of making space for schedule extension risk.
Has to be in the baseline
But in order for it to be applied properly, slack has to be in the baseline schedule to start with. In other words a schedule without slack is not a real schedule, but rather just a hopeful schedule.
What can you do with slack?
It seems that scheduling slack is just scheduling free time and unnecessarily extending the schedule.
Not so.
Here are things you can do with slack that are value-adding:
- Protect the critical path: There are probably a lot of tasks that join the critical path, feeding partial product into the final outcomes. If those dependencies are late, so might the CP be late if it is not buffered to absorb those problems. "Critical Chain" scheduling theory is a good example of how the CP is protected with slack.
- Relieve constraints: Sometimes there is a constraint in the workflow and stuff isn't flowing as it should. Using Theory of Constraint techniques, other elements of the workflow are usually rescheduled, changed in scope, or new tools and training is applied. To make room for these new or changed activities, slack is required.
- Protect a milestone: Even if a milestone is not on the CP it needs to be respected for its intended finish date. If there are more than one activity that contributes to the milestone completion criteria, then slack on the various joins to the milestone will protect its date.
The one thing to avoid is "latest-start" scheduling. Latest-start is, in effect, putting the slack first rather than last and using the slack before any risk appears. A total waste of resources!
Like this blog? You'll like my books also! Buy them at any online book retailer!
