Unlearning Project Management

of 37 /37
Unlearning Project Management By David A. Schmaltz ©2008-2010 by David A. Schmaltz - all rights reserved This series was originally published in the Spring of 2008 in the Projects@Word e-zine. I appreciate Managing Editor Aaron Smith for his sharp pencil and warm encouragement of this heretic’s work.

Embed Size (px)


We've been poisoned by fairy tales. Real projects have to unlearn what they learned they were supposed to be.

Transcript of Unlearning Project Management

Unlearning Project ManagementBy David A. Schmaltz 2008-2010 by David A. Schmaltz - all rights reserved

This series was originally published in the Spring of 2008 in the Projects@Word e-zine. I appreciate Managing Editor Aaron Smith for his sharp pencil and warm encouragement of this heretics work.

1- Gresham s Law

In project work, widely accepted fallacies continue to squeeze out effective practice, often by executive edict. Above all, the favored operations management approach trivializes the complexity and uncertainty of most projects, creating self-inicted problems that seriously undermine performance.

The Underlying Theory of Project Management Is Obsolete by Lauri Koskela of Finlands VTT Technical Research Centre and Gregory Howell of the Lean Construction Institute was published in 2002 by the Project Management Institute, yet most organizations continue approaching projects the same obsolete way. Dog bites man. No news. Another revision to PMIs popular A Guide to Project Management Body Of Knowledge (PMBOK) has appeared since then, with no acknowledgement that some of PMIs latest inspections found its foundation rotting and rickety. Hundreds of thousands of individuals have earned PMIs Project Management Professional (PMP) designation, which, according to this material PMI itself published, is based upon out-dated, obsolete but strangely still labeled best practice theories. But then, PMI publishes a lot of contradictory stuff, always insisting upon the author assigning copyrights as a condition of acceptance. PMI released this particular paper in conjunction with a conference presentation, which Howell

described as a hundred people asking hostile questions, followed by forty coming forward for a group hug while sixty others left angry. My mind drifts back to Einsteins catastrophic rst attempts to explain a more accurate characterization of a physical world no one could visually verify to an academy well-schooled in the best practices of visual verication. He was jeered off the stage. A few years later, everyone was positioning themselves to jealously follow someone who theyd reviled as an upstart clerk just a few short years before. Advances in the sciences have always proceeded thus. Business has been even stodgier and crueler. No one likes to discover theyve been wrong. We label this experience learning. Imagine someone claiming you had fallen under the thrall of false formalisms and pseudo-control mechanisms when you had only followed what the certifying bodies qualied as best practices. Or someone else who claims that the very title of project professional has been subverted to mean someone schooled in how projects dont actually work. In economics, this scenario falls under Greshams Law, which says that bad money chases out good. In project work, widely accepted fallacies continue to squeeze out effective practice, often by executive edict. How project management has managed to slide into this tangled position might make an interesting expose. The day when a PMI board member recommended that the organization go into the business of selling certications, one of the dissenting board members sarcastically asked what it would be called: CPM, for Certied Project Manager? A small state university with excess capacity was contracted to create what would become the rst Body Of Knowledge, and a few seats on PMIs board came vacant as some members left for less exposed positions. And PMI shifted from being a special interest group chartered to improve project practice to become the Holy See for a conservative orthodoxy selling indulgences, hoarding intellectual property, and promoting one right way, effectively blocking wide acknowledgement of emerging better practices and the forward evolution of the profession. It became its opposite. Over the many years since that fateful board meeting, the PMI tin whistle has become the gold standard in project management certication. The Body Of Knowledge, which amounts to a lot of re-packaged operations management concepts describing how projects are supposed to work (but actually dont), has guided a whole generation of innocent project managers down a primrose path. Its inuence is expanding. I dont suppose that PMI expected to enter the paradox business when they published their PMBOK, but anyone creating a body of knowledge is sure to encounter what Russell and Whitehead encountered when assembling their Principia Mathematica paradox. All logical systems of any complexity are incomplete. Russell and Whitehead explicitly excluded paradox from their body of knowledge because it muddled up their otherwise smoothly functioning clockwork. Their body of knowledge omitted a limb or two, but mathematicians somehow manage to limp along. I suppose project managers shouldnt be surprised if they have to limp along, too. But mathematics has never suffered

from the lack of a consistent, logically resolvable underlying theory. Project management has, and still does. In their paper, Koskela and Howell concluded that project management has never had its own fundamental underlying theory to guide it. Most theorists characterize project work as a one-off form of production work, assuming away the most common contexts within which projects actually operate and the obvious variations between predicted and actual performance. They conclude that project management fails to perform its function. Some of the simplest projects can be fairly characterized as mechanical manufacturing efforts, but most cannot be so classied. Most projects are orders of magnitude more complex, uncertain and uncontrollable than any production process. The operations management metaphor trivializes project work, creating what Koskela and Howell called self-inicted problems that seriously undermine performance. By comparing the effectiveness of acknowledged best against different theories, they discover some candidates for resolving fundamental, apparently self-inicted problems.

Self-Inicted Problems

Weve been poisoned by our fairy tales Don Henley, The End Of The Innocence

When Einstein presented his early papers on relativity, the science of physics sat atop centuries spent collecting objective, direct measurements. The presumably clockwork universe could be explained precisely, to wide satisfaction. Leaders in the eld had invested their identities in the validity of their worldview, and didnt appreciate some clerk suggesting that their watches were no more than relatively accurate. In their paper, Koskela and Howell identify three beliefs underlying PMIs characterization of project work, nding each of them faulty and incomplete. Rather like Einstein, their paper made some unsettling distinctions. What is work? What is management? What is control, really? Rather than argue about how to better manage and control work, they questioned what constitutes work in this very special context, which threatened timeworn notions of both management and control. 1. The Transformational View: Project management is characterized as the management of work, which is dened in terms of explicit inputs, processes and outputs. Control is achieved by decomposing, breaking down work into explicitly denable pieces, bidding down resource and time estimates for those pieces, sequentially networking them, then assessing quality upon delivery. Koskela and Howell noted that while most projects attempt to follow this pattern, no real-world project ever operates like this. Theres a lot of implicit, non-sequential work involved, which cannot be explicitly dened, scheduled, or assessed. 2. Management by Planning: This perspective separates planning from execution, and assumes a strong causal relationship between planned work and what work actually gets done. Essentially, the authors noted, execution is assumed to fulll

plannings intent and planning is assumed to be more-or-less complete. The manager dispatches work packets to idle processors, telling them what to do, and the processors are assumed to comply. This amounts to an awful lot of assuming. In practice, management cannot comprehensively determine what must be done or who must do it, and what must be done next often changes from what was originally envisioned. Management is not properly situated to foresee what will really need doing. Nor do people simply comply when directed. These assumptions, repeated in practice, result in plans that chase the work or outdated plans simply hanging on the wall while the real, properly situated workers proceed. 3. Thermostatic Control: There is a standard of performance, performance is measured at output (or input), and the possible variance between the standard and the measured value is used for correcting the process so that the standard can be reached. Measuring correctness at the end of the process might inform the next iteration, but the timing is way too late to inuence the quality of the output of the current process. And no specic process is likely to be repeated. Koskela and Howell cite normal rework rates under this regime ranging from 50 percent to more than 250 percent. No reasons for anyone to get angry they were merely reporting how best practices perform. What gets lost in these characterizations of project work is both subtle and inexorable: The Transformational View ignores the critical inuence of value generation and ow. In the popular Earned Value Method, value is assumed to have been created when the explicit deliverable is produced, but this technique mistakes effort for progress, failing to produce equity value in the real world except under very rare conditions. Lasting equity value, they note, is usually initially indenable as a set of requirements, changes over the life of the project, and depends upon more than a contractual or customer representative relationship with the client. Flow is easily disrupted under the assumption that real value requirements are known rather than being discovered, encouraging inefcient scheduling and rework. Management By Planning assumes central control in a world where those controlling have little practical knowledge of what they are controlling and are poorly situated to see what actually needs doing. It ignores the inuence of organizing rather than planning as a key contributor to coherent execution. How we relate is at least as important as what were tasked to do, and perhaps more important. And everyone involved is actually planning as well as executing work. The Thermostat Control model assumes that we know how work is supposed to unfold, when were often poking sticks into darkness. Koskela and Howell observe that most project work is more like a scientic experiment than a nely determinable set of performance criteria. In scientic experiments, we progress even when our experiment fails, not only when it succeeds. Our plans are frequently hypothetical, intended to guide value creation, not simply blueprints guiding assembly.

