Hurray for Real Time Management! LO13131 -Joe's Jottings #71
Thu, 3 Apr 97 17:23:52 -0800

Bo Davis, a friend and colleague in HP's information technology community,
has long complained about our chronic inability to manage projects and to
learn collectively from our often-repeated mistakes. He feels very
strongly about correcting this, and he is focusing his time now on
promoting the use of an internally developed Lotus Notes application
called the Project Manager Assistant that makes it easy to do a good job
of managing and documenting a project. Bo's efforts are slowly paying
off, but he feels like he's pushing a rope most of the time.

But Bo enjoys fighting windmills; he seems happiest when he's on valiant,
idealistic quests. So I was a bit surprised when Bo exploded into my
cubicle a few weeks ago telling me that he now understands why his task is
really impossible. He just finished reading _The Stuff Americans are Made
of_, by Josh Hammond, and James Morrison (which, by the way, has a nice
introduction by HP CEO Lew Platt). Hammond and Morrison say that we
Americans have some cultural characteristics that differentiate us
strongly from people in other countries.

That statement is no great surprise, but Hammond's and Morrison's points
are a bit embarrassing. Here is Bo's paraphrase of their list of American

1. Insistence on choice

2. Pursuit of impossible dreams

3. Obsession with big (the book calls this chapter, "Big, Bigger, Bust")

4. Impatience

5. Acceptance of mistakes (the chapter title is "Fire, Ready, Blame -
Trying to Do Things Right the Second Time)

6. Urge to improvise

7. Fascination with what's new

Bo says that traits 1, 4, 5, 6, and 7 make a repeatable process culturally
almost impossible. Do you agree?

Let me make this discussion more specific to HP. I meet often with
external customers. Occasionally, they ask about how we manage projects,
assuming that we must be really good at it. The conversations go
something like this:

Customer: "How do you identify your projects so that you can collect all
costs and benefits and calculate an accurate return on investment?"

Joe: "Uh...well, we give them names, like Snakes or Redwood or Tahoe.
Our accounting systems can track location codes, so if the project happens
to coincide with one or more location codes, we get project costs. But
mostly, the project manager just tracks costs on a spreadsheet. And, even
then, we don't usually closely relate implementation and support costs to
a project. Those costs often get mixed in with legacy systems support, so
getting ROIs for a specific project is really a work of art."

The discussion continues like this for a few more minutes, and the
customers get that, "This bee can't fly," look in their eye.

But, of course, the HP bee does fly, I'm happy to say, and I've come to
understand that part of the reason we fly so well may be _because_ we're
lousy at project management. Instead, we manage everything as on-going
business. The targets may have been originally set considering projects,
but actual costs are managed in real time.

IT spending is a business decision made by the business managers. We
expense things as we go and match those expenses to revenues every month.
If business is good, we tend to get a little sloppy and spend a little
more on whatever; e.g., people, convention trips, off-site meetings. If
times get tough, we tighten our fiscal belts. Managers make priority
decisions on what to spend based on the current situation. They are not
locked into project plans that were made in an entirely different business

That flexibility is important even if there aren't any significant shifts
in spending climate. We actually do a pretty good job of planning
projects. Most IT projects go through some form of "launch" based on the
Ernst & Young Navigator (TM) methodology. But, as we all well know,
specifications and plans change, a lot. And those changes inevitably have
effects on spending.

In tightly controlled environments, each significant modification
generates an "engineering change order," and the formal plan is
appropriately modified. All that accounting, when done properly, creates
a lot of overhead. We skip all that by adapting our work to the current
needs of the projects' customers on an on-going basis. When the project
is done, it usually has the capabilities that the customers want at that
time, which may be really different from what the customers said they
wanted when the project started.

Hurray for real time management!

This same idea seems to work as well for teams. Some of you may remember
Jottings #32 that discussed Michael Schrage's book _No More Teams!_.
Schrage suggests flexible collaboration rather than having designated
teams. Along the same lines, I just heard author/consultant Richard
Whiteley at a Customer Work Innovation Network conference. One of his key
strategies for "customer-centered growth" is to move "from teamitis to
universal collaboration."

Whiteley says that there are seven pillars of universal collaboration:

1. Overarching purpose (e.g., vision, mission)

2. People involvement

3. Internal customer process

4. Development of collaboration skills

5. Positive team environments (that allow the formation of _ad hoc_

6. Organizational structure (that allows work to be done informally)

7. Infrastructure (that allows people to work across the organizational
white spaces)

Again, in HP, we tend to focus more on individuals than on their teams.
For example, we have experimented with but never institutionalized team
compensation. We encourage the formation of teams as needed, but even
designated project teams tend to be short-lived and break down as
situations (rapidly) change.

To paraphrase Eisenhower's famous quote on plans, teams are nothing, but
teamwork is everything.

This gives us great flexibility, but at a significant price. Teams don't
stay together long enough to learn and get better as an intact group. We
have to go through a "forming" process each time we start a new project.
We may repeat mistakes, but we also don't carry forward previously good
ideas that don't apply to this exact situation.

Again, hurray for real time management!

Is all this HP "stuff" true because we're a company that started in
America? I'm not sure. I see these project and team traits in all parts
of the HP globe. I think it may have more to do with our "value
discipline." In Treacy/Weirsema terms (see Jottings #21), HP might again
be demonstrating its primary focus on "product leadership" rather than on
"operational excellence," our tendency to do the right thing even at a
cost of some efficiency.

What do you think? Should Bo continue his joust with project management
windmills or find some other less daunting task? What examples do you
have of projects and teams that have succeeded, here at HP or elsewhere?




Learning-org -- An Internet Dialog on Learning Organizations For info: <> -or- <>