"A ruler with .1cm ticks is only good to .05cm. Any measurement
can be off by that much. There are similar, well-known limitations to the
precision of numbers as represented by computers. I think we could
develop this in terms of human perception somewhat. If short-term memory
holds "The Magic Number Seven Plus or Minus Two" discrete values, the error
is half that, or 1/14 the range of whatever we're talking about. If it's
a schedule of around a year, I'd be very suspicious of any refinement under
a month in duration, just because people have trouble with that kind of
discrimination."
James Bullock
This rant is the transcript of a series of email dialogues between me and
James Bullock of Rare Bird Enterprises. jbullock@pipeline.com
I don't always agree with James but I love ranting with him! Warning: This
gets pretty deep at times, bring your waders and enjoy. david
The Trip We Took
David
May I publish this letter as a rant? This is exactly what I intended when
I suggested that you might rant in my space. What says you?
James
I think the power of our project conversations comes from the interplay.
Let's take your reply to me, and jiggle it a little. Let _that_ be the
rant.
We've got mostly similar conclusions about how projects work. Our backgrounds,
talents, and biases are sufficiently different that we come at a problem
from different directions. It's often illuminating. I find great similarities
between my conversations with you and my conversations with James Bach
- for the same reason.
There are several messages in doing the rant this way:
- The dialog itself is an exploration: an
example.
- It will show terminology / definitional disagreements:
places where we agree but think we don't because we are using words differently.
It's better, and shows that collaboration usually does better stuff.
David
I like this idea even better. You go ahead and take the first shot at this.
Statistics of Pert / Gantt Planning
EDITOR'S COMMENT: Much of this rant responds to a build from pieces in
True North's latest Compass newsletter. If you'd like a copy of it, just
ask by sending a request to tn@ix.netcom.com. We'll send a .pdf copy on
to you.
James - I
Dude!
Nice newsletter, as usual, but you've over-stated the results of Dr.
Gray's analysis a bit, I think. If the idea is to find the end date, for
sure, PERT / Gantt planning is foolish for projects with unknowns. But
so is anything else.
David - II
Actually, if the object is to "find" the end date in these situations,
the result must be absurd because there is no end date to find. The object
might be to determine the end date, which might come from anywhere. A simple
statement of "This is when I'd like to end," is useful, probably more useful
than poking sticks in the dark to see what's there. The absurdity starts
with the premise that there is a "scientifically determinable" end date
"out there." There is not. The quantifying blanket blinds many, however,
to the fact that their schedule tool has to be lying to them (actually
they are forcing it to lie to them.) The product looks real and finished,
even though it isn't...
James - III
You're talking about defining an outcome, not a process. Declaring when
you'd
like to be done is the same as declaring the intended deliverable (for
software it's usually the requirements) or the official methods to be used.
In fact, most of my projects have actually had a defined deliverable -
a collection of requirements that had to be met (usually because of totally
extreme secondary costs). Then you do what it takes to meet those requirements.
I get particularly annoyed by people who complain about the deliverables
and the dates, but go absolutely nuts if you want to change any of the
methods. In fact, as the processes (methods) for developing software proliferate,
with things like extreme programming, clean-room techniques, rapid prototyping,
spiral methodologies and so on, planning prescribes a triple: methods,
deliverables, and resources (time is the big one). The question is "Which
do you care about the most?" Specifying all three, precisely, in the face
of unknowns produces an over-construed system. It's at least as powerful
to specify which ones you don't care about very much.
Good, Fast, Cheap - Pick any two.
Humor is based on the sudden perception of incongruity. There's truth
in humor because one or the other perception is wrong: either what you
though is funny because of the truth of the joke, or the joke is funny
because it is often mistaken for truth. Good, Fast, Cheap is just another
form of saying: "This is an over constrained system."
The Death of Project Management
James - I
As for the death of project management, what has died in my estimation
is foolish and ineffective project management. The whole PMI dogma - camp
was profoundly flawed from the beginning. Much like the SEI, they got a
hold of a piece of the truth, and decided it was the whole thing. Happens
to people a lot with their first clue. Some of them never get over it.
Shooting up the PMI approach as representing "project management" is shooting
a straw man, just as shooting up the predicted end date is for PERT planning.
David - II
Well, it's going after a straw man for you, but not for many. I'd say that
the number one "project management problem" I see in organizations is the
wholesale consumption of the dogma. Perhaps it is as some suggest, that
an organization must embrace the "certainties" and find them wanting before
moving on to accepting more organic strategies.
I met Friday with a company that seems capable of embracing organic
without first impaling themselves on the orthodoxy, but this is rare. Most,
I find, when experiencing the shortcomings of the orthodoxy, do even more
of the same. My first intervention strategy with most is simply to break
this self-reinforcing cycle, to disrupt their insistence upon consistency
James - III
Different problem domains optimize at different trade-offs between repeatability
and adaptability. Highly exploratory projects don't work with rigid processes.
Projects with huge secondary costs don't work with exploratory approaches.
It isn't so much that the techniques are invalid, but that they are
being pushed to a precision that this project won't tolerate. I think any
"planning" method would fail in the cases you describe, not because the
method is wrong, but because the people involved insist on a predictability
that isn't there.
James - I
The entire premise of this style of planning is that stuff can be known
ahead of time. Of task duration are only one kind of stuff that is treated
as known, but isn't really. The task list (WBS) is another. It's like they
never heard of game theory: optimizing outcomes with incomplete information.
Deferring commitments is a common strategy. It's why betting a bit at a
time is interesting in poker, or the doubling cube is interesting in backgammon.
The problem with PMI isn't too many mathematicians; it's too many accountants,
dammit.
David - II
Exactly, and many organizations don't want project leadership, but project
accounting. I'd won't bore you with the bloody details, but you've stated
it perfectly. They have accountants because they want them. Spoiled might
be the best term for them, expecting to leach out the risk of new endeavors
by encapsulating them in a security blanket. They tend to get better accounting
then products but then they are measuring the accounting, not the often-intangible
product. Besides, the trance works both ways. The accounting can work and,
if that's what you're measured on and it works, it's not even the project
manager's fault when the product falls short of expectations. Did someone
say, "CYA?"
James - III
Well, I've pulled the "Denial of Chaos" part out of the Project Uncertainty
Principle draft that I sent you a while ago. I think the psychological
process stands on its own, and would make a good piece or Sue Petersen's
new department in the Imprise developer's magazine. We're talking about
the same process - demanding an unjustified precision in prediction. We're
also talking about project uncertainty models.
The Issues System
James - I
I'm surprised you didn't go after some other issues with their methods.
Biggest problem I had with PMI style project management is the definition
of an "issue", and the related "issues process". An issue had to relate
to a task on the project plan, and the "issues process" drove resolution
- defined as a decision - in a timely manner. Things not resolved fast
enough were escalated to another level of management to "decide."
What nonsense. What if the issue was something that wasn't on the plan?
What about an issue that remained open, and ought to remain open? How about
intentionally deferring decisions: planning around what isn't yet known
to buy the maximum possible time (and information if you do it right) to
inform a decision?
David - II
Another and perhaps more subtle point in there. Yes, there are an array
of strategies for "dealing with" problems. I'm particularly interested
in making them moot, in finding a solution rather than in solving the problem.
The difference is striking. Often, a problem solving orientation leaves
one poking around in the past, trying to fix something there. Since we
can only really act upon the present, this strategy is often ineffective-
and frustrating.
My best current example of this "solution finding" is a story
from Japan. An old man is tending a rice field when he notices a tidal
wave approaching his village, which sits a long distance below him along
the shore of a bay. He cannot possibly run to the village to warn his neighbors,
nor can he make a noise that will catch their attention. He is powerless
to solve the tidal wave problem, so he lights his rice field on fire, which
brings every villager to the hilltop to save their crop, thereby saving
them from the tidal wave.
A problem solving strategy seems to always miss the "let's make this
problem moot" approaches... This is for a later issue.
James - III
I've used, "Let's not." as a technique both as staff and as a consultant.
Delivered at the right time, that bare statement can sometimes shock people
into some more open thinking. I also reframe this kind of stuckness using:
Issue -> Goal -> Options -> Problem -> Solution
The issue is the old rice farmer was unhappy with everyone in his village
drowning. The goal is to allow them to survive the tidal wave. He improvised
by seeing a different option, take the mountain to Mohammed by making the
mountain want to be where Mohammed is. At least three unconventional insights
in his process.
If the Tail were Smarter it Would Wag the Dog
James
I'm surprised you didn't harp more on the primacy of observed phenomena.
The problem isn't that "planning is bad" but that "insisting that the plan
is right and reality is therefore somehow wrong" is bad. Here's a quote
I came across, and thought of you, even before I got the newsletter:
"Here lies the essential point; from her scientific preparation, the
teacher must bring not only the capacity, but the desire to observe natural
phenomena. In our system, she must become a passive, much more than an
active, influence, and her passivity shall be composed of the utmost scientific
curiosity, and of absolute respect for the phenomenon, which she wishes
to observe. The teacher must understand and feel her position of observer;
the activity must lie in the phenomenon" - Montessori
The problem comes, I think, when a project "plan" as in a prescription
for action, is combined with Taylor-esque, "scientific management" assumptions
and organization. The manager tells the subordinate what to do. Complete
knowledge is possible and embodied in the manager. Deviations from direction
are flaws in the worker. Since the manager develops the project "plan",
it is treated as direction, if it is interpreted in a Taylor-esque style.
David - II
Yes, again exactly. Taylor's biography is very interesting. He really saw
the world as needing a strong father to guide it away from the naïve
errors of its native ways. The fact that his model for a healthy father
figure matches our present idea of a compulsive adolescent is no accident.
Taylor would be institutionalized for obsessive-compulsive disorder today,
yet his model is still held as an ideal and as a target.
Planning is certainly not the enemy, I think the insistence upon certainty
might be.
Certainty, and you may have heard me rant on this before, is a poor
precedent for confidence. If you have to be certain first (or be fooled
into believing you're certain), the result isn't really confidence, anyway...
James - III
Maybe we just shouldn't let functional managers do the planning, so they
don't get confused about what is direction and what is prediction? Perhaps
this is why team based or team vetted planning tends to work out better.
There's all kinds of press about the brilliance of groups and so on. Maybe
it's as simple as the people doing the work keeping the directive folks
honest?
James - I
Do you remember _The Hitchhiker's Guide to the Galaxy_? When deep thought
is constructed, the union of Philosophers, Theologians, and other thinkers
of big thoughts demand rigidly defined areas of doubt and uncertainty.
I think I do too, actually.
General Theory of Unknowns
James - I
I'd like to pursue a "general theory of unknowns" at some later time. I
came across some useful ideas that I haven't integrated yet. Conservation
laws apply to renaming systems, which are really just remappings. Comes
from the general systems literature.
Now I've got to translate that into useful language. It's the essence
of the second point in my draft of the"Project Uncertainty Principle" -
unknowns are conserved, they just get renamed. Believe it or not, you're
the best candidate test audience I have for this. It takes some ideas you
like into a different space. If I can reach you, I can reach pretty much
anybody. (Jerry, for instance, I could get this through to in about 5 minutes,
if he was in a listening mood.)
David - II
I'd like to do this, too.
James - I
My particular (peculiar?) background allows me to be comfortable with logical
methods, numbers, and so on, and to maintain a grip on how little we know.
Did you know that every proper calculation in engineering includes a precision?
It's one of the first experiments everyone does: measure something several
times, and note how different the answers are.
David - II
How do you know what you don't know?
James - III
To begin with, there is intrinsic error in the representation. A ruler
with .1cm ticks is only good to .05cm. Any measurement can be off by that
much. There are similar, well-known limitations to the precision of numbers
as represented by computers. I think we could develop this in terms
of human perception somewhat. If short-term memory holds "The Magic Number
Seven Plus or Minus Two" discrete values, the error is half that, or 1/14
the range of whatever we're talking about. If it's a schedule of around
a year, I'd be very suspicious of any refinement under a month in duration,
just because people have trouble with that kind of discrimination.
The cognitive scientists ought to be finding us fundamental performance
numbers on human cognition, like this 7 + / - 2 number. When working with
SWAGs (Scientific, Wild Ass Guess) we're limited by the tool: what the
human mind naturally tends to discriminate.
Things like the mode / median preference in estimating from Dr. Gray's
paper is another example.
In physics, entropy is based on the number of states available, and
the distribution of actual values among those states. You can treat the
whole system as a collection of little bits with individual states. I wonder
if there isn't an analog with the many discrete bits of a project which
have a state space. Bulks of chunks can be dealt with statistically. This
is what bulk models in physics and chemistry do.
Individual chunks can be dealt with discretely. We're pretty good at
that too. The transition from discrete models to bulk models comes at around
10,000 molecules if you're talking about aerosols (with many disclaimers
and fudge factors on that number). The interesting part is the transition
from discrete to bulk phenomena - the molecule is neither isolated, nor
engulfed. Sounds like most project tasks.
Looking at meaningful projects, it's interesting to me that they often
have on the order or 10,000 things in them, by the time you count everything
up. Projects seem to be on the cusp between discrete and bulk models (at
least a lot of the time). That would mean use whatever model works, and
don't trust any model too much. But that isn't a problem with models. The
models available are being applied out of their scope in most projects.
That's the big mistake.
David - II
Good paradox here. How do you know what you don't know-- and can you? I
think the worst plans are the ones that assume they know what they need
to know both knowns and unknowns. Better ones assume that there's something
significant missing. The best acknowledge that they could not possibly
know what or where this missing stuff is (yet).
James - I
Actually, every time I hear someone talk about "Software Engineering" in
terms of absolutes, I'm struggling not to laugh out loud. They're just
showing how little they know about engineering, and software.
David - II
Yes, exactly. Although some engineering is more focused upon absolutes
than others. In general, an engineering lab is a messy place. Manufacturing
engineers are much more absolute mind-setted than are electronic engineers,
but like religion, engineering is interpreted in many different ways, I
have met many engineers who feel their experience should be more predictable
than it is, and they drive themselves crazy with these expectations.
James - I
The problem isn't "models are bad" it's "badly used models are bad." and
in part "Bad models are easy to use badly." Specifically about projects
"Models that suggest false precision are bad." and "Models that encourage
belief in false precision are bad." I'd be interested in finding models
that are harder to abuse.
That said, that's me, not you. "Project Community" is a more honest
name for your focus and interests, I think. I'm intrigued enough that your
workshops are on my: "Go Do This" list. Meanwhile, I'd like to equip these
powerful project communities with lots and lots of metaphors and even a
few models for projects - tools to think with. I've also been part of (small)
project communities that sneered at much official dogma, charging forward
successfully under the banner: "Do what works."
David - II
This banner can also be paradoxical, since "what works" is tenaciously
unpredictable. How about "use your collective judgment?" What works won't
work sometimes but it will still be working toward working if this can
be acknowledged. I know you didn't mean this, but I often see teams so
focused upon avoiding making mistakes that they cannot learn and they cannot
talk about what's really going on, while spinning everything into some
representation of "working" ... Yawn.
James - III
"Do what works, this time?"
Note that I think the appropriate (as in effective) metaphors &
models change with the level of uncertainty. That's a draft paper I'm working
on.
Cognitive Coherence
David - II
Models are essential. The primal issue is probably how we determine which
model we will use. PMI is remarkably silent on where this cognitive coherence
comes from, as if plunking down a "plan" would achieve common Gestalt.
The father knows best school says that the project manager creates the
model(s). The project community approach says it's always a blind men and
the elephant process. If each blind man cannot find his piece within the
whole, the whole suffers. Assuming any blind man has better perspective
than any other is equally dangerous. Assuming that each must understand
all is also dangerous.
That this essential, coherent Gestalt is emergent from the community,
I think, is inescapable. I think where the orthodoxy gets tangled is in
their attempt to close systems that must be open to work. In closing these
systems, they create most of the problems their techniques attempt to "solve."
It doesn't make any sense from the mechanic's (notice how close this word
is to maniac... similar root?) perspective to open a system that should
be controllable. The largest opportunity they forfeit is the power of equifinality
- the capacity to succeed in a variety of emergent and unforeseeable ways.
They trade away potential for the illusion of certainty.
James - III
I particularly like your use of the blind man and the elephant. Assuming
that any one description of the universal is fatal. But each blind man
has a better grip on his part of the elephant than anyone else. They don't
succeed by averaging their diverse experiences into some bland whole: part
tree, part snake, and part wall. They succeed when they incorporate their
divergent visions into a rich whole.
One hidden assumption of the "manager as director" model - only the
manager takes in true data about the problem at hand. It seems the people
doing the work have eyes enough to see where they're shoveling, but not
enough vision to see anything else.
David - II
Ever notice how few stories about how projects actually work ever get published?
Wonder why? It's because they actually don't work, or, at least, they don't
work as expected. The messiness is buried and forgotten rather than embraced
because all of the analysis of these past experiences can only lead one
to the conclusion that the predictive models don't work to predict the
experience, and we lack a place to put this knowledge. So we predict and
bury endlessly.
James - III
I'm guesting in James Bach's "Software Realities" column next month. Feeling
pretty good about that. "Software Realities" is exactly about how things
really get done. My piece is on the development system. But there were
two more that didn't come together as fast. One deals directly with multiple
project models, and the other deals directly with uncertainty in projects.
It's all about how projects really work.
Maybe that's the name for the project models book I'm trying to write:
"How Projects Really Work".
A New Name
David - II
All in good time. I am repositioning my business away from project management
because the premises of that orthodoxy are so absurd and because when I
announce that I'm in the project management training and consulting business,
people go there, to a place where I have to chisel them out before we can
do anything meaningful.
James - III
Well, while you've chosen to name your work differently I'm not there yet.
It may be my need to tilt at windmills. But when I look at the fundamental
definition of project management I find:
Allocation, and direction of resources to achieve an end (management
according to Drucker, and Rand - an interesting pairing), and An activity
undertaken to achieve a unique result (from where?). The current practice
may say "use a Gantt Chart" but the fundamental definition says no such
thing. It says allocate and direct resources to get some thing unique done.
Equating that with the PMI techniques is just silly. First they're just
one option, and second they don't work a lot of the time.
I have the same kind of argument about testing software, most of the
time with Dr. Beizer. He asserts a lot of things about "majority practice"
when it comes to terminology and so forth. I have no compunction about
flying in the face of "the majority practice" terminology if majority practice
is in fact a corruption of the language. Everybody saying: "Slavery is
Freedom" doesn't make it so - ask George Orwell (Politics and the English
Language should be required reading for all aspiring project leaders. I've
had many an interesting conversation by asserting just this.)
I see both the PMI approach and some testing advocates exerting great
effort to define useful stuff that they don't agree with out of the world.
Rather than define the world of projects as the world where PERT / Gantt
charts accurately predict resources and end dates, where issues get resolved
just by someone deciding, where predictability is king, let's admit that
"projects" are anything we do to produce a unique outcome, and "project
management" is applying resources to do that. More often than not, uncertainty
is the defining issue in a project.
Yours in uncertainty (which means I've got a grip)
David - II
A great grip! We live in a world where we get absolute responsibility and
limited knowledge. This is a most interesting combination. It means we
must act without really knowing. It means that knowing cannot be the point.
|