Their paper distills into a single, fundamental question. Are projects mechanical or organic? Particle or wave? Project management practices touted then and now as best induce a mechanical, particle view that obscures seeing but doesnt exempt the observer from feeling the effects of unseen waves. Anyone could look at any project through a mechanical lens and see only particles, never waves. And PMIs input-process-output yardsticks cant discern the waves. Few project managers claim to be philosophers. They quite understandably wonder when we can stop with the theorizing and just get back to work, never realizing that theyve just exhibited the effect of a theory at work in their own response. In practice, the paper suggests, these might be false dichotomies. Projects are neither exclusively particle nor entirely wave, but both. The PMI perspective omits one side of the coin from consideration, calling heads when there just has to be a tails and an edge there, too. This might explain why projects planned and managed according to PMIs best practices succeed at about the same rate as predicting a coin toss. Koskela and Howell peer over this edge to suggest what might be on the ip side, and cite dramatic improvements in performance when both sides are considered. Those immersed in the particle view display a curious certainty when facing uncertainty. I remember attending an early ProjectWorld conference where the then PMI executive director proudly proclaimed that the Body Of Knowledge had nally evolved to describe every aspect of project work except communication. But then, he smiled, How much specication is necessary for someone to gure out which end of a telephone to talk into? The partisan crowd cheered while I slipped out the side door, feeling eerily like an early Christian escaping from a lions den.

2- Seeing DifferentMost project managers are introduced to a way of seeing projects that is more reductive than holistic more focused on work breakdown than ow and value creation; more metricsmeasured than self-regulating. In Part Two of the series, the author explains why an emphasis on inputs, outputs and certain processes might hinder performance and, ultimately, project value. Editors Comment: The rst installment of this series Unlearning Project Management (March 17, 2008) incited strong reactions from readers, some who rejected the articles premise or were frustrated by its failure to propose an alternative solution, and others who found it insightful and relevant to their own experiences. Projects@Work strives to present a range of perspectives from and for the project management community; in doing so, disagreement is inevitable.Whether the debate inspires new avenues of thinking or serves to conrm long-held beliefs, the resulting discussion is healthy and the essence of our editorial mission. To recap Part One, in 2002, PMI published The Underlying Theory of Project Management Is Obsolete by Lauri Koskela of Finlands VTT Technical Research Centre, and Gregory Howell of the Lean Construction Institute.This paper claimed that project management fails to deliver what it promises, and proposed that simply improving present practice is unlikely to improve results. Instead, a more complete perspective of what constitutes project work, project management, and project control is needed.The authors identied key beliefs limiting improvement: that project work can be fairly represented as sequential networks of input-output transformations; that planning can be complete, and plans can, will and should given explicit change control be followed as intended; and that standards and metrics can effect control. These three beliefs in action The Transformational View, Management by Planning and Thermostatic Control create self-inicted problems and will require unlearning to move beyond. If Koskela and Howells analysis is correct, resolving the project management problem will not require simply improving some currently blessed practices, but seeing the profession in a really different way.

What do you see in this picture? Some people see an Eskimo peering into a dark cavern. Others see the prole of an Indian chiefs head. Maybe you can see both gures, separately. (No one can simultaneously see both gures, though both images seem to share the same space.) You might experience a ipping back and forth, from one to the other, then back again, when you stare at the picture. Many, once they see the Eskimo, cannot recongure their vision to see anything but an Eskimo. Others see only an Indian. What is this a picture of? Its actually some black scratches on a white background. Where do the images originate? If you see an Indian and I see an Eskimo, we might logically conclude that the images reside in the meaning we each make of the scratches on the white background. Not resident in the picture at all, but somewhere inside us. This picture is an example of a different way of seeing, where the image is not this or that, but both and neither. The arguments narrowly delineating what project management entails seem weighted toward Eskimo or Indian; either/or mindsets wrestling with both/and/neither phenomenon; objectifying essentially subjective experience. The picture doesnt show an Eskimo, but it seems to pretty reliably elicit the image of an Eskimo ... or an Indian ... or, in some cases, neither.You can nd a clue to how I rst saw this picture by how I labeled it. I rst saw the Eskimo, and will, I suppose, always rst see what I rst saw there, as if the Indian was mere afterthought. However you see any picture, though, you rst see one way before you see another. For project managers these days, most were introduced to a way of seeing projects that was more reductionist than holistic: more focused upon work breakdown than ow and value creation, more plan-full than playful, more metrics-measured than self-regulating. Of course all projects intend to maintain ow, create value, avoid drudgery, and perform well. But we seem to focus upon that side we saw rst, the breaking down, planning, and measuring, as the real part the part that induces value, ow, play, and proper regulation and that other one, as one we sometimes glimpse as an afterthought. Broadening our perspective wont help because, like in the Eskimo and Indian picture, we can only see the part we focus on, never both images simultaneously. So we must appreciate our inherent narrowness of perspective and leverage it, understanding that whatever our senses might tell us about the completeness of

The Eskimo and the Indian

any perspective, we are at best seeing only half of the possible picture at any one time. We can learn to move back and forth, trading our former certainty for a certain wonder at the possibilities, but only if we can unlearn what this picture really represents to us. This is the dilemma project managers experience today. Over-focusing upon certain types of organization, regulation and control can reliably induce underperformance when, instead, we might manage less and perform a whole lot better. Maybe the label project manager is the source of this dilemma, focusing attention on the management of the effort as if this causes success. Can we see beyond this innocent label? The rst unlearning required will be to somehow unlearn the either/or. To see the world as we see it and to accept what we cannot see as a part of our world, too. We dont lack visual acuity, but vision. We might avoid mistaking our maps for the territory and still miss the subtle fact that what we believe to be territory exists only in our maps of it and nowhere else. We know too well how it is supposed to be, when how we learned it was supposed to be isnt hardly half of the whole story.

Transforming The Transformational View

The [singular] utilization of the transformation model ... leads not only to a passive neglect of the principles of the ow and value generation view, but to an active violation of these principles. Koskela and Howell

Input. Process. Output. What could be simpler? Take something, feed it into a transformation process, collect the result. Traditionally, project management prescribes breaking work down into managable, serial processes. This trance induces as soon as the word project slips off the tongue: break it down. Once decomposed, the resulting bits can be optimized to ensure that minimum inputs produce maximum outputs. Overall optimum, according to this transformational view, requires simply summing (or a seemingly more sophisticated simulating many iterations) of the individual optimizations. Right? Well, actually, wrong. Projects are complex systems that, while they might be usefully considered by peeking into their parts, cannot be overall optimized by taking the Lilliputian view. There are, the systems scientists insist, subtle yet determining relationships between the parts and the whole, the whole and the parts, and even the individual parts, not apparent from any sequentially decomposed view of the whole. Gregory Howell tells the story of the pipetter, who completes his assignment on time, within budget, and well within specication, only to encumber every downstream contractor on the job. He was encouraged to estimate his effort, rewarded for delivering as promised, and thereby burdened the remaining project with unplanned effort. Well, anyone could argue that this project was not properly decomposed; that the relationships between processes was improperly characterized, otherwise our pipe-tter would have understood and reacted to the tacit dependencies.

