I've been out of the office for most of April, so I'm just getting back to
the important things ... like the Jottings.
Here are comments that came in on Jottings #71, Real Time Project
Management
Joe
-------------------------------------------------------------------------------
Jottees,
Hmmmm.
Real Time Management.
Sounds like a new buzz word for that age old idea, seat-of-the-pants
management. Is this an acknowledgment of the evolutionary theory that
adaptability equals survivability, or just an attempt by some board and
frustrated MBAs' to rationalize why small upstart companies will always
out-perform large organizations in the short term?
As an employee of a recent HP acquisition, I quickly realized what has
made HP successful in the long term. From the corporate level, it isn't
real time management, but hands off management. Real time management is
what drives the success from the local/department level. In the three
years that HP has owned the CERJAC Telecom Operation, the following has
changed;
1. our benefits package
2. where our paychecks come from, and
3. we all got nice new HP PCs.
Of course, we were all very afraid of the spectre of corporate 'Big
Brother'. Some of my co-workers developed a short-lived mantra "Conform,
Obey, the HP Way" which disappeared shortly after we realized just how
much autonomy we were being granted. It is just this autonomy, I feel,
which has given HP the ability to keep up with and even stay ahead of our
competitors. It is as if I still work for the upstart, with the ability
quickly make corrections and adaptations in response to an exceptionally
transitional market, yet I have the corporate resources at my disposal in
order to make sure that those corrections and adaptations will occur.
However there is one major issue that must be constantly addressed.
Quality.
Not just the quality of the product, but also the quality of the process.
As an organization grows, it becomes more likely that some aspect of
development or manufacturing will fall through the cracks of a process
that has failed to keep up. In large organizations, this problem has been
minimized by Process Standardization. However, the major problem with
standard processes is the inability to adapt to change. The large company
with a standardized process cannot release new products or features
without a Herculean effort to change and document all of the processes
involved with the release (per ISO standards). The small company may blast
a new product from design to shipment in as much time as it takes the
large company to finalize the design review process. Once again though,
quality is the victim. Is it better to get a new product to market quickly
through a streamlined (read: inadequate) process and risk product
integrity than to miss time-to-market in an effort to make sure that the
product meets all quality standards? In industries where quality standards
are pre-established (aerospace, medical) the risks of an inadequately
tested product can have profound ramifications. All of this plays right
into the hands of Bo Davis. As the divisions and departments in large
company exercise the autonomy necessary to maintain market share, the
inherent lack of communication virtually ensures that the mistakes made by
one development team will be made another. Thus, the key to long term
success in an autonomous environment is communication. Share your
information. Get out of your cube once in a while and see what your
co-workers are up to, but watch out, you just might learn something
useful. (Godspeed, Bo!)
James Carrington
Manufacturing/New Products Group
CERJAC Telecom Operation
Westford, Massachusetts
----------------------------------------------------------------
Subject: Re: Jottings #71-Hurray for Real Time Mgmt [00002-17582]
Author: HUDI PODOLSKY at HP-PaloAlto,om13 Date: 4/4/97 8:14 AM
On the list of American traits (which I think is quite accurate) you
have ignored one, the obsession with the big. I think it's that trait
that fuels the ongoing interest in project management, and warrants
Bo's continuing his quest. We fall in love with BIG projects. And if
we were ever actually going to get them done in an orderly fashion, we
would probably need great management tools and great teams. Someone
(thank you Bo) has to keep reminding us what it would take to really
do those things. We can then look at all that discipline and say, oh
heck, let's just do a little piece of this thing quietly off in a
corner and we won't have to get good at project management. If Bo
wasn't out there telling us what it takes to do the big ones, we would
probably be fooled into thinking that we could more often.
We are, as the second item on the list points out, prey to impossible
dreams. And one of the "impossiblest" is that we can do big projects.
While I think we need big vision, I think that,in our environment,
big projects are mostly a bad idea. Yes, a worldwide knife edge roll
to SAP would be really cool in theory, but it's so high risk that it
would take us so long to plan for it and would require such massive
control that we'd all be dead before we were ready to implement.
Unlike the ancient Egyptians, we cannot count on our descendants to
pick up the project where we left it. What we can count on is some
fast and loose little entrepreneur to eat our lunch while we're making
sure that everyone, worldwide has agreed on which fork to use and is
prepared to lift it at the same time.
What our values do is help us chart a reasonably sane course through
our conflicting desires for impossible and big on the one hand, and
individually chosen, new and improvised on the other. Our values give
us the touchstone. If a big project requires so much bureaucracy that
trust and respect will be lost, our values remind us to just say no.
If an improvisation creates a safety risk for our customers, our
values rein us in.
The real systemic change that's trying to happen in our schools is a
shift in values. We are trying to shift from respect for formal
authority and faith in certainty (in grown ups who have right
answers), to respect for competence and faith in our ability to keep
learning (in a collaborative learning community).
Hudi
-----------------------------------
Joe,
Another fine mess is just fine? Well, you've churned my brain again,
and there is some synchronicity with recent work...
In the new process management training we're doing (in which project
management is seen a variation on the theme), we recognise that
different processes require different degrees of structure. Some
bottom line rules:
1. Decide on what you will promise your customers, based on their
needs and your capabilities.
2. Set 'thin standards', being those minimal, necessary and sufficient
things that must be done to meet promises.
3. Have 'fat guidelines', which are anything and everything that will
*help* the people in the process achieve the promises/standards. It
includes process notes, lists of phone numbers, IT systems, etc.
4. Try to spot risks ahead of time. Reduce or eliminate them. Have
contingency ready, as appropriate.
Regards,
Dave Straker (HP UK Sales Region)
--------------------------------------------
Joe, I wanted to take some time to think about this jotting, and it
has triggered lots of reflection and research on my part. Thanks for
sending out such a provocative item! Here are some thoughts and
experiences...
I share Bo's predisposition toward tilting at windmills. That's also
an American trait, I think, but it's stronger in some people than in
others. I have observed many of the other cultural traits you listed,
and they are frustrating to lots of purposes, including
standardization and project management. I do agree that a repeatable
process is almost culturally impossible, but I'd like to share a
slightly different rationale.
There is a very interesting paper I read two years ago entitled, "Team
Tools for Wicked Problems," by Dr. Michael Pacanowsky. Michael was,
at the time, a professor of communications at Colorado University and
a consultant to Gore. His paper, which was in the American Management
Association Journal, was based in part on experiences he had while
working with us. Michael is now a Gore associate (our word for
"employee"), and he and I work together on many projects. The point
of his paper is that many problems and projects we face are "wicked,"
i.e., they not only defy solution, they almost defy description. If
you think about it for a minute, you'll probably recall many
situations you just can't "get your brain around." These are wicked
problems. They are, by definition, not repeatable, and the
information you require to solve them one time around may be
completely irrelevant the next time around. You have to approach
wicked problems with a completely different mindset than with "tame"
problems (those with a known, set algorithm for solution).
Instead of solving wicked problems, you design solution frameworks for
them. These frameworks need to accommodate the input of many
different people and the influx of knowledge from multiple sources.
They need to be flexible, responsive, and readily adaptable. A wicked
problem framework might involve elements of organizational design,
information technology, team behavior, team process, and project
management. The point is that the team (loosely worded; I'll come
back to this) must be able to process information quickly to gain an
understanding of a problem situation, try on a solution, evaluate it,
then process again and quickly try another solution. This continues
until the process is adequately resolved for the moment, but the team
must commit to revisiting the problem as conditions warrant. The
problem-solution iterations might occur days or weeks apart, and they
might occur months or years apart. But they do occur, and you have to
approach each one as if it were new while still retaining the lessons
learned from the last iteration.
This sounds complicated, and it is difficult to do it well, but it
really isn't that foreign. In fact, when I first read about this, it
reminded me of the spiral model Barry Boehm developed at TRW for
software development: try a prototype, evaluate, try another,
evaluate, and so on. The key to success is staying flexible, keeping
communications open, and supplying knowledge to the team quickly.
I've used this model many times in the past couple of years as I
approached difficult problems. In fact, I've designed a set of Lotus
Notes based tools to provide this kind of technology framework for
Gore project teams. These tools help teams focus on the projects at
hand while managing the required knowledge in a flexible and
responsive way. We're starting to see some successes with these tools
with some teams. I've helped them by providing a solution framework
that builds a team "memory" and a shared collaborative workspace that
allows the team to iterate quickly through the trial solutions.
After reading your article, I started to factor in Schrage's work on
teams. I concur with the idea that teams have become highly
politicized and rigid. Teamwork (or collaboration, if you will), on
the other hand, is the essence of solving wicked problems. There is a
nice alignment between the team space required for wicked problems and
the shared space Schrage describes as necessary for effective
collaboration. I think it may also be a feature of these situations
that team composition be changeable over time, and that to some
degree, teams approach each new situation with a heavy
forming/learning curve. This sounds like a problem at first, but I've
come to feel that it's part of the mix in solving wicked problems.
The key, then, is not eliminating these transitions but making them
occur faster while preserving what was learned from previous
iterations as you approach new ones.
So, my advice to Bo would be to keep jousting but recognize that the
goal isn't to improve the situation but, instead, to improve teams'
ability to adapt to the situation quickly and effectively.
Thanks,
Dave Clarke
W.L. Gore Company
---------------------------------------------
I noticed your last Joe's jotting about the project management at HP.
Its not unlike what other companies frustrations are as well.
Several things that the literature notes that arise in most all of
HP's projects and definitely all of those projects you're involved in
from Labs, the desire from the company to maintain processes and
procedures for the projects becomes more difficult as task variability
and interdependence increases. As these task variables move up the
scale to higher levels of variability and interdependence they
increase the need for coordination and communication by the group
members rather than through previously established rules or plans. I
think project managers often find that the project plans they laid out
early on need to be truly living documents subject to often change.
As the projects get more complex and require collaborations outside
their own divisions or even companies their ability to forecast and
schedule ahead of time becomes even more difficult. Real time
management is often the only tool that is useful in these cases. The
use of a system as Bo developed for Lotus Notes can be very worthwhile
as these coordination issues grow and become even larger issues for
the company.
Dave Monahan
Purdue University
--JOE_PODOLSKY@HP-PaloAlto-om4.om.hp.com
Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>