Notes on The Underlying Theory of Project Management Is Obsolete

Compiled from Reforming Project Management
By Hal Macomber


Koskela and Howell Argue for a Reform

Lauri Koskela and Greg Howell presented their original paper The Underlying Theory of Project Management is Obsolete at PMI's bi-annual Research Conference July 2002. A number of people have asked me to comment on it. I'm struck by how persuasive Lauri and Greg are. It takes them just 12 pages to evaluate the anomalies and argue for a reform to project management. My comments will attend to Lauri's and Greg's paper. Download your copy. Read ahead. And please join me in discussion with your comments and questions.


Why the Interest in Project Management Theory?

I'll start my comments on Koskela's and Howell's (K&H) paper by addressing the interest in theory. Many of you may want something of more practical value, although the engineers in the group may be quite comfortable with a discussion of theory. Why should we all be interested? Our interest is more than academic; it is quite practical. Let's start by considering that K&H might be right.

We have been distracted by colleges and the PMI.

If the theory in use is obsolete, then it would explain why we don't get the results we're after. Like 15th century navigators believing the world was flat or earlier astronomers who thought the sun revolved around the earth, there are anomalies of project performance that can't be explained. It is with the intent of explaining past behavior and predicting future behavior that we are interested in theory. Readers of Reforming Project Management will note I often recommend adopting one behavior or another. I also criticize familiar behaviors as not effective. K&H's discussion of theory will allow you to participate in selecting practices for your project. Their paper also provides a jumping off point for developing a more encompassing theory.

We have been distracted by colleges and the PMI. We've been told if you want successful projects, then do those things recommended by the ANSI standard for project management. What is that standard? It is the PMI Body of Knowledge®, ANSI/PMI 99-001-2000. (Did you notice the designation of the registered trademark? Trying to refrain from cynical comments let me say might there be commercial interests involved?) We've been told to do more of what we've been doing. To get more people certified by PMI, to do a more comprehensive job of creating project schedules, and to always keep our CPM schedules up-to-date. It seems to me doing more of the same only benefits the status quo: the providers of software, training, and consulting. Yet we all know of projects where they are doing everything PMI recommends, and the project is still late, over budget, missing key functions, or all three. It is this anomaly that so interests K&H. Let's all have a practical interest in theory so we can do a better job of selecting practices, so we have a basis for creating new practices, and so we can get the results we're after on our projects.


IPO Theory is Incomplete

K&H claim the theory-in-use of project management is based on a production theory and a management theory. The production theory is transformation: input-process-output (IPO). The management theory is closed-loop: planning-executing-controlling, with the emphasis on planning (management-as-planning, the dispatching model, and the thermostat model of control).

Our practices for creating the WBS get in the way of combining theories.

The transformation model is so pervasive in our experience and thinking that we don't see the world a different way. The approach is reductionist — break the project down into milestones, phases, activities, and tasks. The project management mechanism for defining and organizing plan items is the work breakdown structure (WBS). K&H argue that IPO theory misses two complementary theories: flow and value generation. Both theories have been around for quite some time, 1920s and 1930s, respectively. But in our machine-dominant world the IPO model pervades, missing the attention these other theories give to time and to what is of value for customers.

So where do we go from here? Some people contend that we can just put the three production theories together in our practice. In my experience, our practices for creating the WBS get in the way of combining theories. Other approaches must be pursued. Some of the more promising approaches are business process mapping (workflow), story-boarding, and the scrum development approach of iterating. In the meantime, perhaps there's a litmus test for defining or accepting plan items. Ask, "Would my customer be willing to pay for (see value in) what I plan to do?" If not, then adjust the plan.


Management-as-Determining?

The PMBoK® describes 10 planning processes out of a total of 13 core processes for project management. These 10 processes comprise what K&H call management-as-planning in their paper. It's no surprise there are 10 planning processes. We go to great extremes on projects to plan. The value of planning seems to arise out of the concern for minimizing risk. More time on planning is supposed to lead to fewer unforeseen conditions. The usual practice is for smart and experienced people to spend time up-front thinking through one possibility after another finally landing on an approach that makes sense (to them).

It is crazy to give the greatest effort to detail when we know the least about the project…at the beginning.

The plan is put to paper (or in scheduling software) then is 'sold' to project participants and the customer as the (one right) way to go. Often, planning then stops. Execution begins. This distinct break — planning as separate from execution — is seen by K&H as consistent with the general field of operations. Planning is the process of deciding what to do. Those in execution get their direction from the plan in a usual dispatching process…following the "simple process of issuing orders". Management-as-planning in conjunction with planning-as-determining, becomes management-as-determining in the everyday practices of projects.

We can understand from history that computer time for scheduling programs was expensive. Doing a good job once, or maybe twice, was all the project could afford. Further, some project activities are deemed expensive to change mid-way through the project, like changing the layout of a building or adding functions to software. So in an effort to minimize rework project teams fix the requirements and the schedule.