Will properly breaking down this work make the problem disappear? Is it realistically possible to properly decompose this work? Koskela and Howell characterize the pipetters dilemma as one of a class of self-inicted problems common to the work breakdown, Transformational View. The Transformational View presumes that complex projects can be decomposed into what cyberneticians (scientists who study control of systems) label trivial processes. Trivial processes are simple input, process, output mechanisms that work like light switches. Flip the switch, electricity ows, and the light turns on. Flip the switch again, electricity stops, light goes out. In transformational language, ipping the switch causes the light to turn on. Of course, the inputs, processes and outputs represented in a work breakdown structure are vastly more complex than a light switch, but the analogy holds in that trivial systems are plan-able, history and context-independent, analyzable, and therefore predictable. If we do this, that will reliably result: input, process, output. But the pipetter is learning that these presumptions do not always hold true. Many of the details, even for activities as supposedly plan-able as constructing a building, are unknown and unknowable until workers arrive to sort out the details. Unrecognized relationships between supposedly independent processes are common, no matter how the work gets allocated. Many of the pipe-tters hands-on tasks are impossible to analyze: completing them depends upon the craftsmans history and present context inuencing how he performs his work; he has a feel for the work that isnt observable from outside, may not even rise to his own awareness, cant be translated into language, and yet is essential to successful completion. These factors conspire to make even the pipetters work tenaciously non-trivial, no matter how it might be otherwise modeled. The Transformational View simplies, but then thats the objective of work break down schemas. In practice, these simplications over-simplify because they mistake what those scientists who study system control call non-trivial processes for trivial ones. From the outside, a non-trivial process looks exactly like a trivial one. Inputs feeding into a process, leading to an output. What goes on inside the black box is worlds different, though. In trivial processes, the state of a process is unchanged by the invocation of the process. Switching on the light doesnt change the function, potential, or the predictability of the switch. In non-trivial processes, its as if ipping the switch changes not just the light, but the switch itself. Non-trivial processes change not just an input into an output, but themselves as part of their operation. This small shift transforms a history-and-context-independent, predictable process into a history and context-dependent, analytically-indeterminable, unpredictable one. How unpredictable are non-trivial processes? Alarmingly! Heintz von Foerster, another cybernetition who founded the famous Biological Computing Laboratory, calculated that a simple, easily plan-able, four input-four output, non-

trivial process capable of changing its internal state in just two ways can produce over four billion unique results! How much more complicated is the actual, situated work the pipe-tter performs? No amount of outside analysis will improve the discrete predictability of such work. The odds against accurately modeling this work are unimaginably long.

A Handful of Magic Beans

Any sufciently advanced technology is indistinguishable from magic. Arthur C. Clarke

Work breakdown-style planning is not properly situated to successfully predict. It must trivialize to succeed, and, in trivializing, it often fails to either guide or predict. Or so the numbers suggest. In practice, the planning only begins with the creation of the master plan. Every contributor might well hold this responsibility to the project as a whole: to replan whatever work they are performing while they are performing it. This continuous replanning can incorporate the situational variables not present in the original planning, and can materially shift the actual plan of attack.Yet, even this situated, detailed consideration can be distracted by The Transformational Views process orientation. Technology leadership guru Jerry Weinberg used to open his Problem Solving Leadership workshop with a simulation that well-illustrates the effect of mistaking a non-trivial process for a trivial one. Given a simple set of rules, four teams were asked to predict the output produced by a black-box process. When I read the rules, I immediately recognized them as the rule set for another game I had read about somewhere, so I announced to my group that I knew the trick to this exercise, which got me selected as the groups leader. After the rst round, my team was skunked by the competition. Second round, same result. For the third round, my team elected another leader while I sat on the sidelines wondering where Id gone wrong. In the end, success in this game was largely determined by luck and insight, though each team had developed a system for predicting what the black box would produce from a given input. Most found it overwhelmingly difcult to step away from their initial predictions to gain the insight their luck was trying to provide. We usually construct ever more elegant input-process-output explanations for otherwise unexplainable events and miss the opportunities to leverage luck with insight, because what might later be characterized as good luck leading to insight is experienced in the moment as bad luck demonstrating lack of foresight. This behavior is a classic, common human response to interactions with the unknowable. Characterizing projects as decomposed series of knowable, discrete, sequential, input-output transformations causes some real problems in execution, but what are the knowable, discrete, sequential, input-output process recommendations for improving this situation?

In practice, as is so often the case, the observed problem might not be the real, addressable issue at all. The problem with The Transformational View is that, while useful for analysis, its easily imprinted on as the way to actually complete the project, and many nd it next to impossible to see beyond the narrow perspective it brings. The problem isnt the problem, how we cope with this feature can make it inexorable. My scientist friends keep reminding me that The Scientic Method is a myth. Most important advances in the sciences originated in insight, not rigorous adherence to investigative method. When the experiment fails, a breakthrough might appear. While this fact doesnt convince any scientist to ditch their mythodology, it does serve as a reminder to remain mindful of things going on outside their carefully constructed frameworks. The same things going on in project management. Someone it might as well be PMI will maintain an orthodoxy, but no skilled practitioner will take that characterization more seriously than they should. They remain mindful that their ne attempts to predict outcomes will remain tenaciously dependent upon absolutely unpredictable conditionslike whether the pipe-tter has a cold that Tuesdayand to depend upon luck and insight to guide them through. Where does luck and insight reside in The Transformational View? Like in the mythical Scientic Method, insight does not reside there. Whether The Transformational View blinds us to the insights necessary to actually complete projects, or humbly steps aside to open the space for possibility depends more upon the practitioner than the method. Each practitioner develops over time a handful of magic beans that compensate for the shortcomings of their espoused methods. These depend more upon the character of the practitioner than the goodness of their method, and rarely involve input-process-output characterization. I will defer identifying more magic beans until later in this series, but I want to reassure those who might nd my analysis annoying, that I will offer a handful of magic beans by the time we arrive at the end. Expect the technology to be sufciently advanced to not look much like technology at all. These beans will, like I prefaced above, depend more upon the practitioner than any outside technology. But Ive barely chipped the surface of our project management dilemma thus far. In the rst installment, I cited a paper that named The Transformational View, Management By Planning and Thermostatic Control as apparently decient foundations of the present theory of project management, and Ive only addressed the rst of these three deciencies in this installment. In the next installment, I will consider the dilemmas induced by the belief that management is primarily accomplished by planning. Bear with me, we must rst sink deeper into our dilemma before we can hope to resolve anything.

3 - Don't Task, Don't Tell

Can projects managers better serve their teams and achieve more valuable results by not getting involved in task-level planning? Yes, because the real-time judgment of those who are executing the tasks will probably be more constructive and insightful than a detailed plan created before work even began. Its not abandoning the plan, but using it more as hypothesis than directive. Plenty of people wish to become devout, but no one wishes to be humble. Joseph Addison

In part one of this series, I presented ndings outlined in a PMI-published paper, The Underlying Theory of Project Management Is Obsolete, by Lauri Koskela and Gregory Howell. The authors identied key theories underlying PMIs PMBoK that inhibit project performance: The Transformational View that project work can be fairly represented as sequential networks of input-output processes; Management By Planning that the manager can create complete plans, which can, given explicit change control, be followed as intended; and Thermostatic Control that standards and metrics effect control. The paper claimed that these three beliefs in action create self-inicted problems and will require unlearning to move beyond. In part two, I considered some of the inherent limitations of The Transformational View: while useful for analysis, it trivializes situated work and is difcult to see beyond the perspective it induces. I suggested that seeing a project requires seeing through dened processes, combining presence with projection, and that this ability depends upon the mindfulness of the practitioner.

In part three, I will more deeply consider the second theoretical: Management By Planning. The paper noted how little PMBoK has to say about other aspects of managing projects, focusing much more attention upon planning than any other activity. In the now-classical characterization delineated around 1900 by Henri Fayol and Frederick Taylor, the purpose of management was to plan the one overall best way to approach work. Management devised the work sequences, approaches and assignments. Work from the resulting plan was dispatched to workers as they became idle, enabling work at the time, heavy industry and construction work to systematically proceed. This theory doubtless improved the price and time efciency of many kinds of work, though often at considerable, unaccounted for human cost. It also separated planning from execution, and relied upon the prescience of the manager to succeed. But, as Howell and Koskelas paper described, the manager is often poorly situated to plan accurately or completely. Not all work can be planned, and some work can actually be inhibited by the presence of a task-level plan. They questioned the belief that casting the manager in the role of chief planner is necessary or benecial; that the role of project manager means planning others work for them. Emerging Agile and Lean approaches cast project management in a distinctly different role than that of Chief Planner of the Work. Many agile practitioners argue against the necessity of the project manager role at all, explaining that only the people performing the work are properly situated to plan their work; but even Agile approaches plan as a means of managing. The theory casting projects as one-off operational work seems to insist upon the necessity of a guiding, management-produced, task-level master plan. Interestingly, agile advocate Mary Poppendick, who for many years worked in manufacturing for 3M, claims that anyone who believes that managements master plan guides production work has never worked in manufacturing. Even there, which might be the most tightly controlled work context, situated workers adapt to conditions never foreseen when the master plan was produced. Of course, every practicing professional is familiar with these paradoxes of planning. They understand that plans are notional. They have personal experience with being poorly situated to plan. Most deeply understand the difference between the notion that plans predict and the pragmatic understanding that they do not. Whatever else planning might achieve, it imprints a perspective on the planners. This perspective is almost certain to fail whoever is tasked to follow the plan, and the unlearning required to meaningfully diverge from the imprinted conceptual model seems a necessary hurdle to actually achieving results. Still, many of us feel an increased comfort level when we encounter a plan, as if it gave us a window into a future none of us could actually see. The challenge is not: to plan or not to plan that is certainly not the question I ask here. Nor do I argue against or in favor of different planning

