Your float values for sub-critical tasks are not actually slack for the rest of the project. You can increase float on sub-critical tasks with standard project management techniques like:
- Reducing scope for the sub-critical task elements.
- Increasing resources assigned to each task or milestone.
- Eliminating non-essential milestones or work elements.
While not recommended, you can also apply techniques from the critical path such as "fast-tracking" or "crashing the path" of sub-critical tasks, but that isn't really part of the official methodology. Applying these techniques away from the critical chain may reduce crash duration of the sub-critical tasks, but will generally cannibalize resources from the critical path to do so.
What Slack is For
Slack in a project schedule generally accomplishes several main goals:
- De-optimizes sub-processes in order to smooth the overall project plan.
- Prevents the 100%-utilization fallacy from making your process brittle.
- Gives you buckets of time, money, or team capacity to borrow against, rather than forcing a recalculation of your plan at every hiccup.
Your Critical Path Has No Slack
Your critical path has zero slack. You define the critical path as:
A->B->E->F = 14 weeks is the critical path
None of the linkages between critical-path has any slack. Whether or not this is true in real life, I have no idea. However, your diagram explicitly says Slack = 0 for each one of the critical path items. Consider that:
(0 float) * (4 chained milestones) = no slack on critical path
Since you have zero slack in your critical chain, any real-life process imperfections will create drag on your project. That means no items on your critical path can accept any slippage at all without forcing you to recalculate your entire schedule, and may force you to re-evaluate your budget or shipping dates as well. That seems bad.
Your Sub-Critical Path Doesn't Add Slack
Delays in tasks or milestones that aren't on your critical path shouldn't delay the overall project. You haven't defined what these non-critical tasks represent, but since they're not on your critical path they probably represent:
- Optional features.
- Additional scope.
- Fruit cake re-gifting exercises, or something else equally unrelated to a shippable product.
Regardless of what they represent, and even if they are essential to the final product, slack in sub-critical tasks only allow you to adjust the start or end dates of those tasks within tolerances; they don't buy you anything related to your critical chain.
A Better Model for Slack with Critical Path
According to Wikipedia's entry on the critical path method:
Although the activity-on-arrow diagram ("PERT Chart") is still used in a few places, it has generally been superseded by the activity-on-node diagram, where each activity is shown as a box or node and the arrows represent the logical relationships going from predecessor to successor as shown here in the "Activity-on-node diagram".
The benefit of this model over the one in your question is that it allows you to model variance on the critical path, which is something that your sample currently does not provide. It may therefore be worth re-evaluating what you're trying to model, and whether activity-on-node will provide a better planning tool for your specific use case.