But the future is uncertain. Plans can't possibly determine results. At best, planning prepares for the always-uncertain future. Our Herculean efforts to get the project plan in place at six levels of detail early in the life of a project is not just a waste of time, it uses key people who could be used throughout the project to better end. It is crazy to give the greatest effort to detail when we know the least about the project…at the beginning. Better (much better) is to add detail no sooner than it is needed (acting at the last responsible moment) taking advantage of what is revealed and learned. AND do this with people who are close to the project…people who actually perform the tasks.


Set It and Forget It? Hardly!

K&H describe thermostatic control as the principal espoused (or inferred) theory of control on projects. Examples:

  • Cool above 72° and heat below 68°.
  • Returning from the South Pole navigating between sets of markers.

Perhaps the machine metaphor has served its useful life.

Thermostatic control is based on some decision or choice of what is right, or best, and then invokes corrective action when conditions vary from that stated norm. What's wrong with this theory? You just can't set it and forget it. Unlike temperature or path, there is no one correct path on the project. The path to completion shifts throughout the project. Sure, we have a good idea of what must be done to finish, but the sequence can change and some of the tasks will fall off while other required actions will be discovered. Thermostatic control at best locks us into a naïve plan…uninformed by the world that has unfolded.

The good news is we find the theory-in-use doesn't conform to the espoused theory. In response to out-of-date plans and execution that fails to consider the readiness of performers, controlling activities function as negotiation between the directors and the performers. Referring to this breakdown of control, people disparage the team by saying they are out of control rather than acknowledging they are likely better off than operating to an obsolete plan.

Where is this headed? The 6σ (Six Sigma) advocates might suggest we must identify the variables and bring them under control (as if we can). But perhaps the machine metaphor has served its useful life; project control is more like navigating a boat. The crew with their hands on the wheel and the lines rely on visceral signals — a fluttering in the sheet, tension in the line, a slight list to starboard — to make their adjustments. Execution and control combine as performers rely on their intuition and experience. The destination is reached even though the boat may never be on course.


Behind the Facade of Project Management

Koskela and Howell do a marvelous job of capturing the experience of projects on page 11:

"The deficiencies of the theory of the project and of the theory of management reinforce each other and their detrimental effects propagate through the life cycle of a project. Typically, customer requirements are poorly investigated at the outset, and the process of requirement clarification and change leads disruption in the progress of the project. The actual progress starts to drift from the plan, the updating of which is too cumbersome to be done regularly. Without an up-to-date plan, the work authorization system transforms to an approach of informal management. Increasingly, tasks are commenced without all inputs and prerequisites at hand, leading to low efficiency or task interruption and increased variability downstream. Correspondingly, controlling by means of a performance baseline that is not based on the actual status becomes ineffective or simply counterproductive. All in all, systematic project management is transformed to a facade, behind which the job actually gets done, even if with reduced efficiency and lessened value to the customer."

The first step in reform is talking about theory. What is a project?

