Managing Complex Systems E-Book

Howard Eisner

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Serie: Wiley Series in Systems Engineering and Management
• Sprache: Englisch

Seitenzahl: 364

Veröffentlichungsjahr: 2011

Beschreibung

Nine innovative methods to think outside the box and solve complex system problems Managing Complex Systems provides specific tools and guidance needed to be a more creative and innovative thinker. Following the author's methodology, the reader will be better able to devise and implement nontraditional solutions to seemingly intractable complex problems. By challenging the reader to think in new and creative ways, the book offers a road map to success, whether measured in terms of competitive advantage, greater market share, improved productivity, or higher profits, all based upon better solutions to difficult problems. The first four chapters set the foundation for creative thinking by exploring the nature of large-scale systems and complexity, thinking inside and outside the box, and examples of how an inventive mind solves problems in both management and scientific domains. Subsequent chapters address nine focused methods that the author has formulated to help the reader think outside the box: * Broaden and generalize * Crossover * Question conventional wisdom * Back of the envelope * Expanding the dimensions * Obversity * Remove constraints * Thinking with pictures * Systems approach Real-life examples are provided for each method that demonstrate how the approach enhances problem solving and decision making in system development and management. Following the discussion of the nine methods, the author examines group decision making as well as additional creative thinking procedures devised by other researchers, including references that assist in exploring these methods in greater detail. The author ends with a wrap-up chapter that includes a test to help readers practice their tendencies toward creative thinking skills and action with respect to solving real-world problems. The nine methods discussed in this book have broad applicability and can be used successfully by managers with a wide range of responsibilities in business and technology. For anyone who is tired of the same old approach with the same old results, this book is essential reading.

Leseprobe

Contents

Cover

Half Title Page

About the Author

Title Page

Copyright

Preface

1 Systems and Thinking

1.1 Building and Managing Complex Systems

1.2 Some Results of Thinking Outside the Box

1.3 Thinking in Relation to Specific Issues

1.4 Conclusion

References

2 Building and Managing Systems

2.1 Some Basics of Systems Engineering

2.2 Some Basics of Project Management

2.3 Complex Systems

2.4 System of Systems Engineering

2.5 Summary

References

3 Problems to Ponder

3.1 Problem Areas: Systems

3.2 Problem Areas: People

3.3 Problem Areas: Software

3.4 Problem Areas: Management

3.5 Summary

References

4 The Inventive Mind

4.1 Management Thinking

4.2 Scientific and Technical Thinking

4.3 Not Everyone Is an Einstein (Or Needs To Be)

4.4 The Next Nine Chapters

References

5 Perspective 1: Broaden and Generalize

5.1 Architecting a Complex System

5.2 Using Functional Decomposition to Explore Strategies

5.3 System of Systems Engineering

5.4 IBM’s View of the World

5.5 Haloid’s Bold Steps

5.6 From PERT to GERT to Stochastic Networks

5.7 Reinventing Yourself

5.8 Summary: A Meeting

References

6 Perspective 2: Crossover

6.1 Peoplesoft

6.2 Software Reuse

6.3 Developer Off-the-Shelf Systems

6.4 Accounting Firm Consultation

6.5 Building and Managing New Systems

6.6 Summary: A Meeting

References

7 Perspective 3: Question Conventional Wisdom

7.1 Large and Complex Government Systems

7.2 Conventional Wisdom Changes with the Times

7.3 More Challengeable Conventional Wisdom

7.4 Summary: Two Meetings

References

8 Perspective 4: Back of the Envelope

8.1 What Can Fit on the Back of an Envelope?

8.2 Some Examples of Back-of-the-Envelope Results

8.3 Constructing What’s on the Back of the Envelope

8.4 What Does It All Mean?

8.5 Summary: A Meeting

References

9 Perspective 5: Expanding the Dimensions

9.1 Another Look at Architecting

9.2 The Morphological Box

9.3 Have You Visited Flatland?

9.4 Functions of Many Variables

9.5 The Movie Camera

9.6 A Multifunctional Device

9.7 A Multifunctional House

9.8 Where Do Elevators Belong?

9.9 Where Are Airplanes Supposed to Fly?

9.10 The Grand Unified Theory

9.11 The Spreadsheet Revisited

9.12 Summary: A Meeting

9.13 Solution to the Matchstick Problem

References

10 Perspective 6: Obversity

10.1 Thirty-Six Ways to Fail

10.2 Top Dozen Obversities

10.3 Summary: A Meeting

References

11 Perspective 7: Remove Constraints

