A fellow colleague of mine made me aware of this website. This concept and presentation made me think back to some of the schedules I’ve created in the past. Now I do not claim to be an expert on resource loaded network (RLN) development, but I can recall that I have seen on numerous occasions more than on critical path in my network. This meaning there were paths identified by the scheduling software tool as red and therefore critical, but not the longest path. Sometimes the path would start from the beginning and stop half way. Another path would start in the middle and the go to the end. So I would spend a great deal of time trying to identify the true critical path only to do it again the next reporting period.
I am interested in hearing some academic/professional feedback on this topic.
See the following from The International Center for Scheduling, Inc. website.
“Is Critical Path Obsolete?”
Is “Critical Path” Obsolete?
As only the 2nd of six speakers chosen from around the globe, ICS founder Murray Woolf posed a thought-provoking question: has “Critical Path” become obsolete? In so many words, he contends that it has — and he even calls for retirement of the term, critical-path. His paper was delivered, via Internet, to a worldwide audience on July 30, 2008.
Paper Abstract
Perhaps it is time for “Critical Path” to take a graceful bow … and exit with dignity. Perhaps its day has come! To be sure, “critical path” – the words, the concept, and even the overarching project management approach to which it i’s central – may have outlived its relevance.
Click here for the entire paper abstract
http://www.ics-global.com/IG-CPObsolete.html
{ 3 comments… read them below or add one }
I suggest that critical path is not obsolete. It is not quite extinct, but certainly should be on the endangered list. The first check I perform on any schedule is to sort by total float primarily, early finish secondarily, and finally by early start. If the most critical path is not immediately and unambiguously presented, 99% of the time the schedule is broken, flawed, defective, whatever you want to call it. I never color code activities by float values to determine criticality. I simply isolate the most critical path. If it is not immediately evident, I determine why. I have filled multiple pages of legal pads recording bad practices that interfered with identifying the critical path. Most schedules I have reviewed do not come close to passing the test. Yet I have quickly and successfully elucidated the critical path using this simple sort on projects having tens of thousands of remaining activities in within hundreds of interlinked project files. This technique works with every critical path software package that I have used for the past fifteen or so years. The ultimate solution always resides in better planning.
If I may add one more comment, successful program management is not a matter of rolling the dice; it is a matter of loading the dice. Probabilistic critical path is a good check for how well one is managing the odds.
Hi, Schedulosophy!
You said: “I have filled multiple pages of legal pads recording bad practices that interfered with identifying the critical path.”
I would be curious to see a summary of those. To make a long story short, I had a “nice” critical path in MSP2003, then shortened one critical activity by a week, the project end date didn’t move, several activities became non-critical, and now the critical path starts mid-project (!). Even after filtering for all tasks then back to critical again. Then shut down Project and started it up again.
The project is not huge, e.g. 100+ activities. I have tried removing things such as SS and FS-1w dependencies, etc., All tasks are fixed duration, not effort driven.
{ 3 trackbacks }