Microsoft Office Tutorials and References
In Depth Information
tasks not on
path of your
The second method of building in slack is the one I like best. You build one
slack task or several slack tasks that occur throughout your project — say,
one at the end of each phase of the project.
Now, there’s one must-do here, even if it seems obvious: Don’t call this task
Slack. Nobody in a position of responsibility would be caught dead approving
slack time for anybody. Give slack tasks appropriately respectable names
that reflect useful (but admittedly, somewhat generic) activities — say,
Engineering Analysis, or Debriefing, or CYA Meeting. Then give the task a
duration that provides breathing space for the other tasks in that phase.
For example, at the end of a two-month phase of designing a new product
package, you might add a task called Design Debriefing and make it one
week long. (That way, if a sudden mandate for design tweaks comes out of
nowhere, you’re covered.) Then create a dependency between that task and
the last “real” task in the phase.
I’m not talking dishonesty here — just reality. In the real world, slack is