methods, each of which might well provide useful perspectives. What is the role of management in planning? Is managerial authorship central to the proper management of a project, as the Management By Planning philosophy implies? When might the manager usefully avoid getting involved in task planning as a means for managing a project?

Managing By Trusting

Over the last three years, Google has run a project called The Summer of Code, in which they pair up university-level software developers with open source software projects. If the student succeeds in fullling the goals set forth in their program application, they are paid a few thousand dollars. On the Edge Inc. website, Chris Di Bona, Googles Open Source Programs manager, reported, We wanted a program that would keep software developers coding over the summer and it would also help out our friends in the world of open source software development. Last years passing rate was just over 80 percent, which means that more than seven hundred students completed their projects to the satisfaction of both their mentors and projects. They achieved this result without management producing any task plans. A cursory study of the code produced by these students reviewed, among other items, how many lines of code each student produced. Di Bona notes, The lines of code thing has been done to death in the computer industry, and it's a terrible measure of programmer productivity. It is one of the few metrics we do have and since we make the assumption that if the code passes for the project, their code has passed muster. So after that, the lines of code become somewhat more signicant than it would normally. Over the summer, the average student produced 4,000 lines of code, with some students producing as much as 20,000 lines. Di Bona concludes, This is an insane amount of written code, weather you measure by time or by money. By some measures this means the students are anywhere between ve and forty times as productive as your 'average' employed programmer. This code, mind you, was written by a student who is almost always geographically separated from their mentor by at least three time zones and almost never has a face-toface meeting with their mentor. This is an absurd amount of productivity for anyone writing production- and user-ready code. It's really something to see and made me revise what I consider a productive developer to be and what indeed I should expect from the engineers that work for and with me. Can I keep my hands off and let things run their course? I now think the answer is yes, they can run each other better than I can run them. Di Bona is still considering the ramications of his discovery. Hes acknowledging that the alternative to management by planning will require a potentially disconcerting amount of managing by trusting, but his experience suggests that in the context within which he works, extending trust might be a benecial

substitute for managing by planning. Hes unlearning his earlier notions of what it means to manage his developers.

Heading West

Have you noticed that experienced professionals can often very accurately estimate project time and cost at a very high cocktail napkin level, while detailed task-level plans rarely prove as accurate? For those of us conditioned by spreadsheets to expect the details to accurately sum to the total, this is an unsettling observation. Jim Goughenour, former VP and CTO of Sealy, Inc., adopted an interesting alternative to management by task-level planning. His preferred form of plan was a statement like, Were heading West. He would justify the overall inquiry with high-level time and treasure assessments, something that he could easily produce on the back of a cocktail napkin, then charter the project to move in some denite direction. This method, he claimed, avoided setting unrealistic expectations about the route or the destination. He recognized that no one in that organization could nely determine requirements or produce a reliable task plan from the outset, so he left the guidance of the effort up to the judgment of those chasing the goal. Later, if the project team found it useful, they might produce a detailed, logistical task plan for heading South, after meandering for what might easily be considered a very long time. The team could wander as their judgment guided, without carrying the added weight of explicit change control before they had an explicit destination in sight. Some might argue that this is an awfully primitive way to manage. The only thing this hunter-gatherer technique had going for it was that it worked, and worked pretty reliably in that context. Goughenour rmly believed that his project leaders and team members were smarter than he could ever be about the details of their situated work. Goughenour is a master at projecting vision, working the political networks to gain buy-in, and also a savvy investor. Hed learned that micro-managing his investments didnt improve their performance. He invests where he sees potential and stands aside while that potential develops.

Managing By Conditioning

After seven months producing the most detailed task plan Id ever seen, a project manager met with many of the contractors whose work assignments were represented in the plan. Each had contributed to the plans creation, but the group had never considered the whole plan together. As you might expect, every contractor had already reviewed the master plan to see that their work was represented as they had bid it. This session, organized by Gregory Howell, would focus upon something different than individual task assignments. The project manager had done a masterful job resolving the usual contradictions involved in planning any construction project: accounting for material delivery lags, logical sequencing and presumed rework. The plan was as good as it could realistically have been from the project managers perspective.

Howell started the session by asking, What wont work. A long silence followed before a master plumber remarked that the blueprints, upon which much of the plan details were based, had not been updated in a couple of decades, in spite of several signicant changes he, himself, had completed on the property. The project manager said nothing while the full effect of this eleventhhour news settled over the group. What else wont work? Howell continued. Over the course of the day, the group identied dozens of difculties, great and small. The overall sequencing of the effort shifted, which, had these difculties been discovered, as they typically are, on the job site, would have cost millions more and added months to the effort. Even more importantly, Howell had conditioned the contractors in what it would mean to follow the plan on the job site. Following the plan would mean continually asking, What wont work? It would also mean more than fullling contractual obligations for any contractors individual piece. The plan would be presumed to be suspect, rather than correct, and the good judgment of every contributor would be enlisted to continuously replan the effort. Howells exercise highlights the recursive nature of planning. Where ever it starts, whether by a management-by-planning mandate or somewhere else, it never actually ends there. The plan, Howell concludes, is a hypothesis, rarely a roadmap. Those contractors had never before been conditioned to see their plans in this way, but many insisted they would never agree to follow another plan before conditioning contributors like this. Perhaps the most useful result of Howells effort was a plan that would never be displayed on paper. Through the course of the day, every contractor developed relationships with other contractors who, had they merely focused upon their assigned tasks, would have been unlikely to emerge on the jobsite. These relationships would guide the work in ways no management-produced task plan could ever prescribe. Management By Planning, carried to its naturally recursive root, enlists every member of a projects community as a planning project manager, which is far from Fayol and Taylors original Management By Planning intent. Each interprets the plan they receive, producing a locally situated version. Whether the plan received is wise depends, again, upon the mindfulness of each situated planner. Whether the project manager is wise might depend more upon their ability to listen than their authority to dispatch pre-planned work assignments. In the Spanish viceroy system, a bureaucracy that lasted more than 500 years, each viceroy reported directly to the king. Communications being slow in those days, a dispatch from the king, responding to a viceroys report, could take more than a year to reach an individual viceroy. So, the viceroys adopted a simple rule for interpreting directions from the king The King Is Wise. This rule encouraged each local viceroy to interpret the kings direction in some way that would preserve the apparent wisdom of the king, even if this meant utterly changing his specic instructions.

We see a similar mindset at work in Lean and Agile project approaches, which advertise themselves as more results-oriented than plan-driven. Extreme resultsdriven project approaches expend more effort clearly envisioning the end result than charting any distinct path of tasks to get there, iteratively re-creating organizations, relationships, and explicit agreements intended to produce discernable value, as if the project might end after any iteration. Each of these alternatives to Management By Planning involve some form of planning, and some of them even employ very detailed task plans. However, they share a focus away from the task plan as the primary means of managing, considering the task plan, at whatever granularity, as a supplement to situationally more meaningful guidance strategies, prominent among them the judgment of situated crafts-persons along with the judgment of the project manager. Fayol and Taylor worked within industries that had relied upon the often-uncoordinated judgment of individual craftsmen. Their planning-centered coordination strategies superseded individual judgment, and in those contexts, resulted in dramatic reductions in production costs, often at considerable human costs. Increasingly, the work we engage in under the label of project requires reinjecting the situated judgment of individual craftspersons. This condition shifts the meaning of planning from tell us how well get there to design some framework within which to pursue management by organizing more than by planning. Like the computing pioneer, who disparaging the misunderstanding of computings power, remarked We compute for insight, not answers, todays planner often plans not for answers like how long and how much, but for deeper insights into the nature of what evers being planned. The plan, in these contexts, is more like a tent than a castle, expected to be disassembled without much fuss and bother, whenever the activity shifts the original purpose to a more alluring one.