11.1 Typical System Constraints

11.2 Internal and External Constraints

11.3 Summary: A Meeting

References

12 Perspective 8: Thinking with Pictures

12.1 Visual Thinking

12.2 Information Flow

12.3 A Different Representation of a House

12.4 General Process Flowchart

12.5 The Parameter Dependency Diagram

12.6 Interface Diagram

12.7 Other Types of Diagrams

12.8 Architectural Views

12.9 Summary: A Meeting

References

13 Perspective 9: The Systems Approach

13.1 Seven Essential Elements

13.2 The Breadth of System Considerations

13.3 The Persistence of Alternatives

13.4 Building a System

13.5 Architecting a System

13.6 Additional Views of Architectures

13.7 Another Government Perspective

13.8 Summary: A Meeting

References

14 Thinking in Groups

14.1 The Delphi Process

14.2 Groupthink

14.3 de Bono and His Thinking Hats

14.4 Advocacy vs. Inquiry

14.5 SAST

14.6 Team Syntegrity

14.7 Facilitation

14.8 Self-Directed Work Teams

14.9 Synectics

14.10 No More Teams: Collaboration

14.11 Conclusion

References

15 Widening the Circle

15.1 de Bono and Lateral Thinking

15.2 TRIZ

15.3 Thinking Like Leonardo

15.4 The Art of Problem Solving

15.5 Einstein

15.6 Breakthrough Thinking

15.7 Creativity

15.8 Cogito Ergo Sum

15.9 Thinking About the Future

15.10 Thinking for a Change

15.11 Some Genius Attributes

15.12 Systems Thinking

References

16 Final Thoughts and a Test

16.1 More Extraordinary Thinkers

16.2 Is There Life Outside the Box?

16.3 Test Yourself

16.4 Final Words

Index

MANAGING COMPLEX SYSTEMS

ABOUT THE AUTHOR

Since 1989, Howard Eisner has served as Distinguished Research Professor and Professor of Engineering Management and Systems Engineering at The George Washington University, Washington, DC. For the prior thirty years, he held various positions in industry, including president of two systems and software engineering companies (Intercon Systems Corporation and the Atlantic Research Services Corporation) and as a member of the board of three companies. He is a Life Fellow of the Institute of Electrical and Electronics Engineers (IEEE) and a member of several engineering honor societies. Dr. Eisner has written two books on systems engineering and related topics and a book on personal and corporate reengineering. He holds a B.E.E. from the City College of New York, and M.S. from Columbia University, and a Doctor of Science from The George Washington University.

Copyright © 2005 by John Wiley & Sons, Inc. All rights reserved

Published by John Wiley & Sons, Inc., Hoboken, New Jersey Published simultaneously in Canada

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750–8400, fax [phone], or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748–6011, fax [phone], or online at http://www.wiley.com/go/permission.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762–2974, outside the United States at (317) 572–3993 or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging-in-Publication Data:

Eisner, Howard, 1935- Managing complex systems: thinking outside the box/by Howard Eisner. p. cm. “A Wiley-Interscience publication.” Includes bibliographical references and index. ISBN-13 978–0–471–69006–1 (cloth) ISBN-10 0–471–69006–6 (cloth) 1. Systems engineering–Management. 2. Project management. I. Title

TA168.E387 2005 658.4’04’0262 - - dc22 2005043921

Preface

This book is about two primary topics: systems and ways of thinking. We are part of and use several systems just about every day: from the highway system, to the telecommunication system, to the banking system, to the medical system, to many others. This central fact supports the notion that it is important to better understand how to build and manage such systems. Improvements can pay large dividends in all our lives and provide benefits measurable in economic as well as quality-of-life terms.

Such improvements are not, however, easy to make. Even if you are inside a company making a special product, it is often a long road from thinking about a product improvement to getting it out the door to your customers. The realities of how we conceive of and actually make new or improved products often conspire against us. So a large number of people in various companies and parts of government have put out the challenge for themselves and their associates—let’s see if we can find a way to “think outside the box.” This book is partly a response to that challenge.

The specific story of this book started some years ago when I was asked to teach a course in systems engineering at a relatively large systems integration and engineering company. About 30 employees were sponsored and made up a cohort that was being given this out-of-the-ordinary treatment. The course was a normal offering as the first course in systems engineering and part of my overall responsibility in the Engineering Management and Systems Engineering Department in the School of Engineering and Applied Science at The George Washington University. As lead professor in systems engineering, I decided to visit with the company manager who wanted this special program for his people. I asked him what he was looking for in the course and its delivery. He gave two answers. Since systems engineering was a core competency in the company’s ability to do systems integration, he wanted to make sure that his people had a formal knowledge of systems engineering, along with some practice in execution. I more-or-less expected that answer, but then he proceeded to a second answer: “I want my people to be better able to think outside the box,” he declared. I took that as a very serious answer, and it motivated me to dig more deeply into its various meanings.

