Why project management doesn't get it: Focus on patterns, not processes!

Why project management doesn’t get it: Focus on patterns, not processes!

I was directed to this academic, though very interesting paper titled “Lost Roots : How Project Management Settled on the Phased Approach (and compromised its ability to lead change in modern enterprises)” Sylvain Lenfle and Christoph Loch of INSEAD.  Here’s a full abstract of the paper:

The discipline of project management adheres to the dominant model of 
the project life cycle, or the phased stage-gate approach, of executing 
projects. This implies a clear definition of mission and system at the 
outset (to reduce uncertainty), and subsequent execution in phases with
 decision gates.

 This approach contrasts with the way the seminal 
projects were conducted that are credited with establishing the foundation of the 
discipline in the 1950s. These
 projects started with missions that were beyond the currently possible, 
thus any solutions had to emerge over time. They succeeded by a
 combination of parallel trials (from which the best would then be 
selected) and trial-and-error iteration (allowing for the modification 
of solutions pursued over a period of time).  

Although the success of these approaches was documented and explained by scientific 
work in the 1950s, today they seem to fly in the face of accepted 
professional standards, making managers uncomfortable when they
 encounter them.

The explanation for this contradiction has its roots in the 1960s, when 
the so-called McNamara revolution at the Department of Defense gave a 
control orientation to the PM discipline. This shift was cemented by the 
encoded practices of the DoD and NASA, contemporary scientific writing,
 and the foundation of the Project Management Institute as a professional
 organization that translated the standard into the educational norm for 
a generation of project managers. The project management discipline was 
thus relegated to a “grunt work niche” – the engineering execution of
 moderately novel projects with a clear mission.

As a result, it has been
 prevented from taking center stage in the crucial strategic change 
initiatives facing many organizations today.

 This article describes the historical events at the origin of PM’s
 reorientation, arguing that the discipline should be broadened in order
 to create greater value for organizations whose portfolios include push-the-envelope projects.

I split the abstract into several parts for readability and highlighted themes from the paper that are worth exploring in detail.  The first notable item is the idea implicit in project management practices that projects with “a clear definition of mission and system at the 
outset (to reduce uncertainty)” can be neatly defined with tasks, phases and gates that proceed in a linear fashion.  This is similar to an argument I put forth in my post about the dominance of linear thinking among project management practioners, industry experts and academics.

Much like the rise of science during the age or reason in the Western world, this same parallel event happened in the project management field.  What’s most ironic to me is the idea brought up in the paper about how the some of the most ground breaking scientific projects of the modern world such as the Manhattan Project, were successful because they allowed multiple, test prototypes to be experimented with to arrive at the best solution, which was facilitated by “trial and error” till the most optimal and effective solution was found and delivered.  Unless you’ve been living under a rock as a project manager, this is basically the ideology that drives all of modern Agile software development and project management.  Another of the most incredible feats of this project was the fact that it had at its disposal, the smartest people on the planet as its core team which really gives occasion for the idea of “herding cats” a new meaning!

But viewed from the perspective of the time this shift in focused occurred, it makes perfect sense.  If such a large and complex project could be delivered so successfully, then we need to lay out the systematic process in which such a project comes into being, so that it can be repeated.  Isn’t this one of the main reasons modern PMO’s are setup?  For any rationally minded manager, it makes logical sense to find the repeatable processes, document them, then educate and train others to follow the same steps for success… basically “rinse and repeat” or as the authors of the paper state, “‘grunt work niche’ – the engineering execution of
 moderately novel projects with a clear mission”.  I’ve owned a couple franchise businesses, and that whole industry is predicated on this model.

The main problem with this model is that it can lead to a mediocrity of results (McDonalds is known for consistency of its food, but not much know and often criticized for the mediocre qualify of its food).  I’ve written about this phenomenon with regard to the advent of the over centralized PMO that creates a mountain of processes and standards that creates an environment of stagnation and staleness, with the added burden of killing off innovation and the ability to deliver “push the envelope projects.”

One could say this adds legitimacy to the Agile movement and I wouldn’t argue with that.  But in my view this is not enough.  Agile with it’s lightweight process and methods is just a way of breaking down the big linear chunks of work into management chunks with the focus on end deliverables that work and putting the focus on the teams and collaboration that it takes to get there.  It refocuses the lost core principles of project management which is the project itself that can get lost when too much focus in on planning and documentation to get that repeatability.

So what’s the solution?

I didn’t find a satisfactory solution in the paper nor in any project management literature I could find out there, with the exception of a book titled “Organizational Patterns of Agile Software Development” by James O. Coplien and Neil B. Harrison, which describe using a pattern oriented language to describe how people and organizations actually work on software development projects.  The writers especially Coplien are heavily influenced by the design pattern movement which the object oriented community found were recurring patterns used in software development.  This movement was influenced by the highly original thinker Christopher Alexander who came upon the idea in the patterns discovered in architecture.  I think it is the right approach to look at patterns instead of process in projects as a guide to what could be mimicked for success.


My thinking is that this needs to be extended to start thinking in terms of “patterns of behavior” that lead to project success.  A more interdisciplinary approach using the fields of psychology, sociology, anthropology and even philosophy and literature could be integrated to provide a guild map for describing and illustrating, NOT prescribing the patterns of behavior that lead to project success. For it’s people that delivery projects and until that day comes when robots can start managing projects with other robots doing the work (unless a robot revolution happens!), then this is the focus that I believe best benefits all.

I have yet to work this out, but look for posts in the future that attempts to push this boundary!

0.00 avg. rating (0% score) - 0 votes