PMBOK, Agile and the need for Theory

    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 3^rd 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 3^rd 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 3^rd 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.