My several-year research activity into what it might mean to think outside the box included a reexamination of my experiences over about a 45-year period. During the first 30 of these years I worked in industry, starting as a research engineer and finishing as the president of two high-tech companies. For the past 16 years I have been a professor in academia, where I served as an educator, researcher, and consultant to several companies and groups. Reviewing these experiences was enormously rewarding as well as lots of fun. It’s not often that one gets a chance to review so many years of work with a focused objective in mind. A key question was: Could I identify specific cases where I concluded that I might be thinking outside the box, as well as to the contrary?

Along with the somewhat personal retrospective noted above, I also scoured the literature and found it expansive. Relevant material was everywhere and took me through a time line from da Vinci’s era to the twenty-first century in terms of both technical and management thinkers. A few even took me back to our very earliest days as, for example, I contemplated what went wrong as some tried to build the Tower of Babel. I’m happy to report that we seem to have been able to do a lot better since that time.

As I was bringing together and organizing my personal experiences along with examples from our history and the literature, a list of some dozen ways to think outside the box emerged. All had at least some foundation in my own experience since I was able to connect to that perspective in a deeper way. In 1999 and 2000 I wrote two articles for the Washington Business Journal on the matter of thinking outside the box. Each article described briefly five ways to do this type of thinking. The reader response to these articles was about 10 times the response I typically got from my other articles on the “technology manager.” This was additional encouragement; people certainly were very interested in this subject.

I followed that with a talk on this topic as the invited lecturer at an evening professional society meeting and dinner. Here again, a lot of interest was displayed, as I had the additional opportunity of a Q & A session as part of the evening activity. All of this convinced me that it was time to think seriously about how to write a book that included these experiences and my newly found set of expanded ways of thinking. The key to moving forward was to link the matter of thinking outside the box with my strong interest in systems and how we might be able to improve how we build and manage systems. I also wanted the book to be as useful as possible, sacrificing much of the academic perspective in favor of real-world practicality. Time will tell whether or not that goal has been achieved.

As to the particulars, this book is organized into 16 chapters. In the first four chapters we explore such topics as the nature of large-scale systems and complexity, thinking inside and outside the box with respect to specific systems issues, some basics of systems engineering and project management, system of systems engineering, typical systems problems faced by management, and examples of the inventive mind in both management as well as scientific domains.

Chapters 5 through 13 then focus on nine specific ways to think outside the box. Examples are used to a large extent to show how these thinking approaches have led to better solutions in the past. In this context, such solutions tend to contribute to improvements in how we build and manage systems of various types.

In Chapter 14, ways of thinking are expanded specifically to group situations. Such scenarios can be enhancers or inhibitors, depending on the group dynamics. Of particular interest is how to achieve the former and avoid the latter.

Chapter 15 widens the circle by presenting approaches that have been suggested by others to expand one’s ways of thinking. These are not included as one or another of the main nine perspectives in Chapters 5 through 13 since the latter are derivative of more personal and direct experiences of mine. References are provided so that readers who wish to explore other approaches may do so.

Chapter 16 is the concluding chapter. It reiterates the main points and perspectives with respect to building and managing complex systems and thinking outside the box. It also includes a test for readers to obtain insights into whether or not they are ready to embrace thinking outside the box as well as some of the consequences of doing so.

Having looked at all of the above, a few words are still in order about who this book might be for. Several audiences are envisioned:

1. People with management responsibilities of various types with respect to building and managing large-scale complex systems

2. Nonmanagers trying to contribute to the building of systems, who are looking for new ways to approach the problems they encounter

3. People who are simply seeking to expand their patterns of thinking in any domain of their lives

4. University students who may be able, relatively early in their careers, to master new thinking perspectives that will help them be more successful in school and after they graduate

Relating to item 4 above, a standard 15-week university course may be constructed as follows:

Class SessionsBook Chapters11 and 223 and 43 through 115 through 1312141315141615Final exam