If one characteristic distinguishes projects today, re-purposing must be that characteristic. Taylor and Fayol worked within contexts where the purpose of their efforts was well known and unchanging. How many can claim such stabile contexts today? So, management by planning, in todays project contexts, seems at best incomplete. Master project managers understand that the act of planning deeply considering together with the projects community might well be more important than any nely nished plan, and that the notions inevitably imprinted upon during the creation of every plan cut both ways. Whatever the planning method or the form of the plan, unlearning will very likely be needed to effectively use that plan. So, we begrudgingly baseline, understanding that the formal ceremony entailed in justifying changes to a master plan neither adds value nor control. And that mastery of planning sometimes entails creating no master task plan at all. If youre anything like me, you might feel quite naked proceeding without calculating the critical path for a network of hypothetical tasks without

wishing upon some distant, unseen star. I seem to default into needing that security blanket, which has so often proven to be more a barrier to discovering a better path than real security. I continue to unlearn what I learned before experience insisted otherwise. In the next installment of this series, Ill consider the third theory that Koskela and Howells paper characterized as obsolete, Thermostatic Control.

4- The Control Dilemma

Widely used project control methods often require more maintenance than the systems (and the people) they are intended to control.The pursuit of control becomes more burden than value facilitator. But on real-world projects, independent agents act in ways no closed-loop or anticipatory control mechanism could predict and often for the better. In part one of this series, I presented ndings outlined in The Underlying Theory of Project Management Is Obsolete, a PMI-published paper by Lauri Koskela and Gregory Howell.The authors identied key theories underlying the PMBOK that inhibit project performance:The Transformational View; Management By Planning and Thermostatic Control.The paper claimed that these three tacit theories in action create self-inicted problems and I proposed that they require unlearning. In part two, I considered some of the inherent limitations of The Transformational View: that while useful for analysis, this perspective trivializes situated work and is difcult to see beyond. In part three, Dont Task, Dont Tell, I evaluated Management By Planning, citing situations where management succeeded by other means.

In this installment, I examine the limitations of using Thermostatic Control to resolve the control dilemma.The maintenance man is moving the thermostat in our ofce today. I started talking with him about the Thermostat Wars [from Dilbert comics]. He told me about one ofce with 30 women where they could never get the temperature to an agreeable level. At his suggestion they installed 20 dummy thermostats around the ofce. Everyone was told that each thermostat controlled the zone around itself. Problem solved. Now that everyone has control of their own thermostat there is no problem. Scott Adams

The Thermostat Wars: Turn Down The Heat!

When a project can be guided by a reliable set of management-planned, hierarchical and sequential input-output processes, control presents no real difculty. One can monitor for difference, document changes, and regulate scope using widely accepted feedback and decision methods. But, as outlined in the

previous installments of this series, projects are not reliably like this. When we assume that they should behave like this, we can cede control to techniques that might at best provide an illusion of control. I hate to bring this up, since were all sick of this example. And, strictly speaking, this example isnt really a project, but it has been managed as if it were. This is my point. The United States sent troops into Iraq to achieve some simple-seeming objectives: destroy weapons of mass destruction, unseat the dictator, and leave. Easily measured, conveniently controlled within certain bounds. When no WMDs were found and locals rioted, objectives shifted: defeat the insurgency, stabilize cities, train local forces, and install a democracy. Not so easily measured, control became more difcult. With the counter-insurgency strategy came a set of 18 new benchmarks, offered as reliable indicators of success. Seemingly easy to measure, but apparently impossible to control: a year later, three of these benchmarks were somewhat met, and the stability achieved was characterized by the general in charge as fragile and reversible. What next? Congressional hearings now ght a different war, one focused upon determining how progress might be measured and how deployment might be controlled. These are thermostat wars, quite similar to the one described in Scott Adams story. Software guru Michael Jackson identied three kinds of systems: lexical, causal and bid-able. Lexical systems are symbolic. Mathematics is an example of a lexical system, perfectly consistent and controllable within the boundaries drawn around its domain. Causal systems are mechanical. These are, by design, predictable and reasonably model-oriented, and are capable of optimization for their purpose. Bid-able systems, Jackson describes, include any system involving human decision-making. Bid-able systems, unlike lexical and causal systems, are neither internally consistent nor optimizable, but operate through the personal choices of individual agents. Bid-able systems are not simply different in degree, as lexical and causal systems are, but different in kind. They require different control techniques than those employed in lexical and causal systems. The thermostatic techniques intended to effect external control over bid-able systems, work ineffectually, if that well. One successful project manager conded his secret of project control: nd the natural rhythm and match expectations with that. If you cant nd that rhythm, it wont much matter what you do to try to control the project. If you can nd it, it might not matter what you do to try to control it. Just nd that rhythm and match it. Not all bid-able projects are blessed with a naturally rhythm-appreciating environment. Some organizations believe themselves to be masters of their projects, able to regulate them however they see t. But these projects have minds of their own. Disrespect the natural rhythm and you induce uncontrollable arrhythmia. Trying to control arrhythmia is a fools mission.

My colleague, physicist Mark G. Gray, recounts the story of a large government project that met the letter of a milestone, but failed to deliver to the undocumented and under-appreciated spirit of it. The customer, frustrated by iterations of spirit-less, letter-of-the-agreement deliveries, rejected this deliverable at the very last moment, throwing this effort into funding default. This is how bid-able systems work. There must be an offer, a resonating bid, and some form of acceptance. Commanding acceptance using the letter of an agreement can undermine approval along with control. While both lexical and causal systems behave rationally, bid-able systems behave non-rationally. Not exactly irrationally, but not rationally, either, for human decision-making is rooted not in any rational decision process, but in how the decision-maker feels. If your customer distrusts you, for instance, that mistrust will inuence your ability to control the effort. Much of what motivates and informs bid-able systems too often remains unspoken, undocumented, and at best tacitly understood by all parties. A felt sense best describes agreement. Control, in this context, demands something other than an explicit target, tied to objective feedback, followed by rational response. This is the control dilemma facing projects operating today. Our techniques kinda-sorta work. Quite unlike the causal, mechanical context assumed in the PMBOK, projects are often better described as dynamic human systems. How might we better control these? Understanding why the Thermostatic and Anticipatory Controls described in the PMBOK offer incomplete regulation might help us unlearn how project control is actually achieved.

Inside The Closed Loop

The control implied by the PMBOK is called closed-loop or Thermostatic Control: set metrics and measure performance against them. When discrete prediction is impossible, thermostatic controls can provide a lagging kind of regulation Did that work?. Thermostatic control is powered by feedback, evaluating results against some target and adjusting subsequent performance to meet that target. As everyone with a thermostat understands, closed-loop control requires difference to work. When the room becomes too hot, the thermostat shuts off the heat. When its too cold, it turns it back on again.You experience what you dont want to achieve what you want. Listen to projects operating under closed-loop, thermostatic control, and youll hear a lot of people saying the equivalent of, Turn down the heat! While overall performance might approach set targets, individual experience will feel more like a continuous stream of errors than awless execution. The language used when describing thermostatic control might be the source of the control dilemma. When you spend more than expected, youre causing a cost overrun. When delivery takes longer than expected, youre called a schedule-buster. When you fail to deliver expected quality, your performance is disappointing. Cost, schedule and quality assumptions too-easily morph into statements about competence, rather than value-less difference. And these judgments take their toll on the humans involved. We learn to anticipate error and to sense our inabilities rather than perform to our full

