You might suspect that Critical Path Methodology (CPM) has a particularly honored place among the cobwebs of my intellectual closet. CPM and I grew up together; I figure I have several thousand hours invested in intimate relations with CPM, either building, breaking, fixing, reviewing or managing the execution of various and sundry schedules. Through the years I have also become increasingly aware of its limitations and weaknesses. Thus, my initial close bond with CPM has grown more distant. I would not go so far as to characterize it as familiarity breeding contempt, but rather as B.B. King laments, the thrill is gone
Here's a bubblehead factoid for you: did you know CPM practices were born from sorting out the complexities of building the first nuclear submarines? It would be an understatement to say that there were some intricate design and coordination issues associated with cramming a hundred sailors into a five hundred-ton tube along with four thousand tons of hot, sharp, poisonous, radioactive, high frequency, high voltage, high pressure or highly explosive 'stuff.' But, Rickover's team somehow managed to figure it all out and using CPM was no small part of the solution.
For the last 50 years since then, CPM has come to be regarded as the overwhelming standard for project scheduling, particularly in cases where task sequencing is of paramount consideration. Many a ship, bridge, skyscraper and refinery owe their final status of 'on time and within budget' to a well-managed CPM schedule, keeping a meticulous eye on critical path activities and rigorous earned value analysis. And in situations such as those, CPM is as valid today as it ever has been. Little has come along since to displace the reign of CPM, with the possible exception of the small but persistent following of critical chain proponents, which just extends CPM principles.
But I am beginning to question whether CPM is still the best approach for managing so many of today's activities in knowledge-based, multi-tasking, resource-constrained environments. I have witnessed my own frustration and that of countless other project managers who attempt to build and manage CPM schedules 'the way it's always been done' for engineering, software development, process improvements, and similar increasingly fuzzy endeavors that can literally defy logic. Added to this is the time wasted trying to coerce CPM into unnatural acts when managing the portfolio of countless and largely unrelated operational activities that make up the majority of the organizational workload.
CPM has as its basis a set of straightforward mathematical calculations, a handful of business rules, and remarkably few constraint and relationship components. Anyone who has ever scratched out a manual forward pass/backward pass calculation on a certification exam knows pretty much all there is to know about CPM fundamentals. CPM has a certain je ne' sais quoi, a simple elegance to its technique.
Unfortunately, the very aspects that allow CPM to adroitly address the requirements of a fairly rigid, sequence-driven project scenario also become its Achilles Heel; its lack of elasticity becomes painfully apparent when attempting to reflect non-linear, shape-shifting work management environments.
It is like trying to model an amoeba with a set of Tinker Toys. Simple parts, fixed angles and predefined connectors are great for building a rigid symmetrical framework, but they lack the flexibility and options required to reflect the imaginative, dynamic and free-flowing approaches now being applied to address the ambiguity of so many of today's unique project challenges.
While you may be able to torture CPM enough to initially reflect an agile-based or otherwise structurally flexible plan, does that schedule really help or become more of a burden once the fur starts flying and calculations start manipulating things according to their rules rather than your reality? Alas, if all you have is a hammer
Part of this stems from the practice of trying to habitually enforce CPM logic where logic does not really exist. I cannot yet ascertain whether it is an inherent genetic flaw or learned behavior, but when it comes to scheduling, most of us project manager types display OCD symptoms that increase commensurate with the level of formal PM training we receive. These days, we must learn to let go and free our minds to focus on what is really important.
I am not suggesting that we toss CPM to the wayside by any means -- it still has its prominent place. But I do think there is something to be said for chilling out just a bit when it comes to how it is being applied.
For example, given a particular two-week long activity, is there really hard sequencing that exists between the eight or nine underlying tasks that must be done, or are relationships being inserted simply out of expedience, compulsive ritual or the intense need to paint an illusion of control? "Whaaat! Are you suggesting that tasks just be allowed to lay there, all unstructured and willy-nilly, smashed against the Time Now line like bugs on a windshield!?"
Sure -- why not? Better yet, why not just skip even putting them in the WBS? Often a simple to-do list with due dates will work just fine. Do you really think your team is just going to freeze up from lack of guidance because their tasks are not on the schedule? Do think they even look at your schedule?
When faced with a nebulous work management situation, sometimes it is better to deal with some intentional vagueness about the details rather than spending all your time building and rebuilding non-existent relationships or constraints for the sake of achieving "logic closure."
Hey, just think about it.