At a personal level, I wish to dedicate this book to four people. The first is my wife, June Linowitz, who continues to be supportive of my various writing endeavors and who, without much apparent effort, exhibits prodigious skills at thinking, both inside and outside the box. The other three people are my daughter, Susan Rachel Lee, and my sons, Seth Eric and Oren David. All are in their 40s and display considerable wisdom in conducting their lives. And they are passing this on to their children, my grandchildren, who are Gabriel, Jacob, Rebecca, Benjamin, and Zachary. The wheel continues to turn. Thank goodness it is (mostly) round rather than multipolygonic. There are still some bumps in the road.

HOWARD EISNER

Bethesda, Maryland

Chapter 1

Systems and Thinking

The main focus of this book is to define and explore ways of thinking that have been shown to have a positive impact on building and managing complex systems. This chapter is largely introductory, defining some basic aspects of systems as well as issues that relate to the construction and management of these systems. Some alternative approaches to thinking about these issues are also explored.

Complex systems will be interpreted very broadly and will include both physical (mostly hardware and software) groupings of equipment to serve a purpose and sets of procedures that are carried out by people or machines, or both. An example of the former is our national air traffic control (ATC) system that is used to control our aircraft as they fly across the country as well as in and out of terminal areas. For the latter, one might think of an airline reservation system, which is largely procedural but is executed on a large scale by both people and machines. Complex systems tend to be relatively large, with lots of internal and external interfaces. Part of our job in thinking about such systems is to try to reduce the complexity by focusing on fundamentals and simplification. But that is getting a bit ahead of ourselves.

Very large and complex systems include, as examples, the following:

Our national aviation systemOur national telephone systemOur stock market systemOur legislative system, the means by which we enact our lawsOur electricity delivery systemOur interstate highway system

Smaller, but still seriously complex systems could be represented by:

Our traffic control systems, which control the flow of airplanes and automobilesThe aircraft and automobiles themselvesInformation systems of various kinds, such as Microsoft Office or a company’s inventory control system

It is important to note that some systems are related directly to a special or novel idea and that such systems would probably not exist without that idea. For example, when you send a FedEx package from the east to the west coast, you are using a large and complex system (mostly transparent to you) of airplanes, trucks, control systems, tracking systems, delivery personnel, and others. The fact that all packages go to Memphis, Tennessee, overnight and fan out from there is a fact of the design of that system. That design is based on the singular idea that this approach is efficient and cost-effective. Without that idea, another system configuration might have been selected. In other words, for many systems, it is the breakthrough idea that is behind the system, and as such, places us in search of these types of ideas as we approach the design issue. In this book, these types of ideas represent thinking outside the box.

1.1 BUILDING AND MANAGING COMPLEX SYSTEMS

We have a variety of tools that we use to perform the tasks of building and managing complex systems. In the building part, a set of activities known as systems engineering is dominant, giving us guidance on how to construct a cost-effective system [1.1–1.4]. A crucial part of that process is the architecting of the system, which is a top-level structure for the system [1.4, 1.5]. For example, the personal computer today generally has an open architecture, such that there is considerable interoperability between components. The same is true, in the main, for other consumer electronics, such as TV sets, VCRs, DVD players, and stereo (audio) systems. Unfortunately, there are lots of system architectures that do not adequately consider interoperability matters.

For the managing function with respect to complex systems, all of our institutions study and implement the best approaches they can think of in terms of management practices. There is an extensive literature that is available to help, from Jack Welch in regard to how he managed GE [1.6], to Harold Geneen and how he built ITT [1.7]. And there is no dearth of “gurus” such as Peter Drucker [1.8], Tom Peters [1.9], and W. Edwards Deming [1.10], who try to point us in the right direction with respect to the fine art of management. In relation to the field of project management, even I have joined the fray [1.4, Chaps. 3–6].

In both building and managing these systems, we are constantly in search of the new and better idea that will allow us to make critical improvements in their design and operation. The new and seminal idea is the “Holy Grail” that takes us to the next level, so that we may be in a position to do better than our competitors. Our overall industrial system works that way, and is supported in part by an elaborate system that is an example of how we value the new and better approach: our patent system. Without that system for recording and regulating better ideas, it would probably be a free-for-all in industry and a sure road to disaster. In other words, we continue to seek, keep track of, and value the better idea, referred to in this book as what results from thinking outside the box.

1.2 SOME RESULTS OF THINKING OUTSIDE THE BOX

In very specific terms, it is clear that thinking outside the box often leads to a new system that is better than previous systems. This can be illustrated by the following short list of inventions and better approaches that all will recognize:

Light bulbAirplaneTransistorElectronic chipCopying machine (i.e., xerography)Digital computer, from personal computer to supercomputerAtomic bombInternal combustion engineArtificial heartNuclear power plant

