Breakthrough Projects

Rick Zahniser, CASELab, Inc.

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 break­through.  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 extraordi­nary 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. 

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 authen­tic com­mitment which is required from everyone.  In order to be authentic:

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!    

Enrollment Management

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 re­sources.

4.  Acknowledgment Learning (giving wide personal & public recognition for ac­com­plishments)

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 sur­prises.

Success Factors for Breakthrough Teams

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 ac­tions and decisions prevents wasteful duplication of effort and reduces confu­sion."      

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 lead­ers 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. 

Some Conclusions 

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. 

##

 

(sidebar1)

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 un­derstanding and commitment, they can and will make it happen.

   


 

(sidebar2)

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]

 


About the Author

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 tech­niques and tools. In 1990 he founded CASELab, Inc. which focuses on improving soft­ware 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 Manage­ment, 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.