Getting from A to B on a straight line.   On that premise, project management sets out to map all the steps and linkages along a timeline.  But project management itself has become so involved there’s  a high priesthood of professionals certified by the PMI.

Consider that over 80% of the PMI curriculum is focused on the planning phase, with a mere one sentence referring to execution – and that, only as a dispatching function.  (Koskela  et al.: The Underlying Theory of Project Management is Obsolete, PMI 2002 ).   It is no surprise that last year saw a major overhaul within the PMI, self- confessedly to fix a growing irrelevance to day-to-day managers.

Absolutely,  the more complex the interdependencies and sequences in a situation, the more necessary it is to pre-plan.

However, as the project moves into implementation, PM’s very own complexity  collapses unto itself.  Why? Reality doesn’t follow our plans.  As the daily operations involve more and more external factors, delays, and uncertainty,  it becomes harder to maintain the convenient tidiness of the GANTT chart.  Ask a roomful of blackbelt six-sigmas how many  are able to keep the GANTT operational through the end of the project.

The GANTT  is invaluable as a planning reference point, but it isn’t going to be your daily management tool.

As decision-making moves upward in the organizational hierarchy, there’s increasing complexity.  Consider that a study of chief executives attributed failure to failed execution, and not to lack of plans or resources.   We’ll come back to this point shortly.

The primary tool for PM has always been Microsoft Project®, which has co-evolved with the PMI curriculum.  Essentially, all events and resources are planned along a timeline: that in itself is faultless.  But here lie the two main fallacies.  One, the software defines “issues” narrowly as scheduling-related .  Two: it does not have an inherent mechanism for feedback loops.

That the world, thanks to electronic media and global interconnectedness, is increasingly complex and fast-changing, is the executive’s new reality.  It is less and less about engineered certainty, and more about shorter, faster OODA loops .   A project management tool must have a built-in mechanism for enabling real-time updates and redirections;  Microsoft Project® does not.

Ironically, the MS Project® development team had to go outside of its own tool to track issues.

“ Expect the unexpected. In the course of its own work, Capossela’s team came upon the central truth of collaborative work: Most projects are derailed by unexpected problems that thwart what looked to be an on-time, on-budget operation.

As part of its own internal operations, the team often uses a homegrown database that it has dubbed Raid. Like the canned product of the same name, it is meant to help find and kill bugs — in the code — and keep them from multiplying.

When it came to working on its own project, the team appreciated the value of Raid. “Keeping our eye on those bugs — those issues — was just as important as getting something finished on time, if not more important,” says Todd Warren, who served as Project’s program manager before Capossela…” – Fara Warner, in Fast Company.

Microsoft has not been able to step back far enough to rethink its own Project® in a larger context.  Fortunately, there are other tools out there more suited to strategic implementation that also inherently allow tracking with updates and redirections.

The real problems tend to be the soft and fuzzy which are not apparent from the GANTT – and a lot of fuzzies are people-related issues.  But that’s real life, and cannot be ignored just because they do not tidily lend themselves to simple timelines of events.

Strategic planning and execution must be even more quickly adaptive as the situation spirals out to include more external factors.

Years ago, Bossidy and Charan reminded us to ask what really matters.  Your world needs a ruthless Pareto 80-20 trimming more than ever.  Your staff planners should develop comprehensive GANTT maps; but,  very quickly, for this fiscal year, what  five or seven deliverables will define your success?

In summary:

1. Project management ( as embodied by the PMI curriculum and its co-evolved tool MS Project®) painted itself into a corner of impracticality by overemphasizing planning  in itself.

2. The day-to-day management reality is that it’s a process within a complex, and ever faster changing context.

3. Managers need tools with information-and-correction  loops to track and drive what really matters.

Scheduling is not the issue, as MS Project® might want to define it:  rather, scheduling  issues are the end result of the fuzzies  - typically things outside your scope, resources, authority and tidy timelines.

The basic MS Project software does not have an inherent provision for posting updates, and thus makes it tough to redirect tasks. Referring to the main wikipedia entry for project management, time is only one dimension: the other two are scope and resources.

A more subtle but common flaw in the injudicious use of a tool like this, proceeds from a premise that the more comprehensive and highly detailed the initial plan, the better the plan. The more experienced project manager would quickly realize this can lead to enormously complex plans that are impractical to maintain throughout the actual project. There is value to such microanalysis such as in complex interdependencies. In most real life situations, the manager might do well to question the level of detail when perhaps it is best to keep to the deliverables and not micromanage the detailed tasks. Indeed, this is one reason project management has become a separate specialist staffing, away from line managers. Embracing chaos and more realistically managing the planning process’ scope and resource and, yes, scheduling, might be a lesson for project managers themselves.

Different management situations may call for looking at other tools as a complement to MS Project. Here are archetypical examples: “Basecamp” would be adequate for teams emphasizing collaborative delivery of creative materials. “ManagePro” is better suited for strategic alignment of lower level projects, as well as being adaptive to inevitable changes and setbacks in the execution. “MindManager” is, on the surface, a right-brained tool for diagramming relationships that are not necessarily drawn on a single line (i.e., chronologic as GANTT charts are), although the tool now has a project management module as well. Wiki pages are used by agile planners who prefer the widely open collaborative nature of the tool. The shopper would do best to step back and size up their application, and not narrowly bound the solution to one tool.

1. Candor on the need for continuing work to make PMI-BOK more relevant and actually used.
2. Five-point criteria : time, scope, cost, and risk and resources.
3. Coordinating the PMI documents in dictating and certifying pm practice.
4. Recognizing that the world is chaotic and nonlinear,
the sections on Change management have been integrated; and,
5. An exhortation that the Scheduler and tools be more “practical and judicious” in order to be flexibly responsive to dynamic situations.

OK; here’s three unsolved problem areas. The PMI-BOK

1. Needs to emphasize that Issues include “soft” and unquantifiable events.  Processes and tools must systematically capture and make visible non-scheduling issues as well.
2. Needs to move away from command-and-control, and emphasize collaboration and motivation. Execution is more than “dispatching”.  PM should be part of a manager’s skillset, not a staff specialization.  Lastly, the term “control” itself easily creates an illusion of certainty about the future.
3. Needs to dismantle a structural emphasis on scheduling. Certainly, time does eventually trump everything in the end. But the solution is not in creating complex schedules. As a writer reminds us, schedules are really “just a summary statement of our best-guess objectives”, given the inherently significant degree of inaccuracy about the future. Acknowledge the uncertainty; then (1) put in place the mechanisms to make changes visible, and (2) facilitate adjustments and feedback loops.

Mere theoretical abstractions? Unfortunately, no. How many people think to question parallel issues with Microsoft Project®, the de facto standard pm tool: (a) its very complexity has made pm into a priesthood isolated from day-to-day management; and (b) it has no inherent mechanism to handle non-scheduling issues (…those messy political and people trivialities).

(In the next blog: more on why schedule as a certainty is mathematically and logically flawed, if project management is to be practical and practicable.  Plus a mindmap parsing of the Koskela critique.)