Most projects do eventually complete. We can thank project participants for their "in spite of it all" approach. We see project participants acting contrary to the stated practices and standards of the organization and in so doing they deal with the problems of the project. K&H show us the problems are not:

  • incompetent management (and we could use more competence)
  • low productivity from unmotivated workers (and interest in improving would help)
  • customers who can't or won't make up their minds (and knowledgeable customers are easier to work with)
  • poor practices of project scheduling (and it's not a computer issue)
  • poor practices maintaining schedules (and we could use more staying in touch with what is happening)
  • risk management (does anyone know what I'm even talking about?)
  • scope creep (and we certainly can help our customers better understand what they could be asking for)
  • add your favorite reason here (or two or three)

The problem with projects is the insufficiency or obsolescence of the underlying theory. There is plenty of work for us all to do to reform project theory and practice. The first step in reform is talking about theory. What better place to start than at the beginning…what is a project? Let's bring down the facade and the misery and waste that go along with it. Thank you Lauri and thank you Greg for getting us talking.


Converging on a New Theory

K&H argue successfully that current theory is obsolete. However the authors may be limited in producing a new theory by exactly the same background paradigm that makes current theory obsolete. K&H seemingly accept the machine metaphor as appropriate for projects. Machines can be perfected; machines can be understood by investigating their parts; machines can by optimized; machines persist in spite of changes to the environment.

The machine metaphor conceals the nature of a project.

In accepting the metaphor they make three mistakes. First, they accept "project management is a special instance of production" discussing inadequacies of theory in the production terms of "flow" and "value generation". Second, they continue to see planning, execution, and control as separate processes as proposed in their Exhibit 2. Ingredients for a new theoretical foundation of project management. Third, their "Discussion" (section) misses the presence of people and all that is entailed by having the everyday influence of learning, innovation, relationships, and complex ever-changing behaviors on a project.

The machine metaphor conceals the nature of a project. Current theory is activity-centric as are machines. The usual practices of optimizing machines is by understanding it by component — breaking it down into smaller and smaller elements. This is the same practice employed in producing project work break-down structures. We've learned enough about reducing the waste of the materiel processes. We need to put our attention on a more significant waste…the under-employment of people on projects.

We need practices that are systems-oriented and people-centric to produce project organizations that can respond to and enable learning, innovation, relationships, and effective action. Where can we look for guidance? I am encouraged by the work in other fields (not projects or production) on autonomic systems, complex adaptive systems, and biomimicry. I also see the relevance of living systems thinking (Margaret Wheatley, A Simpler Way and Turning to One Another), community (Derek M. Powazek, Design for Community), and sustainability (William McDonough and Michael Braungart, Cradle to Cradle). I doubt current operations theory will provide a unifying theory for projects. Instead, I suspect we will see a convergence of thinking that will lead to new theory. Consider this our leaping off point. Where this will go who knows!


A New Idea…Can I Face the Pain?

I read the following quote from Walter Bagehot in Time Magazine's 2006 end-of-year farewell to John Kenneth Galbraith.

"One of the greatest pains to human nature is the pain of a new idea."

The quote reminds me of the theory-trap we are in with projects. So with this posting I am updating my Notes on the Underlying Theory of Project Management is Obsolete.

While our tools are ever more sophisticated and there is more project management training, our project results languish. The new idea — projects are conducted in an unfolding network of commitments — challenges the very nature of what people do today in the project setting. The PMI is going to great lengths to teach people the old ideas.1 In essence saying, "Just get good at doing what we've been telling you to do all along and your projects will come out just fine." Following that teaching with certification is producing a world-wide paradigm that is having the affect of blinding practitioners to alternative ideas (theories). In the face of that, the agilists are dealing with the pain of their new ideas; so are those adopting lean construction.

Individuals are rarely to blame for project failures.

While I've written extensively on the Last Planner System® (LPS) and its basis in the language action perspective (LAP), the crux of the new idea is that projects are distinctly human endeavors taking place in unknowable futures. Planning and plan execution are tied directly to both the people who are performing the project and the future that unfolds while they do that. Consequently, the new idea recognizes that plans have a shelf life…often a very short one. President Dwight D. Eisenhower aptly said,

"Plans are nothing, planning is everything."

The language action perspective is both attractive and challenging in the project setting. The idea that we can't determine our future is anathema in our engineering-oriented highly successful society. When something doesn't go as planned we are quick to assign blame to a person or firm. Yet, in my experience, individuals are rarely to blame for project failures. We can thank Lauri Koskela, Ph.D. and Gregory Howell, P.E. for helping us understand how obsolete theory has contributed to the results we get on projects.2.

Let planning continue to the last moment when task assignments are promised by project performers.

The Lean Construction community has learned quite a lot since Koskela's and Howell's paper on obsolete theory was first presented. At the latest IGLC-14 conference in Santiago, Chile the LAP was moved to the top of the list of theory that explains how the LPS is transforming the planning and delivery of AEC projects. Four years ago I was not ready to predict that although I was doing my own writing in that area. The work of my firm (Lean Project Consulting) has been based on LAP for over 5 years. Our clients routinely produce far superior results when working from the language action perspective rather than the deterministic reductionist perspective underlying common practice. While there is much more to be said, I'll leave you with these three questions as you consider whether you are ready to face the pain:

  1. In our always uncertain world why exclude what we learn while we go about carrying out our projects?
  2. Why exclude what other project performers learn while they toil with (or for) us on our projects?
  3. How does the reliability of others' commitments affect the reliability of your commitments and the project results?

Let planning continue — it does anyway — in a formal way through the time when task assignments are promised by project performers. While the underlying (generally unarticulated) theory is obsolete, a new theory in use –- one that is well-grounded in human experience of committing oneself to a future –- is producing far superior results. The coupling of planning with execution in recurring commitment conversations — negotiating, promising, declaring complete, and re-promising — builds the network of commitments that brings structure to our projects. It is that structure, not the WBS, that also prepares the planner-doers for noticing variation to the plan as they go about fulfilling their promises. The result is a team with the capacity to adjust what they are doing to accomplish the overall promises of the project.

The pain of this new idea of project management is real. There aren't enough project resources to conduct the project the traditional way and adopt the new practices. Frankly, on many AEC projects there aren't even enough people to do the project the way they want to do it. So a choice must be made. It's the choice to do what we've been taught to do and hope for the best or to stop doing many of those things to make room for more effective practices. The companies that made the decision to change faced real pain. And, in just a few months they have also come to enjoy the success that results. It's time to choose.

©2002, 2007 Hal Macomber. Reforming Project Management


  1. The PMI is succeeding. Membership has swelled from under 100,000 in 2002 to over 300,000 going into 2007. Attendance at conferences is at an all time high. And a cottage industry including top universities has grown to prepare project managers for the certification, CPM®. [ ⇑ back ]
  2. The Underlying Theory of Project Management Is Obsolete, presented at PMI's 2002 Research Conference. [ ⇑ back ]