Early in 1993, Bill Holst of
Digital Equipment Corp. sent me an account of the success of DEC's Alpha AXP project[1]. That
triggered an ongoing research project at CASELab -- tracking back and
sideways
through the references in that paper, as well as some tips from colleagues on
the CompuServe CASE forum.
The seminal work that
started it all was done by Allen Scherr of IBM, best known as the father of
TSO, the Time Sharing Option for OS/360, but also the overall project manager
for the first release of MVS. Now an IBM
Fellow, as a VP in the Application Systems Division he had the responsibility
for delivering a large number of software packages for the
application layer
of SAA. One of his colleagues, Michell
Watson, noticed that a supplier was achieving productivity levels far beyond
what they considered possible. How
were they achieving this? Scherr and
his staff set out to find out, by studying IBM and supplier projects which had
produced extraordinary results. Then,
they intentionally created the same conditions in a number of their own
projects,
and achieved the same results! He
briefly describes 16 projects, 15 of which produced exceptional results.[2] (The failure
also verifies the findings.) Here are
his breakthrough principles:
Breakdowns.
A breakdown is a significant
difficulty. The project appears to failing; there's a big gap between what's
being delivered and what's expected. Closing this gap will require a
breakthrough. The greater the gap, the greater
the potential breakthrough. However,
the project team must be truly committed to the promised
delivery, or the
gap will not be conceived as a
breakdown. The breakdown occurs because
either:
1. Some natural sequence of
events (a disaster) degrades the conditions of the project.
2. The commitment is
increased to some unreasonable level.
In the first case, the team
which achieves a breakthrough will probably only return to "Business As Usual". In the second
case, the team may fail, but they also may achieve an extraordinary
breakthrough.
Risk. Most projects, particularly in large
organizations, are estimated and managed in order to minimize risk. Even when successful, these produce ordinary
results at best. There can be no great
breakthroughs without great risk.
This is why so many breakthroughs
happen in new, small companies.
Circumstances give them no choice;
if they don't produce extraordinary results with the resources they
have, they die. Large companies must
learn to create these same "small company" conditions if they expect
breakthroughs.
Commitment. The team must really be committed to the project and
to its "unreasonable"
demands. There are three generic
problems associated with securing this commitment from everyone.
A member feels
that making a commitment to something "impossible" violates his/her
personal integrity.
Managers
assume that they can direct their employees to be committed.
Team members
are not unequivocally committed.
To avoid these problems, IBM
first trained top managers, and then teams of six to 20 team members to
understand the nature of the breakthrough process and the authentic commitment
which is required from everyone. In
order to be authentic:
The commitment
must be unequivocal; i.e. with no conditions or escape clauses.
People must
have a choice. (If one cannot say
"no", then what does "yes" mean?)
The outcome
must be considerably more than "predictable".
Teamwork. It is typical to break projects up into
team-sized tasks. When this is done, it
is possible for all of the teams to be on schedule except one. The one that's behind will delay the entire
project. To avoid this, everyone on the
project must commit to delivering the entire product. (They may then make additional
extraordinary commitments to deliver their components quickly to meet that overall goal.) Because of this commitment, the
entire project can bring all of its resources to bear on the problems of the
troubled team. This drastically
improves the chance for breakthrough.
Sign here! Sounds
tough, doesn't it? Who would buy into such a deal? IBM found that, by simply asking--with an option to freely accept or decline--they had no problem getting people to make
extraordinary commitments. People want to be committed to producing
exceptional results at work. What has
been missing is the opportunity!
The Alpha AXP is Digital Equipment Corporation's new 200 MHz chip,
which will appear in products ranging from workstations to the Cray
supercomputer. Its
production is
pivotal to DEC's survival in this decade.
The project involved 32 engineering groups in 10 countries--over 2000 people--and was managed by a program office (PO) which had no
authority! That meant that all
motivation and coordination only worked if the participating groups bought in
to it (that's what "Enrollment Management" means.)
Conceptually, the project
managers applied Scherr's concepts wholeheartedly, with some interesting
extensions. Here are the principles
upon which the group prospered.
Creating a vision. The first responsibility of the
PO is to create a vision in which all groups enroll. Those groups which don't do this will cause problems later. However, it's never too late for them to
enroll. The model involves cycling
through the following steps:
1. Vision Enrollment. Buying into
business goals and project objectives
2. Commitment Delegation. Establishing trust and accountability by
task/owner/date)
3. Inspection Support. Reviewing
progress and providing encouragementand resources.
4. Acknowledgment Learning (giving wide personal & public recognition for
accomplishments)
Cycling continues throughout
the project as required.
Networking. The PO used the extensive Digital network (over
100,000 terminals and workstations) to plan and coordinate the project. Recognition of group and
individual
accomplishments was enabled by the network and its groupware. The PO published condensed (one-page)
schedules, and review reports which "told it like it was" on Notes
Conferences shared by all the teams.
The resulting peer pressure motivated individuals and teams to meet
their commitments.
Cross-functional management teams. There were
two management teamsone addressing technical issues, the other
addressing project management issues, which met weekly.
It was immediately apparent that, because of the magnitude of the task
set, the team could not build a
detailed master project plan until they got into the midst of the work. So, these teams developed the project plan
dynamically as they got details from the diverse task teams. (So much for "planning ahead", as
advocated by many glib project management experts. Straus and Spiwack suggest
that the breakthrough model should use pathways
rather than plans to handle the
breakdowns and breakthroughs.[3])
Cusps. Digital called their breakdowns cusps (from Gleick[4]). They
encountered a series of these, each of which provided an opportunity for
breakthrough. The article lists nine
cusps which were used to aggressively improve the schedule, and to meet quality
goals. Here are some:
Cusp: Executive challenge to deliver. DEC's top
management challenged the teams to accelerate the project: Result: Team developed positive incentives
like "for every hour we can improve (lower) the time-to-profit, Digital will achieve an additional $1 million
of revenue."
Cusp: Lack of project management
expertise. Several large projects did not know how to
plan their own aggressive schedule to improve delivery. Result: Team hired
outside consultants immediately, put people through classes, and started
putting the new principles in place.
Cusp:
Critical Project Slips. A project on the critical path slipped by
several months. Result: Formal
inspection process, previously resisted by most of the groups, was adopted by
all hands.
Cusp:
Despair. Many of the teams became overwhelmed and
discouraged by the magnitude of the tasks ahead of them. Result: The PO, using the network, developed positive
methods of demonstrating incremental progress and customer acceptance of the
expected
product and sharing it with the teams.
The Bottom Line.
Digital met their most important schedule date--high-volume shipments--to the month.
The product exceeds performance goals and seems to have high
quality. In retrospect, the PO would
have done two things differently:
1. Introduced project management training early, rather than waiting
until teams asked for it.
2. Set up and conduct more pervasive project inspections to cut down
on late surprises.
When I started talking about
breakthrough teams, Larry Constantine pointed me at a remarkable study by Carl
Larson & Frank LeFasto[5]. They looked
at more than 30 successful teams, in order to find what such teams have in
common. They found eight factors that all of these teams had in common.
1. A shared vision. "A clear understanding of the goal to
be achieved." Furthermore, the
belief that the goal is "elevating" -- i.e. "embodies a
worthwhile or important result"
2. Focused structure &
purpose. The group is organized for
results. There are three potential
structures: as a problem-resolution team, as a creative team, or as at a
tactical (plan directed) team. It has
an effective communication system: This
has some interesting features:
It's online. Everyone can get to everything.
It's credible. The team has confidence that in the information on
which it's basing its decisions.
It's ad hoc. The team members have the opportunity to raise
issues not on the formal agenda.
It's complete. The
communications system keeps
everything, and becomes a collective memory for the group. "Keeping an accurate record of the
team's actions and decisions prevents wasteful duplication of effort and
reduces confusion."
3. Good people. Team members are trustworthy, and are
respected for their unique capabilities and the contribution they make to the
team.
4. Common commitment. Commitment supplies energy to the team
and to its work. One of their
interviewed team leaders says "Team members have got to believe that what
they are doing is more important than anything else." Both the shared vision and the unified
commitment create this belief. (see
Sidebar1)
5. A collaborative climate. "The essence of teams is
teamwork." "Collaboration flourishes in a climate of
trust". This collaborative climate
seems to affect not only the team's current performance, but its ability to
improve.
6. Standards of excellence. "At the broadest conceptual level, a standard consists of pressure to achieve a required or expected level of performance." Each team member feels internal pressure to meet his or her personal standards, and the team finds it unacceptable for anyone to do anything less than exceed expectations.
7. Empowering support and
recognition. Although this factor
is noted more for its absence on poorly functioning teams, it is always present
for the successful teams. The organization believes in the team, and gives it
both the resources it needs, and the rewards
it deserves when it succeeds.
8. Principled leadership. "The
single most distinguishing feature of the effective leaders in our database
was their ability to establish, and lead by, guiding
principles."...most
important, they create self-confidence in people, thereby encouraging them to
take risks, make decisions, and act -- in short, to be leaders
themselves."
I found it significant that
the factors that Larson & LeFasto found in their set of
projects were
mostly present in the Alpha AXP project.
These conclusions are drawn
primarily from Scherr's work, but they are validated and augmented by the DEC
experience and by Larson & Lefasto.
Most people
know that productivity must be increased and are willing to make commitments
beyond what is predictable.
By seeking
authentic commitment from a team, we can achieve extraordinary
breakthroughs
from ordinary people, with ordinary tools.
Although the
risk is high, the payback is equally high, and there are ways of
minimizing
the risk through education and intense teamwork.
By looking at each project breakdown as an
opportunity for breakthrough, project management creates a positive attitude
for teamwork which is unbeatable.
Teamwork is
significantly enhanced by an online "group memory" which contains all
of the successes, failures, breakdowns and breakthroughs, exactly as they
occurred,
and accessible to everyone on the project.
As always, knowledge is power.
##
Dedication vs. Commitment
You've probably heard the old joke about the difference between
dedication and commitment:
"A hen is dedicated to producing eggs; a pig is committed to
producing bacon."
Unfortunately, to the potential team member, this implies that "If
I really commit to this, it may kill me!"
Here's a better description of commitment, from Berkman & Lahnston.[6] They
describe three degrees of acceptance:
An aligned stand. People say,
"We say this will happen."
You have their hearts.
Buyin. People say, "Sounds
good. I'd have to be pretty dumb not to
go along with it." You have their
heads.
Compliance. People say, "I'll do it
because I have to." You have their
hands.
Teams that create breakthroughs are powerfully aligned and with that
degree of understanding and commitment, they can and will make it happen.
Timeboxes: Another Breakthrough
Approach
A relatively simple approach to
achieving "little" breakthroughs is the timebox approach, generally attributed to Scott Shultz, formerly
at E.I. Dupont de Nemours & Co., and currently with Ernst & Young. (By "little", I am implying less
gain, but also less risk.)
The timebox is a time limit which is imposed on schedule items, based on
the exigencies of the situation, rather than the content. According to Kerr & Hunter, "when
the project scope conflicts with the time limit, the scope is reduced to fit the time limit."[7] We have a timebox of --say -- two days to write the
specifications; we specify as much
system as we can in that time period, and then quit. A reverse spin on
Parkinson's Law, the technique works because it cuts off a lot of the
"last 10% takes 90% of the time" effect I described here in a
previous article.[8]
James Martin describes very successful applications of the timebox
approach at DuPont; his figures seem to prove that breakthroughs have an
incredible payback with a minimum of risk.[9] For another
discussion of the timebox approach, see Bob Podd's article in an upcoming Embedded Systems Programming.[10]
During the 60's, Rick Zahniser built complex systems
for ITT and IBM. In the 70's, he was a consultant, team-leader and manager for
CIBAR, Inc. and System Development Corporation, specializing in real-time and
data-based systems. During the 80's, he wrote and taught professional seminars
for CIBAR Systems Institute and Learning Group International (Structured Design
& Programming, CASE Hands-On) and built a number of PC-based applications
to apply new analysis, design and prototyping techniques and tools. In 1990 he
founded CASELab, Inc. which focuses on improving software team productivity.
He is the publisher of LabNotes: a journal on group software productivity, and
the architect of Design By Walking
Around, an N-dimensional approach to system analysis and design, and JMPSSTART, a highly structured team
approach
to rapid software development. Update:
In 1999, Rick moved to Belize, Central America. You can discuss these and other ideas with him
on
his
website: http://belizenorth.com.
Author's
Present Address: 15 Eighth Avenue, Corozal Town,
Belize, Central America. 001-501-402-0300. E-mail: rickz@usermail.com
[1]Conklin, Peter F. "Enrollment Management, Managing The Alpha AXP Program", Digital Technical Journal, 4:4 (Special Issue, 1992).
[2]Scherr, Allen. "Managing for Breakthroughs in Productivity", Human Resources Management, 28:3 (Fall 1989).
[3]Straus, Jerry & Spiwack, David. "The IS Productivity Challenge: Motivating your people to produce breakthroughs", American Programmer, 3:7/8, July/August 1990.
[4]Gleick, James. Chaos: Making a New Science. New York: Viking, 1987.
[5]Larson, Carl E. & LaFasto, Frank M. J. Teamwork: What Must Go Right; What Can Go Wrong. Sage, Newbury Park, CA, 1989.
[6]Berkman, Robert E. & Lahnston, Anton. "Successful Business Reengineering: Protecting Your I/T Investment." Transcript of a presentation at the POSPP (Profit Oriented Systems Planning Program), October, 1992. [PII 1203]
[7]Kerr, James & Hunter, Richard. Inside RAD: How to Build Functional Computer Systems in 90 Days or Less. McGraw-Hill, New York, 1994.
[8]Zahniser, Richard A. "JMPSSTART: A Massively Parallel Software Development Approach," American Programmer, 5:1, January 1992
[9]Martin, James. Rapid Application Development. Macmillan, New York, 1991.
[10]Podd, Robert J. "Evolutionary Delivery Plans", Embedded Systems Programming, June 1994.
Copyright, CASELab, 1994. All Rights Reserved.