A popular starting point for the criticism of PMBOK and PMI is a series of papers by Koskela and Howell stating "the theory of project management is obsolete." These can be found on Google using Lauri Koskela, Greg Howell, and obsolete. While the ideas presented there are provocative, they are also useful for asking questions about project management from an external point of view. The thesis is well reasoned (except for some flawed assumptions). But these paper have been raised to near cult status by the agile community, in the absence of the construction context and the flaws of some of the assumptions.
Sometimes quoted directly without having been read. Sometimes quoted out of context. But most times treated as gospel. One slight flaw in this approach is that the papers were not peer reviewed in the sense of a scientific journal, but are treated as such. I say this from the highly biased and narrow minded view of one trained as a physicist and having experience in the peer review process.
All of this started today with Hal Macomber's site referencing a posting on Project Times. These triggered a response I've been meaning to make for some time now. And it goes like this.
===========================================================================
Care must be taken with the Koskela papers. Not that they don't have value, because in the market place of ideas, they are certainly of value, well reasoned and somewhat well written - although the thread of the thesis gets lost in rhetoric at times. But it must be understood, at their heart they are criticisms of
PMBOK in the context of construction and as such are biased in ways not always understood by the causal reader. As well specific assumptions have been made that are incorrect
in some instances. While PMI likely overstepped its capabilities when claiming
Project Management is a profession, Koskela then amplified this to mean there
must be a theoretical basis of project management as his thesis.
This approach
is likely flawed, since the conjecture of project management as a profession by PMI is
itself flawed. All could have ended there, but Koskela continued on (as do
several critics of PMI) to build on this “house of sand.” Too bad, since
there are useful elements of PMBOK that have no need to be “tossed out with the
bathwater.”
One flawed Koskela approach is the rewriting of PMBOK's
description of projects to a "production" point of view. Once that
has occurred, Koskela argues that PMBOK is not appropriate. This is circular
logic at best and a tautology at worse.
While there are legitimate criticisms of PMBOK 3rd edition,
the PMBOK for Construction and the PMI College of Scheduling Guidebook (heavy
construction focus) address some issues Koskela brings up in what is now an
"aging" paper.
A second is Koskela’s use of the thermostatic control analogy
for "feedback." This control loop algorithm is a simple but effective
approach to controlling an “on/off” process. Koskela wants us to accept that
PMBOK suggest a thermostatic approach is recommended. This is simply not the
case, but Koskela continues to argue the failings of this non-recommended approach.
In fact Chapter 6 of PMBOK 3rd edition has four
activities in Schedule Control: 1) Determining the current status of the
project schedule, 2) Influencing the factors that create schedule changes, 3) Determining
that the projects schedule has changed, and 4) Managing the actual changes as
they occur. PMBOK 3rd edition states (in the context of how the
Process Groups interact) “The Monitoring and Controlling Process Group must
provide feedback to implement corrective actions to bring the project into
compliance with the project management plan or to appropriately modify the
project management plan.” Feedback is required and stated as such in numerous locations
in PMBOK 3rd Edition.
These, like all PMBOK elements, are activities that should
to be performed during the management of a project. “How” they are performed is
left to the execution side of project management.
Koskela's conjecture that the sampling period for feedback
is poorly defined in PMBOK is correct. This needs to be replaced with an understanding
that PMBOK does not specify the sampling period for the feedback - just that
"control" is needed. While the criticism may be appropriate, the term
"obsolete" is likely overstated. A simple survey of any control
system book reveals many algorithms for fine grained control appropriate for
project management. Even feed forward algorithms like “earned schedule” and
Monte Carlo Simulation based analysis tools. And since PMBOK does not specify
the algorithm, substituting one of those solves the problem without using the
term obsolete.
As we all know Agile defines this feedback in 2 to 4 week
intervals, and in some instances feedback is provided daily in XP shops for
software development. Many large government contractors define the feedback period
to not more than one accounting period (45 days). For alternative guidance
beyond PMBOK in Defense, look to DID81650, DFAR, DOD PMBOK, Part 2.B.3 of DoD
Acquisition Strategy, DFARS 252.242-7001 and other for specific “execution”
instructions from DOD in the Acquisition Guide.
Applying directly Koskela's paper to software development is
a popular but sporty business. As well, care must be taken in applying PMBOK to
the “production” phase of a project, especially in construction. Execution in
construction is not execution in software or execution in operations of a manned
space flight mission or even the avionics systems for the spacecraft. I am
deeply familiar with all of these domains and it would be dangerous to apply
PMBOK in the absence of experience or consideration of the actual activities on
the project. PMBOK is “A” guide and even then an introductory guide. But obsolete?
Koskela’s thesis is unsubstantiated at best and a thinly disguised sales tool for
Last Planner at worse. Not a problem; everyone has to make a living But using Koskela as a reference academic paper
– as has become popular in the agile community – is troubling for those like me
with a academic background.
No one in Defense sees the role of PMBOK to state HOW to
execute the project – although increased advice would be helpful at times. Nor do
they see it as “obsolete,” – just a starting point – possibly naïve at times. Adding
value to PMBOK is the result in DoD PMBOK.
The sport of PMBOK and PMI bashing seems to be unique to
Agile. It is time to mature Agile execution and ask how to increase the probability
of success (P(s) is an official notion in defense program management), and
build on the foundation of the Knowledge Areas and Process Groups – all of
which should (must) be present in some form for project success.
