Has CPM had its day?
by Chris Vandersluis, Contributing Editor
MANY OF US REMEMBER what it was like: aerospace and defense were spending money on a scale never before seen in peacetime; construction and infrastructure projects were beyond comprehension in their scope and vision. It started in the ’50s and lasted until the end of the ’80s. It was the era of the megaproject. It started with a postwar world and saw us through the Cold War, the placing of a man on the moon, and the birth of the modern computer. It saw power projects that harnessed rivers and atoms, and for project management as a discipline it was a time of coming of age. Project management has been around for as long as there have been projects—the Pharaohs obviously used some kind of project management in creating the pyramids. But never before in the history of the world have so many great projects occurred simultaneously. History will record the birth of the “discipline of project management” in the middle of the last century—circa 1950.
The Birth of Critical Path Methodology.
Those of us who were able to work on some of those megaprojects can remember how they were organized. First of all, there were lots of activities, and I mean lots! Resources were basically unlimited, and those resources were expected to work across multiple years to accomplish their tasks. Time was the only constraint: the pressure to finish early, finish on time, not to be late drove everything. If you were in aerospace, it was the “Space Race.” If you were in defense, it was the “Arms Race.” If you were building infrastructure to accommodate the new world, it was about finishing fast enough to just keep up with demand.
It was into this world that critical path methodology (CPM) was born. It was miraculous. For the first time, we could look at a project and know just what tasks we had to focus on in order to avoid delaying the project. We learned about forward and backward passes and early versus late dates. There were variants and innovative displays. Gantt had his bar chart, and the U.S. Navy had PERT. It was all designed to focus on one thing: “Don't be late!”
Early Computerized CPM Systems. The application of computers to this calculation methodology was a natural; with all the calculations to do, it seems obvious. In fact, as computers have evolved, one of the first business applications to appear in each new iteration has been a project management system. Computers were tailor-made to handle the arduous, yet clearly defined, calculations, enabling project teams to adjust their forecasts as fast as events occurred.
Yet, these systems were created in the world of the time. They were called “project management systems,” and, indeed, they were in the project management category, but what we all knew we meant was that these were CPM scheduling systems.
Those first systems didn't look much like the graphical, easy-to-use systems of today. The earliest systems on mainframes and minicomputers were originally loaded with punch cards. Even when “online” systems became available, they looked more like an airline reservation system than today's point-and-click. The fundamental algorithm of those original scheduling systems is essentially unchanged over the years. Even as systems became available on PCs, they showed the bias of the times. Early project scheduling systems didn't do resource leveling—it was a later invention. In fact, with some systems, the resource calculator was sold separately, as an addon. Resource-limited scheduling? It was an afterthought. Remember that resources on a megaproject were considered essentially unlimited. There was no thought of scheduling down to the individual level. Resources were considered at best as disciplines or categories. Graphical reports were considered a luxury that not everyone wanted or needed. (Can anyone say “Primavision”?) These days we talk about resource calendars and split activities, but there was nothing like that in the thinking of the time. I remember that the first system I worked with had eight calendars—whatever would I do with all those calendars? Baseline changes were also something not originally conceived. No one much cared how the megaproject had originally been planned; all that counted was when it would be finished.
The PC-based software that got its start in the early ’80s is still very much part of today's market. And, while those products have advanced with the times, for those of us who remember the first versions, we can still see traces of their original design.
Yes, it was a different time; but that's when the software we see today had its start, and for the most part, the changes we've seen over the years in that software have been an evolving theme rather than a rethinking for the times.
Welcome to a New World. The world that project managers face today is a far cry from that of the ’50s through ’80s. It is a function of today's economy. Today's MTV generation lives in a world where 10-year-long projects are remarkable exceptions, where an individual is more likely to be working on multiple projects at one time—even multiple projects in a single day. It is a world ruled by time to market, shorter run times, design/build, rapid application development—and it is skewing everything we know about project management.
While the world was changing for project managers, the world of computers was changing too. We tend to think a lot about the impact of Windows on the current landscape and, of course, with any thought about Microsoft must come a thought about MS Project. But when you look at the core, the most significant changes in project management products have been interface-driven. After all, that was Windows' claim to fame. It made the PC interface so easy that a whole new category of user was able to adopt it and become proficient with much less training. Changes in project management software have been focused on specific areas; online tutorials, user friendliness, and flashy, sexy, fun-to-use software make for more sales. Yet, the basic concept of the vast majority of these products continues to be based around the old CPM model.
Microsoft tried to break out of the model a couple of years ago. A famous (infamous?) white paper was written by someone at Microsoft a few years ago describing-how MS Project version 3 “deemphasized” the CPM model. It may be true, but if you do a calculation of schedule in MS Project, guess what algorithm is used. At its heart, MS Project is still a CPM product.
Sure, there have been plenty of additions and enhancements in all of today's popular project management products; some of them are remarkable. Projects can now be huge, and many high-end tools do multiproject scheduling. Forget about eight calendars and a single baseline—“unlimited” is the latest limit described by almost all project management software vendors on such functions. There are hierarchical resources, integrated costing functions, risk analysis, and so on and so on. It's remarkable, but at heart most of these systems are still built around that original CPM algorithm.
No one much cared how the megaproject had originally been planned; all that counted was when it would be finished.
The CPM algorithm requires a few key elements to automatically calculate a schedule; for example, it requires a list of tasks. A duration or a method of calculating the duration must be given for each task. If there is a logical sequence to the tasks, it must also be defined. Given this information, a CPM calculation can tell you the earliest feasible date that each task can start (and finish) and the latest date that it can start (and finish) without delaying the project as a whole. Resources may be defined along the way, but basically the resource calculation is laid on top of the CPM dates and scheduled from there.
It sounds fine, but remember that the algorithm was designed in a period where the only driving criterion was “don't be late.”
Now, for Something Completely Different. Imagine a world where the driving criterion for successfully completing a project is the availability of highly skilled individuals, a world where even the technology upon which a project is based will change multiple times over the life of the project. (Sound familiar?)
I question whether the CPM algorithm is a useful method of analysis for many of today's projects. (Wait, if you're one of those critical chain advocates, please don't write to me explaining how different it is—I don't believe that's the answer either.)
In a world where skilled individual resources move from project to project over a period of hours, perhaps we need a whole new way of thinking about project management software—a completely new paradigm. Something starting not with a list of tasks perhaps, but with the capabilities of the resources and technology available to us. Perhaps the projects and tasks to which one commits and the schedule that becomes possible should be driven around available technology capacity and skills, rather than the other way around.
There were lots of software announcements at PMI ‘99. There is great focus at the moment on the Internet, the Web, and how marvelous it is to work across a worldwide network. The focus is all too much on the interface for my tastes. It makes for “sexy” press, and I'm sure I'll end up being a user or proponent of some of these systems. I don't doubt that there is merit in many of them, but it is a variant on a theme. Being able to look at the same old paradigm in a Web browser is not a shift in thinking, no matter how many new people will play with it because it is simpler to use.
There is room in the project management software market for some innovation, room for something completely different.
A FEW FIRMS, some new and some old, are touching on some new areas. Some of the solutions are innovative, but many are not ready for prime time. I'll be looking for developments from these firms throughout the year to see if they can get over the initial teething stages and get something into the market addressing the new world in which we work. One thing is for sure: When there is a need in the marketplace, someone will find a way to fill it. When I find some answers, I'll let you know. ■
Chris Vandersluis (email@example.com) is president and co-founder of HMS Software, based in Montreal, Canada. He is a member of PMI and the American Association of Cost Engineers, and is a founding member of PMI Canada. He has appeared in numerous publications, including For tune and Heavy Construction News, and is a regular columnist for Computing Canada magazine's project management column. Comments on this column should be directed to firstname.lastname@example.org.
PM Network January 2000
PMI research shows project teams that draw from an array of perspectives and skillsets deliver powerful outcomes.