potentials. Carried to a small extreme, we become paranoid. Standards and metrics, intended to delineate minimum acceptable criteria, evolve through this repetition to represent maximum capability, eroding the quality of individual experience along with the quality of the resulting work product. We might understand that honey attracts more bees than vinegar, but closed-loop, thermostatic control insists upon a steady diet of vinegar negative feedback to effect control. Thermostatic control is a causal, mechanical control strategy. For projects more properly characterized as organic, bid-able rather than mechanical systems, lagging control mechanisms are of limited utility. One cannot control an organism as one controls a machine, for the organism has physical capacities quite unlike those of any machine. Regulating organic systems requires something more and different than a diet of backward-looking thermostatic control. In practice, the timing of external, closed-loop control is often out of synch with a projects ow and rhythm. Because it depends upon sensing out-of-bounds conditions, it changes course only after error is experienced, encouraging, rather than avoiding, recursive rework loops, which disrupt ow and frustrate real control enhancing the sneaking suspicion that the project is not really very controlled at all. Control could be better realized if we could anticipate future states.


Which leads us to a second form of control, also quite popular in the project world, Anticipatory Control. Imagine a programmable thermostat that can be set to automatically turn the heat down at bedtime and turn it back up when morning comes, and youll imagine a simple anticipatory control system. Anticipatory control requires the ability to model expected performance and allows pre-adjusting measurements according to a pre-determined set of rules. Anticipating control requires a model of the system sufcient for prediction. Not an exact one-inch-equals-one-inch simulation, but some form of good-enough model to produce reasonable speculation about likely future behavior. In a project context, popular predictive models center around statistical inference algorithms that suggest likely paths rather than delineate exact ones. And, of course, every model is prone to modeling the modeler along with the system it intends to represent, carrying subtle prejudices that deeply color the meaningfulness of the resulting inferences. In practice, anticipatory control requires the modeled system to exhibit random behaviors that cannot be precisely determined though they are commonly precisely assumed beforehand. A good anticipatory control system demands decent anticipation on the part of some controller, and this assumes a causal rather than a bid-able system context. Whether that controller acts alone or by a more inclusive and collaborative process, the usefulness of the resulting control depends upon the goodness of the anticipation, and we have good reason to question how well we can anticipate the behavior of any bid-able

project. We can easily hobble potentially useful variety to achieve control, inhibiting the very inventiveness swerves and insight veers that our projects rely upon to succeed. Just this morning, as I rose early to work on this essay, I noticed the house a little colder than I appreciated. I checked the thermostat, an anticipatory one, and remembered that it assumes the house should stay midnight cold until seven in the morning. At four, it was three hours behind what real-life conditions wanted. I could have simply gone back to bed and waited until the climate automatically changed into one more hospitable, but I pumped up the heat instead, innocently trying to violate the second law of thermodynamics by adjusting the control above the regularly anticipated daytime setting. Then I manually reset it when the house ended up warmer than I wanted. I ght these little skirmishes almost every morning because I rise when inspiration moves me, not when the alarm clock says its time to rise. My behavior isnt predictable enough to be properly served in anticipation. In their paper, Koskela and Howell reported how projects often execute independently of their controls, leaving the formal controls moldering on the wall or chasing the project when the controllers anticipation falls behind the projects situated action. This tangle often occurs in the name of control, where control is properly assumed to be achievable only by anticipating, but where correctly anticipating proves impossible. One can easily implement a mindless, mechanical control strategy that requires more maintenance than the thing it was intended to control where the control mechanism shifts roles and becomes the controller of the controller, rather than the controller of the system it was intended to inuence. When this happens, project delays are caused by change control, more time gets spent anticipating notions about the system than actually observing the system in action and adapting, and project control becomes more burden than value facilitator. In practice, no project relies solely upon closed-loop and anticipatory control strategies, though one might not come to this conclusion if oriented by PMIs PMBOK. On real-world projects, independent agents act in ways no closed-loop or anticipatory control could predict. The metrics underlying closed-loop assessments cannot anticipate situationally good-enough or emerging contextual t. The model underlying anticipatory control is incomplete in ways no one could anticipate, so even when we rigorously anticipate, we might be simply blinded by this light we shine into our projects. However we attempt to achieve external control, we will sometimes be left poking sticks into absolute darkness. In these dark moments, our theoretical controls nd little utility. And, when were lucky, we stumble upon unanticipated controllers, ones excluded from the PMBOK and discussions of both closed-loop and anticipatory control strategies. We will have to unlearn some well-imbedded theories about how and what to control to reliably produce real value. Well need to turn down the heat!

In the next installment, Whos Managing Whom?, Ill introduce some cool controls, unexplored in the Project Management Body of Knowledge, that could put an end to your Thermostat Wars.

5- Who s Managing Whom?

However you might dene project control, you should question its purpose before attempting to accomplish it. Otherwise, you may default to a control strategy poorly matched to your intentions and your projects purpose.Theres considerable evidence that individuals, not managers, PMOs or progress reports, exert the most meaningful control over successful projects, and that external controls can compromise this inherent capability. In part one of this series, I presented ndings outlined in The Underlying Theory of Project Management Is Obsolete, a PMI-published paper by Lauri Koskela and Gregory Howell, who identied key theories underlying the PMBOK that inhibit project performance:The Transformational View; Management By Planning and Thermostatic Control.The paper claimed that these three tacit theories in action create self-inicted problems and I proposed that they require unlearning. Part two Seeing Different considered some inherent limitations of The Transformational View: that while useful for analysis, this perspective trivializes situated work and is difcult to see beyond. Part three, Dont Task, Dont Tell, evaluated Management By Planning, citing situations where management succeeded by other means. Part four examined the limitations of using Thermostatic Control to resolve The Control Dilemma. Here, in part ve, I consider some of the control mechanisms unanticipated by PMBOK.

What does it mean to control a project? If you follow the PMBOK, youre excused for interpreting control as meaning containing scope. We seem to be much better trained in controlling to contain cost, for instance, than in controlling to create value, and these two objectives are often mutually exclusive. Controlling cost might not be entirely irrelevant, though, since cost can be a derivative of value. But cost, even when it is a derivative of value, isnt the value we seek. The expectation that one might create real value by merely

controlling scope is a common, self-destructive delusion, and one PMBOK does little to deect. The standard points of scope control outlined in PMBOK time, cost and quality ignore value creation in favor of loosely associated derivatives of that value. This association encourages practitioners to direct their efforts toward expense containment rather than value creation, to consider their primary inuence as limiting expenditure rather than sustaining an investment. In a recent conversation, Howell remarked, Current project controls increase risk in projects ... external risk is rarely the killer. Things most often go wrong because of the wreckage caused by the feedback and control used in current PM: control for cost, squeeze em down, and the people will nd a way to do just what you ask reduce the immediate cost of their work. This reduces the predictability of workow in the system, further reducing performance. Hazing managers in response to further cost increases puts projects into the death spiral. Meaningful control requires that you control things that need controlling. Theres adequate evidence to conclude that containing cost, time, and quality is anathema to creating real value. While such budget controls are simple, they can control elements that might not need much controlling. Listen to how we describe what we do. Most of us describe our projects, not by the value we intend to create, but by how much money and time has been budgeted. Few of us understand how cost compares with the value were producing. We might have performed a discounted cash ow or a cost/benet analysis without ever discovering our projects real value. Without this value, what is left to control but cost, time and quality? And how does one control for value, anyway? What to do? The best projects we know are managed under a cost plus small fee basis with a signicant prot pool where savings are allocated in proportion and advance, Howell reports. The goal is to create an investment mentality where money is able to get to the place where it reduces waste or adds value. And under the cost containment philosophy, how could it make sense to allocate more than the estimated cost for a project, and agree to distribute to the project whatevers remaining upon delivery? There is some rule that says that your ability to deliver is limited by the ability to shift money to where it matters. Our ability to deliver responsibly is always at risk and limited. The ability to take money out of one pocket or another increases our ability to deliver. I am not turning the asylum over to the inmates. I am trying to create a project as a collectively (rather than an externally) controlled enterprise, as [lean construction project management advocate] Will Lichtig calls it. However you dene control, youre well advised to question the purpose for controlling before attempting to accomplish it. If youre well versed in the PMBOK, youre likely to default to a control strategy poorly matched to your intentions and your projects purpose. Theres considerable evidence, even back

to Ecclesiasticus (38:31-34), suggesting that individuals not managers exert the most meaningful control over every project, and that external controls can and do compromise this inherent capability.

Unanticipated Control