Although it is the new and seminal idea that sets the stage for major advances in building and managing systems, such an idea is often insufficient. Usually, there are many hurdles to jump over and potholes to avoid between the thought and its implementation. Bringing an idea from its conception to its fruition in the real world is often a long journey that requires lots of determination and stick-to-itiveness. A relevant observation in this regard is that genius is a matter of 1% inspiration and 99% perspiration (attributed to Thomas Edison). Although modest gains, one day at a time, can be made just by showing up, breakthrough gains don’t come that easily. So even if you have a demonstrably wonderful new idea, you must keep in mind that you’re still only a short way down the road toward the goal of converting the idea into a successful product or service that is implemented in the real world.

TABLE 1.1 Examples of Thinking Inside and Outside the Box

IssueThinking Inside the BoxThinking Outside the Box1. Integration of stovepipes100% of all systems must be integratedIntegrate what it is cost-effective to integrater2. Best of best of breedOptimizing subsystem choices will optimize the overall systemMay not work; there is no guarantee3. MeasurementsMeasure as much as you can think ofMeasure a minimum set that works and “tells the story”4. Getting back on scheduleAdd more people on the projectAdding more people is likely to make situation worse5. Requirements change and volatilityRequirements are to be taken as fixed and inviolateRequirements can, at times, be variables6. Reserves on a projectAll levels of management need to have dollar reservesProject manager needs enough money to get the job done7. Customer negotiationPromise whatever the customer appears to wantTry to underpromise and overdeliver8. Dealing with customersThe customer is always rightThe customer can often be wrong9. Overall approachDo it right the first time (DIRFT) [1.11]Provide continuous improvement and iteration10. Employee trustEmployees cannot be trusted to know how the company is really doingHave the obligation to tell the truth and focus on company well-being11. Work task strategyNever do work unless you can profit from itInvest in key areas for the future health of the company12. Processes and productsGet the process right and the products will always be rightThe right process still doesn’t guarantee the right product

1.3 THINKING IN RELATION TO SPECIFIC ISSUES

Table 1.1 lists a dozen issues together with ways of thinking about these issues that might be considered both inside and outside the box. These are explored next, one issue at a time. They are meant simply to illustrate, in a concrete way, how thinking inside and outside the box may differ from one another.

1.3.1 Integration of Stovepipe Systems

There are a large number of “stovepipe” systems in operation today, each of which carries out a discrete function. Examples include a human resources personnel tracking system, an inventory control system, and a finance and accounting system. When a new manager comes upon such a scene, he or she often leads the charge toward the integration of the stovepipes, believing that an integrated system is certainly going to be more cost-effective. The knee-jerk goal is often something like the following: We need to integrate the stovepipes to the maximum extent, approaching 100% integration. One might say that this knee-jerk reaction to the existence of a set of stovepipes is the rule today rather than the exception.

A deeper look, however, suggests that the integration of stovepipes may be a good idea, but it also may be a bad idea. Further, the so-called goal of 100% integration may be a very bad idea. An out-of-the-box approach might well be to integrate the stovepipes to whatever extent is appropriate and cost-effective, based on the specific circumstances attendant on the stovepipes in question. This author has seen an advanced Navy information system start down the road toward the integration of stovepipes and then be given up after three years, at which time they proceeded to “disintegrate” the stovepipes. The problem, as defined, was just too difficult and expensive.

More will be said about this particular out-of-the-box perspective later in this book. For the time being, can you think of situations for which the integration of stovepipes might well be a less than wonderful idea? If so, make a note of your thoughts and hold on to them until you read the next section.

1.3.2 Best of “Best of Breed”

Inside-the-box thinking assumes that a system composed of the integration of a set of best-of-breed systems will necessarily be the best system that can be constructed. After all, what can be better than the “sum” of “bests”? A simple example should demonstrate that such a system can be a terrible choice in the sense that another approach can easily be seen to be superior.

Let us assume that a government agency has done several in-depth studies to determine the best-of-breed systems that carry out certain functions. The functions and the best of breed answers are as follows:

FunctionsBest of Breed SystemsWord processingWordperfectSpreadsheetLotus 1–2–3Presentation managerPowerpointDatabase management systemOracle

It should be noted that each of these best-of-breed systems is produced by a different company:

Wordperfect is made by Corel.Lotus 1–2–3 is made by Lotus.Powerpoint is made by Microsoft.Oracle is made by Oracle.

