Even Agilists find it hard to argue that the concept of a critical path is not valuable.
But for a critical path to be truly useful, in a practical sense, embracing two fundamental characteristics is required.
The first characteristic is that the calculated path’s accuracy is in direct proportion to the accuracy of the plan or model.
Critical path calculations depend on proper dependencies and realistic estimates. A lot (most) of the business process/technology development plans that I’ve seen over the last 30+ years consistently share these problematic traits:
- they are missing key tasks
- include arbitrary constraints
- do not include resources
- rely on inconsistent or mandated estimates
- do not have dependencies defined correctly, if at all
Putting undue emphasis on critical path items when the underlying plan is incomplete or poorly modeled, can quickly cause improper resource allocation, scheduling issues or worse.
The second fundamental characteristic is that the critical pat
h is not static.
Semantically, most of us associate a path with a course or route which is assumed to be fixed. And at the time the critical path is determined, this assumption is true.
But as the project progresses and the model changes, so does the critical path. An obvious change is that as time progresses, activities on the path get completed and the path gets shorter.
A non-obvious change is when the plan is refined with new, more current information or increased granularity and detail. One change in duration, a single revised dependency, or a key resource shift, can dramatically change the course and timing of the critical path, and the outcome of the initiative. If the new path is never recalculated and reviewed relative to the prior path, the same negative outcomes caused by focusing on the wrong things can occur.
Managing to the critical path can work well as long as its use is tempered by the understanding that: 1) the path is only as reliable as its underlying plan and 2), it is a constantly changing thing.
