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
No related posts.
{ 31 comments… read them below or add one }
For those trying to view the video, click Play and then double click the video for full screen view.
For those trying to view the video, click Play and then double click the video for full screen view.
Hi Travis,
As a practitioner and as an academic, I think what Mr. Woolf demonstrates is that a little bit of knowledge can be a dangerous thing.
When I learned scheduling, I was taught exactly what he said- that there were only one activity with no predecessor, a start milestone and one with no successor- finish milestone. To this day, I stick by this convention to as great an extent as possible. IF there must be interim milestones, the assumption is that the project manager/project controls specialists can apply some common sense in their interpretation of the critical path, including an assessment of the “near critical” activities.
The definition I use for critical path is any activity that, if delayed, delays the completion of the project OR any interim milestone.
Using this definition (which has been around as long as I can remember) addresses many of the supposed weaknesses he speaks of.
Bottom line- His presentation is very interesting, and while academically correct, appears to me to lack any ability to apply common sense to the process.
BR,
Dr. PDG, Jakarta
http://www.build-project-management-competency.com
Dr. PDG,
I primarily use Primavera P6 and the tool has settings for critical path determination. Pick here for longest path or click here for float value.
After watching this, how would or could the tools support these academic concepts? What would this do during a Monte Carlo, if even applicable?
Could you play devils advocate here and highlight pro and cons of this kind of thinking?
Thanks
Hi Travis,
As a practitioner and as an academic, I think what Mr. Woolf demonstrates is that a little bit of knowledge can be a dangerous thing.
When I learned scheduling, I was taught exactly what he said- that there were only one activity with no predecessor, a start milestone and one with no successor- finish milestone. To this day, I stick by this convention to as great an extent as possible. IF there must be interim milestones, the assumption is that the project manager/project controls specialists can apply some common sense in their interpretation of the critical path, including an assessment of the “near critical” activities.
The definition I use for critical path is any activity that, if delayed, delays the completion of the project OR any interim milestone.
Using this definition (which has been around as long as I can remember) addresses many of the supposed weaknesses he speaks of.
Bottom line- His presentation is very interesting, and while academically correct, appears to me to lack any ability to apply common sense to the process.
BR,
Dr. PDG, Jakarta
http://www.build-project-management-competency.com
Dr. PDG,
I primarily use Primavera P6 and the tool has settings for critical path determination. Pick here for longest path or click here for float value.
After watching this, how would or could the tools support these academic concepts? What would this do during a Monte Carlo, if even applicable?
Could you play devils advocate here and highlight pro and cons of this kind of thinking?
Thanks
Travis,
First a few comments. The presentation will elicit a longer post on Herding Cats.
First, having a schedule with widows and orphans is simple “bad” practice in some domains. It is cause for a Corrective Action Request (CAR) in other domains. In every case it represents naive and immature scheduling. So have tasks with no predecessors or successors negates any further discussion of a Critical Path.
Look at DID 81650 and the DCMA 14 Point assessment for guidance here.
I’m troubled by your description of how the path is shown in the scheduling tool. In MSFT “turning red” can only occur if you fix the finish with a MFO or similar constraint. Such a constraint would be prohibited in an credible scheduling process.
Hey Glen,
Thanks so much for leaving a comment. I was hoping you would see this and leave some clarification points. You are correct, we originally had applied constraints on some external milestones. I was trying to have my milestones represent algorithm drops. Once we optimized the schedule the critical path to showed up and it was a beautiful thing.
I will research the DID you suggested.
Travis,
The best way we’ve found to “fix” a deliverable in MSFT Project, is to set a deadline. This way all the tasks (or activities representing work packages) can be ASAP, but the negative slack will be visible as well.
This way the Monte Carlo approach can be used, you’ll have a DID 81650 compliant schedule, and your schedule will be considered “dynamic” since there are no constraints in the sense that something can’t move if the work to the left moves to the right.
Travis,
First a few comments. The presentation will elicit a longer post on Herding Cats.
First, having a schedule with widows and orphans is simple “bad” practice in some domains. It is cause for a Corrective Action Request (CAR) in other domains. In every case it represents naive and immature scheduling. So have tasks with no predecessors or successors negates any further discussion of a Critical Path.
Look at DID 81650 and the DCMA 14 Point assessment for guidance here.
I’m troubled by your description of how the path is shown in the scheduling tool. In MSFT “turning red” can only occur if you fix the finish with a MFO or similar constraint. Such a constraint would be prohibited in an credible scheduling process.
Hey Glen,
Thanks so much for leaving a comment. I was hoping you would see this and leave some clarification points. You are correct, we originally had applied constraints on some external milestones. I was trying to have my milestones represent algorithm drops. Once we optimized the schedule the critical path to showed up and it was a beautiful thing.
I will research the DID you suggested.
Travis,
The best way we’ve found to “fix” a deliverable in MSFT Project, is to set a deadline. This way all the tasks (or activities representing work packages) can be ASAP, but the negative slack will be visible as well.
This way the Monte Carlo approach can be used, you’ll have a DID 81650 compliant schedule, and your schedule will be considered “dynamic” since there are no constraints in the sense that something can’t move if the work to the left moves to the right.
So now some concepts of CP and its critical importance to project success.
IN any non-trivial project schedule – one where more than a few pages are needed to print the schedule – the CP shows what activities must be directly managed to avoid falling behind schedule. In order to have a “credible” – and I’ll keep emphasizing this term “credible” – schedule, the CP identifies the “zero slack” path through the schedule – no widows, no orphans, no constraints. Only a MSO and ASAP (see the DCMA 14 point assessment).
So Travis, I’d conjecture you have a problem finding the CP because you don’t have a credible schedule to begin with.
So now some concepts of CP and its critical importance to project success.
IN any non-trivial project schedule – one where more than a few pages are needed to print the schedule – the CP shows what activities must be directly managed to avoid falling behind schedule. In order to have a “credible” – and I’ll keep emphasizing this term “credible” – schedule, the CP identifies the “zero slack” path through the schedule – no widows, no orphans, no constraints. Only a MSO and ASAP (see the DCMA 14 point assessment).
So Travis, I’d conjecture you have a problem finding the CP because you don’t have a credible schedule to begin with.
Glen,
I agree and my mentor said the same thing regarding the use of constraints. He is a long time RLN expert. He said there MUST be a critical path. This was a 1200 line software development schedule. It was my very first experience with developing a RLN.
I was reading your comments on Hearding Cats about IMP/IMS. http://herdingcats.typepad.com/my_weblog/2008/06/impims-and-deliverables-based-planning.html
For the other readers go to the IMP/IMS Preparation and Use Guide link http://www.acq.osd.mil/sse/docs/IMP_IMS_Guide_v9.pdf
Read the last paragraph at the bottom of page 50. This supports what Glen is saying about my first schedule.
Hey Glen, can you perhaps provide a post or at least some links to some good examples of schedules with identifiable critical paths. More specifically, a MSP 2003 mpp file that some of us can to move around in for learning.
Thanks
Travis,
Yes. I’ll poke around and detox what I consider a “good” IMS. I’m teaching the 500 course at EVM world on Technical Performance Measures and their integration with the “Credible” IMS, so this will be the motivation for building examples.
Glen,
That is really good news. I told Josh that he and I should collaborate on providing some tools based examples of these concepts we all share on this site. I think the new grasshopper PMs could get some value.
You know, tools alone won’t deliver a successful project. However, with the right skill set, knowledge, and tools the chances greatly improve.
Thanks
Travis,
Another thought is to build a briefing around a credible schedule. There are several “building a credible PMB,” parked at the PMI-CPM site. But they’re not low enough down to see how the IMS is actually constructed from the IMP and how the Work Packages are assembled and ready for baselining.
This be my motivation to pull this together. We’ve got a EV Validation coming up and some people need a walk through of the steps.
Glen,
I agree and my mentor said the same thing regarding the use of constraints. He is a long time RLN expert. He said there MUST be a critical path. This was a 1200 line software development schedule. It was my very first experience with developing a RLN.
I was reading your comments on Hearding Cats about IMP/IMS. http://herdingcats.typepad.com/my_weblog/2008/06/impims-and-deliverables-based-planning.html
For the other readers go to the IMP/IMS Preparation and Use Guide link http://www.acq.osd.mil/sse/docs/IMP_IMS_Guide_v9.pdf
Read the last paragraph at the bottom of page 50. This supports what Glen is saying about my first schedule.
Hey Glen, can you perhaps provide a post or at least some links to some good examples of schedules with identifiable critical paths. More specifically, a MSP 2003 mpp file that some of us can to move around in for learning.
Thanks
Travis,
Yes. I’ll poke around and detox what I consider a “good” IMS. I’m teaching the 500 course at EVM world on Technical Performance Measures and their integration with the “Credible” IMS, so this will be the motivation for building examples.
Glen,
That is really good news. I told Josh that he and I should collaborate on providing some tools based examples of these concepts we all share on this site. I think the new grasshopper PMs could get some value.
You know, tools alone won’t deliver a successful project. However, with the right skill set, knowledge, and tools the chances greatly improve.
Thanks
Travis,
Another thought is to build a briefing around a credible schedule. There are several “building a credible PMB,” parked at the PMI-CPM site. But they’re not low enough down to see how the IMS is actually constructed from the IMP and how the Work Packages are assembled and ready for baselining.
This be my motivation to pull this together. We’ve got a EV Validation coming up and some people need a walk through of the steps.
If you don’t have a resource loaded network, you don’t have a schedule. Even the Agilistas understand that.
If you haven’t identified the critical path, that doesn’t mean it isn’t there. It just means that you don’t know where it is, and thus you don’t know which activities are most likely to cause your project to be delayed.
This is EXACTLY the same issue as reserves … EVERY project has a reserve. If you haven’t identified it, then it is either zero or hidden.
Bill,
That is interesting that you give the Agilistas credit for appreciating critical path.
Do you have some good examples or best practices of utilizing CPM and Agile? What would the schedule look like? More importantly how would you capture performance in the RLN for EVM. It is my understanding that agile schedules are fixed sprints and scope fluxuates.
If you don’t have a resource loaded network, you don’t have a schedule. Even the Agilistas understand that.
If you haven’t identified the critical path, that doesn’t mean it isn’t there. It just means that you don’t know where it is, and thus you don’t know which activities are most likely to cause your project to be delayed.
This is EXACTLY the same issue as reserves … EVERY project has a reserve. If you haven’t identified it, then it is either zero or hidden.
Bill,
That is interesting that you give the Agilistas credit for appreciating critical path.
Do you have some good examples or best practices of utilizing CPM and Agile? What would the schedule look like? More importantly how would you capture performance in the RLN for EVM. It is my understanding that agile schedules are fixed sprints and scope fluxuates.
For those looking to make the CP visible,
Insert the TOTAL SLACK field, set the CRITICAL bar style to RED. Go to the Gantt wizard and check the show critical path and it’s there.
But that’s only for today’s un-statused schedule. Update the schedule and the path changes of course.
This is why the Monte Carlo Simulator is mandated for our programs. It the probabilistic CP that’ll get you. Not the one right before your eyes – after turning on the Bar Styles correctly.
But the CP is one of many “health checks.”
http://pmchallenge.gsfc.nasa.gov/Docs/2006attendee-presentations/2006presentationsCD-attendee/Ken.Poole.pdf
Is a start. http://www.pmmetrics.com/ and http://www.steelray.com are some tools that’ll provide deeper insight. You can build your own in VBA, but these are used on our programs to save time and grief.
For those looking to make the CP visible,
Insert the TOTAL SLACK field, set the CRITICAL bar style to RED. Go to the Gantt wizard and check the show critical path and it’s there.
But that’s only for today’s un-statused schedule. Update the schedule and the path changes of course.
This is why the Monte Carlo Simulator is mandated for our programs. It the probabilistic CP that’ll get you. Not the one right before your eyes – after turning on the Bar Styles correctly.
But the CP is one of many “health checks.”
http://pmchallenge.gsfc.nasa.gov/Docs/2006attendee-presentations/2006presentationsCD-attendee/Ken.Poole.pdf
Is a start. http://www.pmmetrics.com/ and http://www.steelray.com are some tools that’ll provide deeper insight. You can build your own in VBA, but these are used on our programs to save time and grief.
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 }