Anyone familiar with software products recognizes the difficulty of trying to integrate software from different companies, even if the source code were accessible and modifiable. The costs of doing so would be prohibitively high, especially in light of the fact that another, more than feasible alternative is readily available. Those familiar with Microsoft’s Office system (or Lotus’s Smartsuite) can see immediately that an integrated system with the four functions above is available as a commercial off-the-shelf (COTS) product. Thus, abandoning the integration of disparate systems in favor of Microsoft Office is a clear and highly cost-effective alternative solution. This simple example demonstrates that leaping to the conclusion that a system composed of a set of best-of-breed systems will be the best choice may not be the right answer, even though one’s intuition might point in that direction.

1.3.3 Measurements

This example focuses on measurements programs that are related to the building or managing of a product or service. Measurements are also sometimes called metrics. The inside-the-box approach is to measure everything that you can think of. That way you are not likely to miss anything important, one can reason. As an example, the Department of Defense, in relation to establishing management indicators for software, came up with the following measurement areas [1.12]:

1. 1. Requirements volatility

2. Software size

3. Software staffing

4. Software complexity

5. Software progress

6. Problem change report status

7. Build/release content

8. Computer hardware resource utilization

9. Milestone performance

10. Scap/rework

11. Effect of reuse

Looking at this list, it is evident (1) that lots of measurements are being made, and (2) that it will take a lot of effort to make such measurements. The size and efficacy of a measurements program are, of course, related to the size of the system being developed, but still, the list of measurements above suggests a considerable effort at a very sizable cost. Outside-the-box thinking tries to focus on the minimum measurement profile that is sufficient to “tell the story” and be implementable within the constraints of a real-world situation. That includes the practicality of both making the measurements and making changes, given that the measurements suggest that there are problem areas.

This “minimalist” approach is supported, if you will, by some of the thinking in the ubiquitous and far-reaching Department of Defense. In the so-called 5000 series [1.13] dealing with the acquisition of systems, the directive and instruction of the reference are both scaled down, pointing to performance and capabilities-based acquisitions that are tailored to the situation at hand.

I tend to agree with this idea for most situations, reckoning that there should be an appropriate match between a measurement program and the specific needs of that program rather than going automatically to the default solution that says: “Measure everything that you can think of.” A good measurements program should be designed rather than be the consequence of constructing a mindless, long laundry list.

1.3.4 Getting Back on Schedule

Many large-scale software development projects seem to go off the track after awhile, as manifested by falling behind schedule. This means that the actual achievement of various milestones is later than that called for by the original schedule. One inside-the-box reaction is to add personnel to the project in an attempt to get back on schedule. This reaction flies in the face of Brooks’s law [1.14], which states that the addition of personnel will probably make the project schedule problem even worse rather than better. Part of the reason for this apparent anomaly is that productive people currently working on the project will have to stop what they’re doing in order the bring the new people “up to speed.” This diversion of their time and attention makes the schedule problem worse, among other negative effects.

Is there a potentially better solution to this type of problem? A few other approaches suggest themselves, including (1) changing the technical approach, which may not be sound; (2) recognizing that the present personnel level may not be sufficient in terms of the technical challenge and its degree of difficulty; and (3) the original schedule may not be realistic.

1.3.5 Requirements Change and Volatility

Inside-the-box thinking assumes that the up-front set of defined requirements is basically inviolate and “set in concrete.” This point of view often follows from the need to be definitive in a contract document between customer and contractor. However, since requirements are usually defined very early in a program, it makes sense that they will probably have defects, often significant ones. Out-of-the-box thinking recognizes the fallibility of the people who develop this early statement of requirements and provides the means by which requirements can be changed in an organized and disciplined manner. This is not the same as requirements creep. Sensible changes to requirements should be made when both parties agree that such changes will improve the system development process or the product.

Support for the above can be found in both the “spiral” approach to building systems [1.15] and in aspects of the acquisition process in the government. With respect to the latter, we find the following phrase: “consistent and continuous definition of requirements.” As systems are built, they are acquired in increments. This incremental approach suggests further that requirements may change as part of the process, for purposes of refinement and improvement.

1.3.6 Reserves on a Project

Conventional wisdom might suggest, in the execution of a project, that each layer of management set aside a reserve to try to assure project success. That’s an interesting mainstream idea but it can easily lead to counterproductive results. Suppose that a project manager (PM) reports to a program manager who reports to a division director who reports to a vice president. If the latter three executives each set aside a 10% dollar reserve, we can see that the PM is left with only about 73% of the original budget to work with. As a conscientious PM, he or she will then attempt to complete the work with about three-fourths of the original estimate of funding. This, in turn, can place enormous stress on the PM as well as on every member of the team over the entire duration of the project. This can easily lead to several negative consequences.

