Slack value in a project network diagram?

Question

Can you please tell me how can I use the slack value in my network diagram to readjust it(if it is applicable)? Using the following table, I have calculated the slack value and drawn a network diagram.

Finding Slack Value:

A->B->E->F = 14 weeks is the critical path
A->B->D->F = 10 weeks
A->C->E->F = 12 weeks

I want to keep the original project duration intact(therefore, I am not going to change the number of weeks used in the critical path). But I want to reduce the number of weeks used in non critical paths. Can I do that by using the slack values(or another method)?

Answer 1

TL; DR

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:

1. De-optimizes sub-processes in order to smooth the overall project plan.
2. Prevents the 100%-utilization fallacy from making your process brittle.
3. 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:

1. Optional features.
2. Additional scope.
3. Nice-to-haves.
4. 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.

Answer 2

But I want to reduce the number of weeks used in non critical paths.

I am reading this as you want the total duration of your non critical path network to decrease thus increasing slack on those paths. To do this, all you need to do is decrease the target duration of those packages that are off the critical path.

However, I am not sure what the value is in doing this. The initial assumption is that, within the probabilistic distribution of duration of each of your packages, you are targeting a duration that is somewhere around the MODE of that distribution, a target that represents a realistic possibility but also lean enough to not constitute over buffering. When you reduce that duration, you are increasing risk and, in order to mitigate, you end up increasing resource utilization and / work hours in order to meet the more aggressive target duration. Duration = Work / Resource Utilization.

This then threatens work activity on those packages on the critical path, which will directly threaten your overall duration.

Of course, on the other side of that, you are increasing your slack so you have some cycles in there to cope with unfavorable schedule variances. However, all this looks super on paper, but your reality will be very different.

Your other risk is, your critical path at planning is valid only at planning. At the moment you press go and begin work and begin progressing your packages in the schedule, your critical path(s) WILL change and change and change and change. Those packages that you arbitrarily reduced duration can and will likely fall in the new critical path(s) and, since you reduced the duration and increased your threat, you have now created a bigger threat to your overall schedule duration.

All in all, I cannot see the logic in what you are attempting to do from a scheduling / planning perspective. That does not mean there is no logic, I just cannot see it and I have never heard anyone discuss this before.