Before scheduling software packages were available, engineers would painstakingly perform the forward pass and backward pass algorithms manually with the occasional help of a trusty slide rule to identify the critical path of their projects.
At the time, schedules were true to their original purpose: simple graph models that helped understand how changes would impact the delays and what tasks should be looked at more closely in order to reduce the global duration of projects.
Fast forward to the present, many scheduling software packages have grown into ALM tools and students for the PMP certification discover during their training that there is actually a graph underneath the Gantt charts they have used on a daily basis for several years.
The last nail in the coffin of the Pert graph is a consequence of the feature race that takes place between ALM tools. Since the selection of these tools is a box checking exercise, features are added on top of one another and time tracking is one of the first.
It’s an easy sell, it´s one of those ideas that looks great on the surface but whose flaws are safely buried in technical layers. Since all of the organisations’ projects are in the same database why not take this opportunity to track time and therefore costs?
So the package is bought, users are trained and trouble begins.
With their original purpose lost from sight and with the new mission to track time, schedules quickly morph into monster timetables: tasks not related to the production of one of the projects’ deliverables are added, dependencies are removed to ensure stability and easy timesheet entry. Until the Pert graph is no more, the critical path is lost and tasks have become budget lines.
Managing costs and delays with the same tool is a complex endeavour and for many organisations it is too complex. The costs side often wins because it has more visibility and it is easier to deal with and thus the ability to simulate the impact of scenarios on projects’ end dates is sacrificed.