First, let us assume that by lots of extra hours and good PM management, the project is completed without use of the reserves. As the people on the project discover that all those extra hours were likely not to have been essential, they will conclude that they were taken advantage of, unless they get a bonus for the work. If not, a lasting negative feeling will persist.

Now assume that the project is not completed: that is, the PM runs out of money prior to completion. The reserves may or may not have been employed in time to preclude schedule and technical progress slippages. If not, a failure scenario has taken place, even though that was not the intention. The bottom line? Don’t give the PM a very nearly impossible job to do and try to be a hero by making new funds available later. It’s a strategy that has a good chance of backfiring. Instead, give the PM all the money necessary to get the job done.

1.3.7 Customer Negotiation

There are literally hundreds of books that can be consulted about how to negotiate with your customer, who is looking to you, and possibly others, to build and manage a system for them. Conventional wisdom appears to tilt in the direction of promising essentially whatever the customer wants. It is easy to see that this strategy can often lead both parties astray.

An alternative out-of-the-box approach was suggested to me by my oldest son. He had been quite successful as a software development manager at a large and significant company. One day I asked him to cite the most important reason for his success. His answer was: “Try to underpromise and overdeliver.” This meant relatively hard-nosed up-front negotiation, but it paid handsome dividends to both parties down the road. At project completion, everyone tended to be pleased. Another way of expressing this approach is simply to manage expectations. Many managers work themselves and their people to a frazzle and still wind up with an unhappy customer. The reason: They haven’t paid attention to managing expectations.

1.3.8 Dealing with Customers

Related to the above is the inside-the-box notion that the customer is always right. Since the customer consists of one or more fallible human beings, it is clear upon further consideration that the customer can be wrong at times, especially in relation to a nonmass marketing and sales situation. In a more conventional one-on-one context, your customer, for example, may:

Desire that you meet an impossible scheduleNot be willing to pay for the true product or project costsAsk for work that is outside the scope of the contractNot provide adequate customer-promised equipmentTry to upgrade product specifications and requirements midway through a project, with no schedule or cost consideration

Any one of the above (and potentially lots of others) may lead you down the road to failure and should therefore be resisted. The perspective that the customer is always right may be a good metaphor for how generally to treat a customer, but it should not be accepted literally in most situations. Knowing when the customer is right, and when not, can easily translate into the difference between your success and your failure. One of the precepts of building complex systems is to walk away from a customer who insists on driving the relationship to a “win-lose” conclusion, with them on the winning side.

1.3.9 Overall Approach

There is a notion that comes from the field of total quality management (TQM) that might also be applied to one’s overall approach to building and managing systems. This notion, coined by Philip Crosby [1.11], can be stated succinctly as “Do it right the first time” (DIRFT). Although that is not an undesirable thing to do, I would still put it in the category of being inside the box. What, then, is outside the box? It certainly could not be “Do it wrong the first time”!

In today’s world of complex systems, it is necessary to acknowledge that the chances of doing everything correctly the first time is vanishingly small. So the question becomes: What approach should be taken in the light of this fact? The answer that lies outside the box in this connection is to focus on continuous improvement and iteration (CII). This perspective is from both the fields of TQM and systems engineering. The CII approach recognizes that we learn more about the system as we proceed through its development cycle, and what we know needs to be used to update earlier versions of the system. This relates to the discussion above about changing requirements, the “spiral model,” and the value of iteration in order to converge on a system architecture and detailed design. This is not an invitation to make mistakes, but rather, to understand how to proceed when you are faced with unknowns and hurdles that need to be dealt with in a systematic and progressive manner. This is also reinforced by a key idea of Senge’s [1.16]: that organizations need to become learning entities, which will better allow them to tackle matters related to continuous improvement and iteration.

1.3.10 Employee Trust

In the context of a project whose purpose is to build or manage a system, the project personnel are often not trusted to know fully the status of the project, especially if there is trouble. This reflects the idea that bad things might happen if these personnel are too aware of problems. Indeed, it also reflects the perspective that members of your team are not necessarily to be trusted to know the truth. This attitude is distinctly inside the box and should be replaced by an open and truthful approach to members of the project team. It is also perfectly all right to ask project personnel to keep any and all information about the project within the project team and only the project team. It turns out that people will respond very well to being trusted and not well to not being trusted. Isn’t that true of you?

1.3.11 Work Tasks Strategy

