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.
Re-purposing
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.
Anticipation
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