Classic characterizations of management imagine the manager as somehow more prescient than the projects he controls. But real-world managers learn to depend upon controls unanticipated by any father-knows-best theory. When not if a project quite naturally veers out of patterned behavior or when an anticipated project proves less than predictable, Thermostatic Control proves unworkable. The term project manager can mislead us into believing the manager should respond. We should say project managing to more accurately imply who manages whom! Where control is effected, the project manages the manager at least as much as the manager manages the project, usually even more. Unanticipated control appears after the designated controller accepts that a project is actually populated with independent agents, each of whom is a lot wiser about their part of the system than anyone else could ever be. The wise controller then cedes rather than delegates control, since delegating control is just another form of closed-loop or anticipatory control. This does not mean that project managing means capitulating to chaos as the ultimate controller. Quite the opposite, it requires that the designated pilot merely acknowledge the fact that most airplane accidents occur not due to thermostatic mechanical failure or unanticipated conditions but pilot-induced oscillation. Over-ying. But airplanes are meticulously designed and rigorously engineered to be largely self-controlling. Assign workers to do an artisans job and youll doubtless nd the need to exert endless intrusive controls which wont make much difference. Design the effort to depend upon naturally self-controlling artisans and youll nd little need to exert external control. Noted social scientist Gregory Bateson claimed that behavior is greatly inuenced by what he labeled context markers. Context markers are subtle environmental cues that inform behavior. For example, organize the furniture in a room to resemble a church sanctuary chairs set in rows with a center aisle, table set at the front holding a large opened book and a burning candle, dim the lights and people entering the room will, without being directed, hush their conversation, fold their hands, lower their eyes, and silently take a seat. Ask them why they chose that seat, and many will reect that their choice corresponded with where their family always sat in church. Those whose seat was taken by someone else often nd themselves unfocused and anxious. This is the power of context. Deliberately setting context markers can preconsciously induce control or the need for it. Look at the context markers of external control: time reports, written justications for divergences, public disclosures of shortcomings. These markers imply that someone is watching to see if your pot boils. It boils begrudgingly.

What context markers might induce more meaningful self-regulation? Trust remains the most powerful, but may require some conditioning. People are not usually aware of their own reliability. Most will claim that they are more than 90 percent reliable, but measure out at about 50 percent. But the difference is rarely their fault. Someone else delivers late or poorly, stumbling their effectiveness. Responsible relationships are missing in this familiar scenario. Focusing upon delivering their piece of work creates a context marker that encourages relationships to seem of minor importance, when all project work is heavily dependent upon maintaining explicit and responsible relationships with those you receive from and those you deliver to. A responsible relationship includes explicit promises rather than implied dependencies. Responsibility includes reneging on your promise as soon as you must, if you must, as well as simply delivering as promised. Early, explicit reneging allows adaptation. Learning later that the delivery wasnt on time undermines ow along with any possibility for control. Simply making individual reliability explicit sets a context marker that encourages individuals to take responsibility for their own exchanges, and leverages market forces to improve the projects ability to create value and control itself. Projects, like markets, are comprised of less-than-fully informed individuals who can produce remarkable equilibrium if they understand trading patterns and ethics. Projects not conditioning their communities in these ethics of trading nd external regulation their only, albeit much weaker alternative. Along with the anticipated control systems, every project depends upon these independent individual agents. They will not always respond as any external controller would (thank heavens) because external controllers are poorly situated to affect control. Independent agents are capable of acting in concert, rather than simply creating chaos. Look under the hood of any project, and youll nd thousands of little, situated choices that sum to the soul of that efforts control engine. Some of these controllers are strong-willed, and nudge the project toward a purpose originally unanticipated. Others question the metric when it doesnt match the situated need. Taken together, these subtle nudges effect more control than any anticipated control mechanism. What gets omitted in the rational description of project control is nothing more or less than the spirit that really controls the effort.

Mercurial Control

Eventually, IBMs then-chairman Thomas Watson, Jr. gured out that NASAs Mercury manned space ights might well provide an opportunity for IBMs software to fail in too public a way. So he ordered a few of his cleverest eggheads to report to the project, to control software development and ensure a failure-proof result. The eggheads found the governments usual layers of controlling oversight. This being the early 1960s, it took about four months for a progress report to

elevate to the highest controlling layer, so Junes progress report needed to be produced in February to be delivered on time. The IBM team was inventing, not merely assembling their software, and the eggheads appreciated that they couldnt nely predict next weeks position, let alone four months in advance, so they spent a day writing a very special-purpose bit of software, designed to spit out a credible progress report, complete with randomly-generated small roadblocks and difculties Other teams working on the program spent about a week per month crafting their prospective progress report, and every team except the IBM team was waylaid at least once by well-intended controllers, further hampering their progress. In the end, the IBM software was delivered on time and avoided publicly embarrassing IBM. Projects are capable of controlling themselves, and most dance with their controllers to co-opt unnecessary intrusions. The feedback from the project to the external controller can become a form of control over the controller. Many successful efforts manage to succeed, like IBMs Mercury effort, by hoodwinking managements controls.

Conversation As Control

Life can only be understood backwards; but it must be lived forwards. Soren Kierkegaard

While the thermostat and the plan might well anticipate some control points, the conversation about the control effects the greatest regulation over the outcome. This says nothing more about closed-loop and anticipatory control systems than their most generous practitioners freely acknowledge. They are necessary, perhaps, but never sufcient. For effective control is unavoidably recursive, considering itself along with the system it intends to inuence. This conversational interaction effects control beyond what comparisons to any static metric, standard, or anticipatory control could ever produce. Where those who are project managing recognize this conversation as the source of control, uid adjustment replaces lagging mechanical measurement and corrective action. Those who are supposed to know better learn from those who arent supposed to know better, and all are wiser as a result. Control is achieved by unlearning. Whether that unlearning comes from a wakeup alarm or from someone awakened by their own inspiring insight before the alarm rings makes a real difference in the maintenance of ow through a project. The best control is that which requires no error to occur before adjustment of the course. Whether anticipated in the master plan or by the night janitor matters little. That unlearning is necessary to effect meaningful control matters most. We live forwards. Control must then mean something more than measuring against previous experience or deliberate anticipating. The scope might well shift and if we judge performance by how little we shift scope or how well we manage to sell each shift, well be controlling unnecessarily.

We control to maintain value, not simply to contain cost, time and quality. Full project controlling means engaging in continuous conversation with our projects, and its only conversation if we expect to be changed by what we hear. We can unlearn our expectations more easily than we can x any performance problem. Continuous improvement naturally involves endless unlearning. If we anticipate difference as error, were unlikely to maintain the ow and trust our projects need to produce real value. How curious that the PMBOK stands so silent and glaringly incomplete on the subject of conversation as control. In the next and nal installment, Play Ball!, Ill call upon the patron saint of project managing to consider what bodies of knowledge actually provide.

6- Play Ball!

We set out to learn the project management body of knowledge before learning that our projects communities are more knowledgeable and capable of guiding us than our earlier indoctrination acknowledged. And that our notions of what it means to play the project management game need some situated experience and a lot of unlearning before they do us much good.Then we start inventing games that work better for us than following the old rules ever did. In part one of this series, I presented ndings outlined in The Underlying Theory of Project Management Is Obsolete, a PMI-published paper by Lauri Koskela and Gregory Howell, who identied key theories underlying the PMBOK that inhibit project performance:The Transformational View; Management By Planning and Thermostatic Control.The paper claimed that these three tacit theories in action create self-inicted problems and I proposed that they require unlearning. Part two Seeing Different considered some inherent limitations of The Transformational View: that while useful for analysis, this perspective trivializes situated work and is difcult to see beyond. Part three, Dont Task, Dont Tell, evaluated Management By Planning, citing situations where management succeeded by other means. Part four examined the limitations of using Thermostatic Control to resolve The Control Dilemma and part ve introduced the concept of unanticipated controllers (Whos Managing Whom?).

In this, the nal installment, I discuss what we might reasonably expect from any body of knowledge, why they are necessarily incomplete, and how we might unlearn where we look for knowledge.

The necessary condition for assessing the value of creeds is that we should fully understand that they claim to be, not idealistic fancies, not arbitrary codes, not abstractions irrelevant to human life and thought, but statements of fact about the universe as we know it. Dorothy L. Sayers,The Mind of the Maker

