The content of this article is a brief preview from Eric Uyttewaal’s new, upcoming book, Forecast Scheduling with Microsoft Project 2010, which will be published in the summer of 2010.

The first version of the Critical Path Method (CPM 1.0) is soon celebrating its 60th birthday. It was just about 60 years ago -- during the 1950s -- that DuPont constructed a model for projects that encompasses a list of a project's activities, the time each will take to be completed, and their dependencies. CPM, of course, is that path of activities from beginning to end that defines project duration -- the earliest it can begin and the latest it can end without becoming any longer.

I find CPM 1.0 still a beautiful thing. CPM helps project managers focus on a subset of activities that affect the project end date. However, some people say it takes too much time to identify and enter all the dependencies. Some say they hardly ever see a complete and reliable critical path in their schedule. Others say critical path stops working when you start to level the workloads. And who among us doesn't live in a resource-constrained situation nowadays?

Yes, these are all real issues. But your thinking shouldn't stop there. Each can be addressed with some simple techniques and new tools. In this article, you'll find out how to overcome most of these obstacles. I'm confident you'll gain a new perspective on CPM -- in fact, I'm so certain, I'm calling it "Critical Path 2.0."

This article examines the questions: Does CPM 1.0 still deserve a place in our project management body of knowledge? Can it stand up against the challenges and practices of our current times? Can its weaknesses be overcome? Along the way, I'll discuss our state-of-the-art scheduling software and whether it addresses CPM 1.0 deficiencies. Between the lines, we'll also explore whether CPM 1.0 can survive the next decade.

The Forgotten Assumptions of CPM 1.0

It sometimes surprises me when people make remarks like: "Well, the critical path method doesn't work in my resource-loaded schedule!" When I hear this, I often think: "It wasn't supposed to work in your situation!" Many people have forgotten that CPM 1.0 was based on some seemingly far-fetched assumptions. When CPM 1.0 was first formulated, the creators also gave us their assumptions:

Assumption 1: Task estimates are normally distributed; an estimate has an equal chance of being under or over when compared to actuals. (My comment: This assumption is often wrong because we all know that task durations tend to extend out much more often than they shrink.)

Assumption 2: There's no merge bias or path convergence; the fact that multiple paths need to come together doesn't affect the on-time probability of the overall project. (My comment: This assumption is often wrong because we all know that parallel paths do affect the likelihood of project delays.)

Assumption 3: You have unlimited resources available. (My comment: This assumption is often wrong because most of us now use experts and are managing a resource-constrained project.)

Assumptions 1 and 2 haven't been true right from the start; but only since about 2000 have they been adequately addressed. That's when we had sufficient computer power to really put Monte Carlo Simulation to the test, a technique that's actually been around since the 1930s. It took all those years in between before software would surface that would allow us to generate the random numbers and perform all the calculations in our project schedules to get a more realistic sense of task estimate and multiple path accuracy.

Regarding assumption 3, many construction projects are still scheduled under the assumption that they have access to unlimited resources. Construction companies rarely allow their project to extend if they can remedy the situation by putting more resources on site, particularly if there are contractual penalties for delivering late. Penalty clauses are common in construction, and general contractors will hire 10 more carpenters for next week if they need to. However, using unlimited resources is becoming less of an option, even for construction companies. In practice, I see more construction schedules being loaded with resources. So, assumption 3 becomes untenable even for construction.

Another point: IT projects have always relied on expert resources. I define these as resources that aren't always available when you need them. Therefore, projects that use experts are almost always resource-constrained. In most IT-projects, the assumption of unlimited resources has decreased the value of CPM 1.0 to the point of being useless. Many other types of projects also use experts: pharmaceutical, defense, telecommunications... and whenever you need experts, you can't simply assume any longer that you can always add resources to solve your time problems.

Critical Chain vs. CPM 1.0

CPM 1.0 lost a lot of influence with the arrival of Critical Chain project management thinking in the late 1990s, which formed the focus of a book, titled Critical Chain, by Eliyahu Goldratt. Goldratt made some very astute observations about the weaknesses of CPM and proposed to replace it with an entirely new system of scheduling, Critical Chain:

• Switching from 90 percent to 50 percent confidence level estimates or aggressive estimates.
• Adding a project buffer to the most critical path and measuring project health in terms of buffer consumption. Critical chain is essentially buffer management.
• Scheduling the secondary paths as late as possible and inserting buffers where the secondary paths connect to the main critical path.
• No multi-tasking of resources. Each resource works with 100 percent focus on a task until it's finished or until roadblocks appear in the way, and only then does the resource move onto the next task.
• Making sure that the schedule stays within the constraint of availability of resources. Critical Chain respects the limited resource availability and finds the resource-critical path in a schedule rather than the critical path.

Critical Chain seems to be firmly entrenched in certain niches such as new product development in high-tech. Likewise, many a project manager has adopted some aspect of critical chain -- single-tasking resources is popular. However, from my perspective critical chain hasn't overthrown CPM 1.0; the majority of project managers exhibit a continued interest in CPM 1.0.

Agile vs. CPM 1.0

More recently, the Agile movement has mounted an attack on CPM. Like advocates of Critical Chain, these devotees would also like to kill CPM and dispose of its body of knowledge. Agile works well, particularly in software development and research projects. However, I believe that CPM will survive Agile attacks as well because project management doesn't start and stop in IT.

Sometimes, I even like to ponder that CPM will perhaps enjoy a revival in software and in research projects if we manage to address some of the issues that Agile thinking has brought to us, for example, the proper chunking of large projects to promote the creation of prototypes and builds early, resulting in the early creation of benefits (quick wins). There's no reason this practice couldn't be implemented with CPM 1.0, and therefore I don't believe it'll make CPM go away.

Critical Path Method 2.0