With a project orientation, as discussed above, there is often the question of how to approach work tasks that are in the gray area, defined here as the set of tasks that might or might not be essential to successful completion of the project. How much effort, if any, should be applied to tasks within this zone of uncertainty? The inside-the-box answer tends to be guided by the admonition never to do work unless you can make a profit from it. This can get into the matter of the type of contract under which the work is being performed. Independent of that, however, is the out-of-the-box perspective that it is necessary to make certain investments that tend to be for the overall health and greater good of the enterprise, even though it might be detrimental to the budget of a particular project. The PM should be aware of the “greater good” scenario and bring such situations to the attention of his or her boss as soon as possible.

In a context larger than that of a project, the same type of question can be addressed at the enterprise level. Companies need to invest in their futures, and the failure to do so might result in no future at all, in favor of maximizing profits for today (or the next quarter). Enterprises that are prosperous today do not necessarily have a license to that prosperity forever. A brief look at the company Wang Laboratories demonstrates that point: a multibillion-dollar and highly successful company in the 1980s that went into bankruptcy into the 1990s. They may have been investing in their future, but the way they did it is certainly open to question. The same may be said for quite a few “systems” organizations. The bottom line here is that all enterprises need to be open to investing in key areas, at all levels in the company, from the corporate level to the project level.

1.3.12 Processes and Products

There appears to be an inside-the-box perspective that if the processes are correct, it follows that the product will be also, and without question, will be correct. Processes are clearly important, but the matter of building and managing systems is not totally a function of these processes. The belief that “process is king” may lead to an inappropriate allocation of effort and funding that works against success instead of for it.

An outside-the-box view is that the correct process is a necessary, but not a sufficient, condition for success. In other words, there are other key ingredients to success, the most important of which is subject matter expertise. Teams with excellent process behavior may still lack the proper subject matter knowledge to both build and manage complex systems. Clearly, one should not expect a highly capable process-oriented team of communication engineers to build an excellent nuclear power plant, and conversely. Every enterprise needs to find the right process but must also make sure that each team has the right mix of subject-specific knowledge as part of the team expertise.

1.4 CONCLUSION

The issues discussed above have been examined from the perspective of what appears to be inside the box and what outside. Several of these issues will resurface in later chapters. Readers may or may not agree with all that has been said, and to a certain extent, that is expected. After all, outside-the-box views are, by definition, in the minority. If you are now itching to take issue with one or more of the dozen examples above, I urge you to be patient, as more will be said about that in later chapters. For the time being, let us look more deeply into how we approach the matter of building and managing complex systems and their ingredients. These are the main topics of Chapter 2.

REFERENCES

1.1 Sage, A. P. (1992). Systems Engineering. New York: Wiley.

1.2 Sage, A. P., and J. E. Armstrong, Jr. (2000). Introduction to Systems Engineering. New York: Wiley.

1.3 Blanchard, B., and W. Fabrycky (1998). Systems Analysis and Engineering, 3rd ed. Upper Saddle River, NJ: Prentice Hall.

1.4 Eisner, H. (2002). Essentials of Project and Systems Engineering Management, 2nd ed. New York: Wiley.

1.5 Rechtin, E. (1991). Systems Architecting. Upper Saddle River, NJ: Prentice Hall.

1.6 Welch, J. F., Jr. (2001). Jack—Straight from the Gut. New York: Warner Books.

1.7 Geneen, H. (1984). Managing. New York: Avon Books.

1.8 Drucker, P. F. (1986). The Frontiers of Management. New York: Harper & Row.

1.9 Peters, T. J., and R. H. Waterman, Jr. (1982). In Search of Excellence. New York: Harper & Row.

1.10 Deming, W. E. (1982). Quality, Productivity and Competitive Position. Cambridge, MA: MIT Press.

1.11 Crosby, P. (1984). Quality Without Tears. New York: New American Library, Penguin Books.

1.12 U.S. Department of Defense (1994). Software Development and Documentation, Military Standard 498. Washington, DC: DOD.

1.13 U.S. Department of Defense (2003). Operation of the Defense Acquisition System, Directive 5000.1 and Instruction 5000.2. Washington, DC: DOD, May 12.

1.14 Brooks, F. P., Jr. (1975). The Mythical Man-Month. Reading, MA: Addison-Wesley.

1.15 U.S. Department of Defense (2003). Operation of the Defense Acquisition System, Instruction 5000.2. Washington, DC: DOD, May 12.

1.16 Senge, P. M. (1990). The Fifth Discipline. New York: Doubleday Currency.