Anywhere in the world, you can hear some form of the phrase, Play Ball! In the United States, we expect this phrase to initiate a game of baseball. In other cultures, it might herald the start of a game of cricket, soccer, football, rugby, basketball or any of hundreds of different games each with its own knowledge base, each featuring something labeled ball. Successful play in baseball requires more than raw talent, but a deep knowledge of the game. A successful cricket player will not necessarily make a successful soccer player, since the two games share little except that they involve a ball. But even what constitutes a ball varies widely across ball games. As an American, I nd cricket matches to be the perfect companion to a long afternoon sipping pints of Bishops Finger at The Old Doctor Butler's Head pub in Moorsgate, in the old City of London, though neither the afternoon nor my attention span will prove long enough to actually complete the match. Nor will my interest in the match spread much beyond my need to distract myself, though others in the pub will cheer and shout at actions I nd at best distantly curious, because I do not comprehend the rules of play. A colleague presented me with a book of cricket knowledge, but it proved indecipherable to me. Likewise, for those only interested in watching a game, books of knowledge hold little interest, except perhaps to second-guess an umpire. Most fans have never cracked any ofcial book, but assimilate their understanding of the game over time by watching others play it. The same holds true, it seems, for the curious game of project management if, indeed, project managing can be fairly characterized as a game. There are, among the many schools of the practice, different rules of play, and for any player, knowledge of the local customs seems essential. But if project management is a game, what sort of game is it? For decades, spectators might have agreed that project management is rather like the game outlined in PMIs PMBOK. Projects have, indeed, been thought of as sequential input-output processes, and managers have been expected to manage by planning, and control has been rmly believed achievable thermostatically. In more than just recent times, our trusty old baseball game has sometimes appeared in more soccer-like forms, as those touted by the Agile movement, scrums and all. And the rules of play, which used to seem to fairly characterize the game we engaged in, have become noticeably incomplete to universally guide play. Much of the fury of the theological wars surrounding the proper body of knowledge upon which to base the game of project management carries with it unspoken assumptions about what constitutes not valid play, but a valid game. Those who focus upon conditioning relationships, rather than delineating inputoutput processes, have been called misguided. Those choosing to manage without creating a critical-path schedule have been seen as lazy or amateurish, rather than innovative or properly adaptive. Those ceding control to their projects have been labeled unprofessional.

But I believe these and many other unblessed choices are valid, given the contexts within which these curious players play their bafing ball games. Perhaps a pint or two of the Bishops Finger would help speed a knowledgeable professionals unlearning of how ball games are supposed to be played. Few have investigated without preferring specic rules of play just what games are played when different organizations engage in managing projects. In absence of such impartial judges, the consensus opinion of the expert, but far from impartial players, results in a body of knowledge that distills to nothing more or less arbitrary than the rules for playing any game. Why is it three strikes and not four? Why three outs and not two? Over time, the formal rules have evolved into a more-or-less static set, though the National and American leagues cant quite agree on the necessity of the designated hitter rule. Some will argue that their rules are far from arbitrary, that they delineate the true and natural way of playing the game gleaned from decades of experience, embodying the best of the best practices. The old-timers, like my 85year-old father, disparage the slovenliness of todays players while acknowledging that even Manny Ramirez plays an excellent game. Not quite the same game he, himself, played in his prime, but then, part of his game involved clearing the cow ops from the outeld before commencing play; quite a different game than those played most places today. And the ofcial rulebook says nothing about the proper response to a grounder drilling through a cow pie. Is that interference or just a feature for the elder? Just how universal is PMBOK? This book of knowledge opens with a statement that claims it is the complete body of project management knowledge, an assertion that discredits whatever follows. For even expert ball players understand that their specic brand is nothing more than a small island in an ocean of possible games. If a project manager works within a single, mature monoculture, he might well mistake his experience as somehow universal. For any homogeneous group, their individual experience might well map similarly. For the rest of us, those working in a variety of cultures and expected to play many different project games, our experience varies as much as the shapes of the balls we catch or kick or nudge out-of-bounds when we play our various games. In my 30 years of project work, Ive not seen two organizations who dened projects or project management in the same way. Curiously, most of these organizations believed that they were following one-or-another best practice, while actually dening and playing their own, unique game. To the extent that they believed their book and not themselves to be the creator of their approach, they were pretty universally hobbled, because they seemed to need to unlearn what they believed they knew before they could respond as their unique, unanticipated-by-Hoyle game demanded. Sometimes this hobbling took the form of a spirited argument over what was implied from what wasnt specically denoted. Others, a forceful plea for leniency when an irrelevant rule was broken. Mostly, these arguments were misplaced, focusing upon the rules for a game not actually being played. Behind these disagreements rested a rmlyheld, but essentially bogus assumption that they knew how the game was

supposed to be played, and it wasnt being played right or an equally delusional faith that if only they played by the rules, they would somehow win. One of the reasons I dont consult with many government projects is that, to my mind, they play a very primitive form of the project management game. For this same reason, Im very careful about whom I work with in big business, too, so I can avoid engaging with Big Dumb Companies. Government agencies and BDCs, in my humble experience, most often imprint upon one-or-another body of knowledge and enforce compliance with brutal, often self-destructive force. This, of course, ensures that the umpires can consistently call strikes, but it results in fairly unproductive play. There are good reasons why this is the case, and better reasons why an organization might want to choose differently, but such arguments are lost on those who rmly believe that they have acquired the knowledge necessary to win their game and especially for those who believe that their knowledge of how the game is supposed to be played amounts to much more than a hill of beans on this latest playing eld. In this culture, we have learned that we possess knowledge like we possess wealth. It is property for us, as if we could trade what we know for what we want. But knowledge neither appears nor is it exchanged as a coin might be acquired or exchanged. My personal body of knowledge is, quite honestly, disembodied. So is yours. So is PMBOKs. There is no denable place where knowledge is stored in any brain, so our metaphor for knowledge as embodied seems as incomplete as our bodies of knowledge inevitably prove to be. A simple thought experiment illustrates this point. Imagine seeing someone vaguely familiar, only to recognize after a moment or two that this unfamiliar person is your neighbor. But you encounter this familiar person in an unfamiliar place, perhaps at the dentists ofce rather than over the back fence. The different context renders momentarily useless your usual knowledge about your neighbors identity. The same holds true for all knowledge: it is tenaciously context-dependent. What we assimilate when cramming for an exam is not so easily conjured up when surrounded by a real-world crisis. What we know worked last time doesnt apply very directly this time, for knowledge is situated. If we believe that one project is very much like every other project, then we probably believe that our knowledge from then is well situated to inform us now. I see more aspiration for one project to be like another than I see real similarity, though the desire to somehow enforce a single context upon projects is at least as old as the metaphor for them, which says that projects are just a one-off form of operations/production management. The patron saint of project managing was also one of the founders of the Greek School of Skepticism, Pyrrho of Elis. Interestingly, he is also characterized as one of the fathers of modern scientic thought. Pyrrho noted that the same things appear differently to: different individuals and senses, to the same sense in different conditions, in different positions or places, in company with different things, in different quantities, in different relations, if common or rare, and to people with different customs or ways of life. Thus, Pyrrho claimed that any statement about anything could be matched with an equal counterclaim, which might account for the wide disagreement about the assertions of PMIs body of

knowledge and also why so many organizations expend so much energy encouraging a monocultural perspective on their projects. If the body of knowledge doesnt embody the knowledge about managing projects, what does? Like with our brains, this highly specialized, situated knowledge is stored in a variety of places: Partly in the organizations memory and in our own; in what weve done and in what were trying to do; in books and brains and behaviors. And in none of these and all of these. Mostly, it seems to me, its what we dont know yet that really makes a difference. Projects are about discovery, not simple assembly. Discovery demands unlearning. What game are you playing this time? If youre well-trained in PMBOK, youre likely to consider this one to be the perfect context for employing PMBOK.Your project will, if you pay close attention, teach you just how right or wrong your assumptions are. Then, unlearning project management will take on real meaning.

Complete Incompleteness

Whatever one might say in support of PMBOK, it is obviously incomplete. This conclusion does not argue for an even more co