The survival of CPM will depend on two things. First, the critical path method needs a makeover -- CPM 2.0 -- to address the assumptions and issues of CPM 1.0 as well as integrate several facets of Critical Chain and Agile thinking. Second, those who develop scheduling software need to add new features into their applications to address the assumptions and issues of CPM 1.0 by giving us tools with which we can perform most or all aspects of CPM 2.0 in an automated fashion.

The limitations of CPM 1.0 that we need to address in CPM 2.0 are:

• Incomprehensible critical paths: Why is the critical path what it is?
• Incomplete critical paths: Why does the critical path in a schedule often only explain part of the project duration?
• Hidden critical paths: Are you looking at the right path?
• Resource critical paths: Do you have unlimited resources -- anybody?
• Program critical paths: Can you trace your critical path across multiple subprojects?
• Protecting the critical paths: Can you protect the main critical path from impacts of other secondary paths?

If we can make our scheduling tools address most or all of these issues, we'll have arrived at version 2.0 of CPM. CPM 2.0 scheduling applications should have features that resolve all six challenges we have with our current scheduling software. Amazingly, I think all but one of these limitations have already been addressed. Let's drill down a bit.

Incomprehensible Critical Paths: Maybe you're looking at your schedule and asking, why is the duration of this critical task so long? Critical tasks may be longer than their duration suggests because your resource is going on a vacation while working on it. The scheduling tools need to make readily visible when a resource vacation stretches a task bar. Another issue surfaces when there's a gap between two critical tasks. The cause for this can be a lag on a dependency, a task calendar, or resource calendar. Again, the scheduling tool should explain this in the Gantt chart. My company, ProjectPro, sells a Microsoft Project add-in, Complete Critical Paths, that can do this.

Incomplete Critical Paths: What breaks a critical path? How can you repair it? What do you need to do in your current scheduling software to display a complete critical path that explains the entire project duration? There are only six factors that can break a critical path, and since this list is finite, our scheduling tools should be able to handle this and explain any gaps. There's a technique of increasing the threshold for criticality from zero days to x days with which you can make a critical path complete. Again, my company's product, Complete Critical Paths, will present the complete critical path automatically.

Hidden Critical Paths: Our scheduling software may not tell us the real critical path, particularly when there are many parallel paths that have similar durations. The problem is not that our software is lying to us; the issue is that only Monte Carlo simulation can reveal the path that is the most critical to monitor when there are parallel paths. In my view simulation is essential for every schedule, and every scheduler needs to do this. There are two solid add-ins for Microsoft Project with which we can find the hidden critical paths in our schedule: Risk+ from Deltek and @Risk from Palisade.

Resource Critical Paths: How does workload leveling impact the critical path? Microsoft Project still doesn't have resource-critical path features yet -- a major omission in my view. However, two add-ons for Microsoft Project can come to our rescue by implementing critical chain capabilities: ProChain Project Scheduling from ProChain Solutions and cc-Pulse from Spherical Angle. If you don't want to implement the other aspects of Critical Chain, you can use our company's add-on, Complete Critical Paths.

Program Critical Paths: Several tracing tools that are available as add-ons to Microsoft Project can display the critical path leading up to a milestone. They do a good job as long as you stay within one schedule. They typically stop when the critical path goes across to another schedule via cross-project links. We need tracing tools that can go across subproject schedules via the handoffs between the subprojects. Currently, we're aware of only one such add-in, which we publish: Program Management Solution.

Protecting the Critical Path: How can you schedule backwards from milestone events on the main critical path to schedule the activities of secondary importance? How can you schedule secondary paths as late as possible and still protect the main critical path by using a buffer? How can you further enhance the critical path method by adding features like backward scheduling from critical path events and create dynamic due dates -- due dates that move when the main critical path moves?

For this particular set of challenges, there's more needed than just tools. It requires the creation of a new class of dependencies, the "earlier-than" dependencies. Currently, we only have later-than dependencies in our scheduling tools. For example, a Finish-to-Start (FS) relationship means the successor can start later than the finish date of the predecessor. Start-to-Start (SS), Finish-to-Finish (FF), and Start-to-Finish (SF) all work in a later-than fashion as well. If we add an entirely new class of earlier-than dependencies, we can create dynamic due dates and dynamic windows of opportunity in our schedules, and we can do backward scheduling properly. On the other hand, we'd also have to re-think the critical path algorithm and reprogram it in our scheduling tools. This will take longer to agree upon and to resolve.

Can CPM Survive?

CPM 1.0 was based on major assumptions that also reveal its shortcomings. CPM 2.0 addresses six limitations of the critical path method as we currently understand it. A review of currently available scheduling software, solutions, and add-ins suggests that we have solved five of these problems already. Now, if those solutions were simply bundled into our primary scheduling applications that we use for managing our projects, we'd be able to realize the vision of CPM 2.0.

So, can CPM survive for another decade? With the makeover I propose, I believe so. Nothing else comes close to addressing the scheduling challenges of today's projects.

Attend two MPUG WebNLearns with the author in April!

Apr 13: WebnLearn: Critical Path 2.0 with Eric Uyttewaal (Part 1)
Apr 14: WebnLearn: Critical Path 2.0 with Eric Uyttewaal (Part 2)

Eric Uyttewaal is one of the foremost authors, trainers, and consultants on the use of project management tools from Microsoft. He wrote the best-selling book, Dynamic Scheduling with Microsoft Office Project 2003, and is working currently on a new book, Forecast Scheduling with Microsoft Project 2010. Eric is founder and president of ProjectPro, a company specializing in Microsoft Project and Project Server. He's the president of the MPUG-Ottawa chapter. Contact Eric at ericu@ProjectProCorp.com or visit his website at http://www.projectprocorp.com.