visualizing project management

VisualizingProject Management

Models and frameworks formastering complex systems

Third Edition

Kevin Forsberg, Phd, csepHal Mooz, PMP, CSEP

Howard Cotterman

John Wiley & Sons, Inc.

cott_a01ffirs.qxd 7/1/05 4:06 PM Page i

Copyright © 2005 by John Wiley & Sons, Inc. All r ights 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, ortransmitted in any form or by any means, electronic, mechanical, photocopying,recording, scanning, or otherwise, except as permitted under Section 107 or 108 ofthe 1976 United States Copyright Act, without either the prior written permission ofthe Publisher, or authorization through payment of the appropriate per-copy fee tothe Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923,(978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requeststo 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(201) 748-6008, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have usedtheir best efforts in preparing this book, they make no representations or warrantieswith respect to the accuracy or completeness of the contents of this book andspecifically disclaim any implied warranties of merchantability or fitness for aparticular purpose. No warranty may be created or extended by sales representativesor written sales materials. The advice and strategies contained herein may not besuitable 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 othercommercial 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 (317) 572-4002.

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

Library of Congress Cataloging-in-Publication Data:

Forsberg, Kevin.Visualizing project management : models and frameworks for mastering

complex systems / Kevin Forsberg, Hal Mooz, Howard Cotterman.—3rd ed.p. cm.

Includes bibliographical references and index.ISBN-13 0-978-0-471-64848-2ISBN-10 0-471-64848-5 (cloth)

1. Project management. I. Forsberg, Kevin. II. Cotterman, Howard. III.Title.

HD69.P.75F67 2005658.4′04—dc22

2005007673

Printed in the United States of America10 9 8 7 6 5 4 3 2 1

cott_a01ffirs.qxd 7/1/05 4:06 PM Page ii

www.wiley.com

To those who master complexity andprovide us with simple, elegant solutions.

cott_a01ffirs.qxd 7/1/05 4:06 PM Page iii

cott_a01ffirs.qxd 7/1/05 4:06 PM Page iv

Foreword to theThird Edition

Today’s industrial products, and many public sponsored projects,show a strong increase in functionality and complexity. Think of au-tomobiles, mobile phones, personal computers, airplanes, or a spacemission. To ensure success and cope with inherent risks of modernproducts, project management and systems engineering have be-come indispensable skills for forward-looking enterprises. Theyhave been thrust into the center of attention of top executives. Bothfields, project management and systems engineering, ensure successby focusing on technical performance, cost, and schedule—and be-yond that on parameters such as return on investment, market ac-ceptance, or sustainability.

Anyone who has lived with the space program, or any other high-tech industrial product development, can immediately appreciatethis acclaimed book. It addresses and “visualizes” the multidimen-sional interactions of project management and systems engineering inseveral important ways. The book shows the interdependencies be-tween the two disciplines and the relationships that each disciplinehas with the many other engineering, manufacturing, business ad-ministration, logistics, enterprise, or market-oriented skills neededto achieve successful products.

Since the early 1970s, many of the world’s space projects havebeen planned and implemented through broad international cooper-ation. Having lived through some of these as engineer, project man-ager, and managing director, I well understand the need for simpleand broadly accepted principles and practices for the practitionersof project management and systems engineering.

My years in industry gave me significant insight into the dif-ferent engineering and project management cultures and practicesprevailing in Europe and the United States. It enabled me to un-derstand and easily interact with the different organizations that

v

cott_a01ffirs.qxd 7/1/05 4:06 PM Page v

vi FOREWORD TO THE THIRD EDITION

were involved in the most complex transatlantic cooperation of the1970s. Remember, failures result not only from poor hardware engi-neering, software engineering, or systems or project management;they can also originate from differing cultural interpretations of en-gineering, communications, or management practices.

On more recent, highly complex international projects, such asthe world’s largest radar missions (SIR-C and SRTM) f lown on thespace shuttle, and the International Space Station (ISS), welearned again the lesson that project management and systems en-gineering, when focused on the essentials, are key ingredients toassured success.

At the Technical University of Delft in The Netherlands a fewyears ago, we initiated a new international postgraduate Master pro-gram of space systems engineering for senior engineers with a focuson modern “end-to-end” systems engineering. We emphasized theimportance of multidisciplinary engineering, communication, andmanagement interaction on the basis of a common use of terms anddefinitions. We also gave strong consideration to the fact that sys-tems engineering and project management need to closely interact toachieve results.

The importance of this excellent book, able to encompass thesetwo key disciplines, cannot be overemphasized. I was hence delightedto have been invited to write the Foreword for this third edition.

—Heinz Stoewer

Heinz Stoewer is the president of the International Council on SystemsEngineering (INCOSE). Professor Stoewer started his career in aero-space. He spent a number of years in German and U.S. industry(MBB/EADS and McDonnell-Douglas/Boeing). In the 1970s, he was ap-pointed the program manager for the Spacelab, the first human space-f light enterprise at the European Space Agency. He eventually became amanaging director of the German Space Agency. As professor for spacesystems engineering at the Technical University of Delft in The Nether-lands, he initiated a highly successful space systems engineering Masterprogram. Throughout his career, he has been aware of the need to interacteffectively with compatriots in other fields and in other countries in areascovering the management of projects, systems, and software engineering.

cott_a01ffirs.qxd 7/1/05 4:06 PM Page vi

Foreword to theSecond Edition

There are a thousand reasons for failure but not a single excuse.

Mike Reid

It is every manager ’s unending nightmare: In today’s world of in-creasing complexity, there is less and less tolerance for error. We seethis daily in the realms of health care, product safety and reliability,transportation, energy, communications, space exploration, militaryoperations, and—as the above quote from the great Penn State foot-ball player Mike Reid demonstrates—sports. Whether the venue isthe stock market, a company’s customer base, consumers, govern-ment regulators, auditors, the battlefield, the ball field, or themedia, “No one cares”—as the venerated quotation puts it—“aboutthe storms you survived along the way, but whether you brought theship safely into the harbor.”

Over the course of my own career in aerospace, I have seen anunfortunate number of failures of very advanced, complex—and ex-pensive—pieces of equipment, often due to the most mundane ofcauses. One satellite went off course into space on a useless trajec-tory because there was a hyphen missing in one of the millions oflines of software code. A seemingly minor f law in the electrical de-sign of the Apollo spacecraft was not detected until Apollo 13 was200,000 miles from Earth, when a spark in a cryogenic oxygen tankled to an explosion and the near-loss of the crew. A major satelliteproved to be badly nearsighted because of a tiny errorin grinding the primary mirror in its optical train. And, as becameapparent in the inquiry into the Challenger disaster, the per-formance of an exceedingly capable space vehicle—a miracle ofmodern technology—was undermined by the effects of cold temper-ature on a seal during a sudden winter storm. Murphy’s Law, it wouldseem, has moved in lockstep with the advances of the modern age.

vii

cott_a01ffirs.qxd 7/1/05 4:06 PM Page vii

viii FOREWORD TO THE SECOND EDITION

THEORETICALLY, SUCCESS IS MANAGEABLE

In the grand old days of American management, when it was pre-sumed that all problems and mistakes could be controlled by morerigorous managerial oversight, the canonical solution to organiza-tional error was to add more oversight and bureaucracy. Surely, it wasthought, with more managers having narrower spans of control, theorganization could prevent any problem from ever happening again.Of course, this theory was never confirmed in the real world—or asKansas City Royals hitting instructor Charlie Lau once noted regard-ing a similar challenge, “There are two theories on hitting the knuck-leball. Unfortunately, neither one works.”

The problem with such a strategy of giving more managersfewer responsibilities was that no one was really in charge of thebiggest responsibility: Will the overall enterprise succeed? I recallthe comment a few years ago of the chief executive of one of theworld’s largest companies, who was stepping down after nearly adecade of increasingly poor performance in the marketplace by hiscompany. He was asked by a journalist why the company had faredso poorly under his tutelage, to which he replied, “I don’t know. It’sa mysterious thing.”

My observation is that there is no mystery here at all. Afterdecades of trying to centrally “manage” every last variable and con-tingency encountered in the course of business, Fortune 500 com-panies found themselves with 12 to 15 layers of management—butessentially ill prepared to compete in an increasingly competitiveglobal marketplace. Or as I once pointed out in one of my Laws, “Ifa sufficient number of management layers are superimposed on topof each other, it can be assured that disaster is not left to chance.”

A NEW LOOK AT PROJECT MANAGEMENT

Today’s leaders in both the private and public sectors are rediscov-ering the simple truth that every good manager has known in his orher heart since the first day on the job: Accountability is the onemanagerial task that cannot be delegated. There must be one per-son whose responsibility it is to make a project work—even as weacknowledge the importance of teamwork and “worker empower-ment” in the modern workplace. In other words, we are rediscov-ering the critical role of the project manager.

The importance of the project manager has long been noted inour nation’s military procurement establishment, which has tradi-

cott_a01ffirs.qxd 7/1/05 4:06 PM Page viii

tionally considered the job to be among the most important and mostdifficult assignments in peacetime. Performed properly, the projectmanagement role, whether in the military, civilian government, orin business, can make enormous contributions and can even affectthe course of history.

Challenges of this technology-focused project management roleare particularly noteworthy for the insights they provide into thebroader definition of project management. Perhaps the greatest ofthese is inherent in technology itself. In the effort to obtain the max-imum possible advantage over a military adversary or a commercialcompetitor, products are often designed at the very edge of thestate of the art. But as one high-level defense official noted in a mo-ment of frustration over the repeated inability of advanced elec-tronic systems to meet specified goals, “Airborne radars are notresponsive to enthusiasm.” In short, managerial adrenaline is not asubstitute for managerial judgment when it comes to transitioningtechnology from the laboratory to the field.

Despite considerable tribulations—or, perhaps because ofthem—the job of the technology-focused project manager is amongthe most rewarding career choices. It presents challenging workwith important consequences. It involves the latest in technology. Itoffers the opportunity to work with a quality group of associates.And over the years, its practitioners have generated a large numberof truly enormous successes.

THE LURE OF PROJECT MANAGEMENT

This brings me to the broader observation that the project man-ager ’s job, in my opinion, is one of the very best jobs anywhere.Whether one is working at the Department of Defense, NASA, or aprivate company, the project manager ’s job offers opportunitiesand rewards unavailable anywhere else. Being a project managermeans integrating a variety of disciplines—science, engineering,development, finance, and human resources—accomplishing animportant goal, making a difference, and seeing the result of one’swork. In short, project management is “being where the action is”in the development and application of exciting new technologiesand processes.

The principles of successful project management—picking thebest people, instilling attention to detail, involving the customer,and, most importantly, building adequate reserves—are no secret,but what is often missing in the literature on the subject is a

FOREWORD TO THE SECOND EDITION ix

cott_a01ffirs.qxd 7/1/05 4:06 PM Page ix

x FOREWORD TO THE SECOND EDITION

comprehensive, easy-to-understand model. This is one of the manycompelling aspects to Visualizing Project Management. The authorshave taken a new, simplified approach to visualizing project man-agement as a combination of sequential, situational management ac-tions incorporating a four-part model—common vocabulary,teamwork, project cycle, and project management elements. Thebeauty of their approach is that they portray management complex-ity as process and discipline simplicity.

Kevin Forsberg, Harold Mooz, and Howard Cotterman are emi-nently qualified to compose such a comprehensive model for suc-cessful project management. They bring a collective experienceunmatched in the commercial sphere. One author has spent his en-tire career in the high-tech commercial world; the two others havemore than 20 years each at a company (Lockheed Corporation,which is part of the new Lockheed Martin Corporation) that estab-lished a reputation strongly supporting the role of the project man-ager. Collectively, the authors have spent many years successfullyapplying their “visualizing project management” approach to com-panies in both the commercial and the government markets. Theirtechnical skill and work-environment experience are abundantly ap-parent in the real-world methodology they bring to the study andunderstanding of the importance of project management to the suc-cess of any organization.

SUMMARY

As corporate executives and their counterparts in the public sectorexpect project managers to assume many of the responsibilities offunctional management—indeed, as we look to project managers tobecome “miracle workers” pulling together great teams of special-ists to create products of enormous complexity—we need to makesure that the principles and applications of the project managementprocess are thoroughly understood at all levels of the organizationalhierarchy. This book will help executives, government officials,project managers, and project team members visualize and then suc-cessfully apply the process. I recommend this book to all those whoaspire to project management, those who must supervise it in theirorganizations, or even those who are simply fascinated with howleading-edge technologies make it out of the laboratory and into themarket.

—Norman R. Augustine

cott_a01ffirs.qxd 7/1/05 4:06 PM Page x

FOREWORD TO THE SECOND EDITION xi

Norman Augustine retired in 1997 as Chair and CEO of Lockheed Mar-tin Corporation. Upon retiring, he joined the faculty of the Departmentof Mechanical and Aerospace Engineering at Princeton University. Ear-lier in his career he had served as Under Secretary of the Army and priorto that as Assistant Director of Defense Research and Engineering. Mr.Augustine has been chairman of the National Academy of Engineeringand served nine years as chairman of the American Red Cross. He has alsobeen president of the American Institute of Aeronautics and Astronauticsand served as chairman of the “Scoop” Jackson Foundation for MilitaryMedicine. He is a trustee of the Massachusetts Institute of Technologyand Johns Hopkins and was previously a trustee of Princeton. He serves onthe President’s Council of Advisors on Science and Technology and is aformer chairman of the Defense Science Board. His current corporateboards are Black and Decker, Lockheed Martin, Procter and Gamble, andPhillips Petroleum. He has been awarded the National Medal of Technol-ogy and has received the Department of Defense’s highest civilian award,the Distinguished Service Medal, five times. Mr. Augustine holds an MSEin Aeronautical Engineering from Princeton University.

cott_a01ffirs.qxd 7/1/05 4:06 PM Page xi

cott_a01ffirs.qxd 7/1/05 4:06 PM Page xii

About the Authors

Kevin Forsberg, PhD, CSEP, is co-founder of The Center for Sys-tems Management, serving international clients in project manage-ment and systems engineering. Dr. Forsberg draws on 27 years ofexperience in applied research system engineering, and projectmanagement followed by 22 years of successful consulting to bothgovernment and industry. While at the Lockheed Palo Alto, Califor-nia, Research Facility, Dr. Forsberg served as deputy director of theMaterials and Structures Research Laboratory. He earned the NASAPublic Service Medal for his contributions to the Space Shuttle program. He was also awarded the CIA Seal Medallion in recogni-tion of his pioneering efforts in the field of project management. He received the 2001 INCOSE Pioneer Award. Dr. Forsberg is an INCOSE Certified Systems Engineering Professional. He receivedhis BS in Civil Engineering at Massachusetts Institute of Technol-ogy and his PhD in Engineering Mechanics at Stanford University.

Hal Mooz, PMP and CSEP, is co-founder of The Center for Sys-tems Management, one of two successful training and consultingcompanies he founded to specialize in project management andsystems engineering. Mr. Mooz has competitively won and success-fully managed highly reliable, sophisticated satellite programsfrom concept through operations. His 22 years of experience inprogram management and system engineering has been followedby 24 years of installing project management into federal agencies,government contractors, and commercial companies. He is co-founder of the Certificate in Project Management at the Univer-sity of California at Santa Cruz and has recently developed coursesfor system engineering certificate programs in conjunction withOld Dominion and Stanford Universities. He was awarded the CIASeal Medallion in recognition of his pioneering efforts in the fieldof project management and received the 2001 INCOSE Pioneer

xii i

cott_a01ffirs.qxd 7/1/05 4:06 PM Page xiii

Award. Mr. Mooz is a PMI certified Project Management Profes-sional (PMP) and an INCOSE Certified Systems Engineering Pro-fessional (CSEP). Mr. Mooz received his ME degree from StevensInstitute of Technology.

Howard Cotterman has served The Center for Systems Manage-ment in capacities ranging from project manager to president, andhas held executive positions at leading technology and aerospacecompanies, most recently as vice president of Rockwell Interna-tional. Mr. Cotterman has successfully managed a broad range ofsystem, software, and semiconductor projects, including Intel’s fam-ily of microcomputers and peripherals. His 36 years of project man-agement experience began with the development of IBM’s firstmicroprocessor in the mid-1960s and includes research, develop-ment, and manufacturing projects as NCR’s Director of AdvancedDevelopment and at Leeds & Northrup where he was Principal Sci-entist. Mr. Cotterman was co-founder of Terminal Communications,Inc. and founder of Cognitive Corporation, specializing in knowl-edge management and online training. Mr. Cotterman received hisBS and MS degrees in Electrical Engineering from Purdue Univer-sity where he was a Sloan Fellow.

xiv ABOUT THE AUTHORS

cott_a01ffirs.qxd 7/1/05 4:06 PM Page xiv

Acknowledgments

The process models, best practices, and lessons learned embodiedin Visualizing Project Management have been significantly en-

riched and refined in this Third Edition by collaboration among themany new contributors and by the reinforcement from successfulproject management and systems engineering practitioners.

We particularly wish to acknowledge the following contributors:Ray Kile for articulating the cause and effect relationships amongthe visual models, process improvement, and the achievement ofpeak performance; Frank Passavant for sharpening the core systemsengineering messages, and particularly for his thoughtful and in-depth critique of requirements management and the Dual Vee; andJohn Chiorini for clarifying the synergies among our primary mes-sages and those of the PMI® PMBOK® Guide and INCOSE SystemsEngineering Handbook. We appreciate the substantial subject mat-ter expertise contributed by Ray Kile relating to the SEI-CMMI®

and cost estimating; by Jim Chism in clarifying the role of UML andSysML; and by Jim Whalen’s DoD 5000 insights. We thank MarshaFinley for helping to identify the 100 most commonly misunderstoodterms; Greg Cotterman for his contributions to Part I and to manu-script production; and Chris Fristad for his perspectives on thePMI® PMBOK® Guide and OPM3®. We are grateful to Neal Golubfor agreeing to add his software project planning and estimationtemplates to our downloadable template database.

xv

cott_a01ffirs.qxd 7/1/05 4:06 PM Page xv

cott_a01ffirs.qxd 7/1/05 4:06 PM Page xvi

Contents

Introduction Using Visual Models to Master Complex Systems xxi

Part OneUsing Models and Frameworks to

Master Complex Systems

1 Why Are Project Requirements a Critical Issue? 3

Maintaining consistency of the business case, the project scope, and customer needs

2 Visualizing the Project Environment 8

Using systems thinking to understand and manage the bigger picture

3 Modeling the Five Essentials 19

Visualizing the critical relationships in managing projects

Part TwoThe Essentials of Project Management

4 Organizational Commitment 37

Ensuring success with management support, quality environment, and needed resources

5 Project Communication 48

Communicating clearly, completely, and concisely

6 Teamwork 69

xvii

cott_a02ftoc.qxd 7/1/05 3:49 PM Page xvii

xviii CONTENTS

Maximizing team energy and output

7 The Project Cycle 84

Understanding the steps and gates in every project life cycle

8 The Ten Management Elements 129

Comprehending the relationships among the techniques to be appliedthroughout the cycle

Part ThreeThe Ten Management Elements in Detail

9 Project Requirements 137

Ensuring satisfied users by determining and delivering what’s wanted

10 Organization Options 167

Selecting and adapting the structure for the project

11 The Project Team 181

Getting the right people

12 Project Planning 196

Determining the best way to get there

13 Opportunities and Their Risks 223

Seeking and seizing opportunities and managing their risks

14 Project Control 254

Making sure the right things happen and the wrong things don’t

15 Project Visibility 278

Providing project transparency for everyone involved

16 Project Status 292

Discovering the problems

17 Corrective Action 312

Fixing the problems

cott_a02ftoc.qxd 7/1/05 3:49 PM Page xviii

CONTENTS xix

18 Project Leadership 319

Motivating and inspiring the team

Part FourImplementing the Five Essentials

19 Principles and Tactics for Mastering Complexity 341

Implementing the technical development process

20 Integration, Verification, and Validation 361

Delivering the right thing, done right

21 Improving Project Performance 381

Moving beyond success

Appendixes

A Web Site for Forms and Templates 401

B The Professional and Standards Environment 403

C The Role of Unified Modeling Language™ in Systems Engineering 409

D A Summary of the Eight Phase Estimating Process 415

E Overview of the SEI-CMMI 421

Glossary One Hundred Commonly Misunderstood Terms 427

Notes 435

Index 441

cott_a02ftoc.qxd 7/1/05 3:49 PM Page xix

cott_a02ftoc.qxd 7/1/05 3:49 PM Page xx

xxi

Introduction

USING VISUALMODELS TO MASTERCOMPLEX SYSTEMS

The traditional telephone is heading for extinction—one morecasualty of the Internet and evolution. Consider how quicklythe cell phone grew from its modest beginnings as a mobileversion of Alexander Graham Bell’s telephone to being acomplex entertainment, knowledge management, andcommunications system. But technology advance representsthe most manageable facet of the complexity growth.Consider the business and social implications. Your boss willbe able to contact you no matter where you are. Vacationswill exist in name only.

While some organizations cite complexity as an excusefor late, flawed, and overrun projects, others welcome thechallenge and strive to simplify and manage complexity as acompetitive advantage. This book is dedicated to masteringcomplexity.

“The ability to simplify meansto eliminate the unnecessaryso that the necessary mayspeak.”

Hans Hoffman1

IT’S ALARMINGLY COMMONPLACE FORPROJECT TEAMS TO FAIL

Almost daily we are made aware of projects that have failed orhaven’t met customer expectations. Past examples include Iridium,Globalstar, and many others where the technical solution worked asspecified but the business case was never realized. The EnglishChannel tunnel has never achieved predicted revenues and theBoston “Big Dig” has overrun its $2.6 billion budget many times over

cott_a03flast.qxd 7/1/05 3:49 PM Page xxi

xxii INTRODUCTION

($14.6 billion and counting). At the other extreme, billions of dollarsin failed projects have been attributed to minor technical problems,such as a missing line of code or crossed wires. Concurrent with thesetroubled projects are those that meet or exceed expectations. TheOlympics are perhaps the best examples. Except for isolated instancessuch as Montreal, they routinely accomplish difficult objectives ontime and usually with substantially—sometimes surprisingly—higherprofits (Los Angeles Olympics profit was $100,000,000—ten timesthat expected). Product introductions such as the Apple iPod and theToyota Lexus are among the excellent examples of projects that werevery well executed.

Widely varying project results would lead one to conclude—quite correctly—that project success is too often dependent on thespecific team. But any team can succeed when it is committed to im-proving its processes and applying the fundamentals of project man-agement and systems engineering comprehensively, consistently, andsystematically.

RESPONDING TO THE ULTIMATE “WHY?”

Ironically, most of the billions of dollars lost in high-tech projectfailures have been traced to low-tech causes. Following each failurethere is usually an extensive analysis that seeks to identify the rootcause. Here’s a representative list of reported root causes:

• No one communicated a change in design.• A piece part was not qualified.• A line of software code was missing.• Two wires were interchanged.• Unmatched connectors were mated.• A review or decision gate was skipped.

We have only to ask “Why?” to see that these are symptoms ofthe real root cause. They are human errors—the results of behavior.Why wasn’t the change communicated? Was it fear of interrogation?Why wasn’t the part qualified? Was it a cost savings? And whyweren’t the interchanged wires detected? Was it incompetence orexpediency? These are the ultimate “Whys?” that should be an-swered for every failed project. Chapter 4 addresses this question ina cultural context.

Since projects and projectteams are temporary, theirperformance may be incor-rectly attributed to the luck ofthe draw.

cott_a03flast.qxd 7/1/05 3:49 PM Page xxii

INTRODUCTION xxiii

WHY DO COMPLEX SYSTEMS HAVE A DISMALPROJECT PERFORMANCE RECORD?

Failure often results from f lawed perception of what is involved insuccessfully managing complex system development from inceptionthrough completion. Even experienced managers often disagree onimportant aspects, like the blind men who encounter the elephantand reach different conclusions concerning the nature of the beast.In the parable, the man feeling the tail concludes the elephant is likea rope, while the man holding the trunk decides the elephant is likea snake. Project reality is such a complex organism that personal ex-perience alone can result in biased and f lawed views.

Being temporary, projects often bring together people unknownto each other. The newly formed group usually includes specialistsmotivated by the work itself and by their individual contributions.Teams of highly skilled technicians can make costly errors—even

Visualization without confirmation

through a common language can produce

a flawed vision of reality. The results can

be equally misleading whether we see the

world through the optimist’s rose-colored

glasses or through a “buggy” lens as this

Far Side cartoon depicts. (THE FAR SIDE ©

1994 FARWORKS, INC./Dist. by UNIVER-

SAL PRESS SYNDICATE. Reprinted with

permission. All rights reserved.)

cott_a03flast.qxd 7/1/05 3:49 PM Page xxiii

xxiv INTRODUCTION

Improved visualization andintuition can be developedwith time and training.

fatal ones—simply because the members fail to understand or inter-nalize a systematic approach for applying best practices to projectmanagement. A major factor critical to project success is the avail-ability of an effective and intuitive management process—one thegroup will quickly buy into and build their team upon.

VISUALIZATION: A POWERFUL TECHNIQUE FORACHIEVING HIGH PERFORMANCE

No matter how much intuition you have, you can’t rely on personal ex-perience alone as you navigate through the increasingly complex anddynamic environment of projects. On the other hand, management ex-cellence cannot simply be taught any more than excellence in Olympicgymnastics or being a great artist. Fortunately, complex systems do notrequire complex management, quite the contrary. The most effectiveproject managers are able to decompose the apparent complexity oftheir project environment in order to view it more simply.

Psychologists agree that most people have insight and creativeabilities far beyond those used routinely. This has been attributed tochildhood education that favors left-brain (logical) modes of think-ing, while downplaying the right brain’s creativity. Albert Einsteinis just one of many people believed to have overcome traditionalWestern society left-brain learning patterns. He was able to “see”three-dimensional pictures in his mind before he wrote equations.He emphasized the importance of visualization to his own workingmethods. Everything he did on the theory of relativity was alreadyin the literature, but other physicists just couldn’t visualize how toput it all together. Experts now believe that visualization, and thesubsequent intuition improvements from right-brain thinking, canbe developed with time and training.

Visualization can be a powerful technique for achieving highperformance and success in business as it is in fields such as sports.Top athletes often perform successfully in their minds before com-peting. They experience their winning achievement visually—seeit—even feel it. NASA researcher Dr. Charles Garfield reports thatmost peak performers are visualizers. Business people who need topersuade others, such as salespeople or entrepreneurs, prepare forthe responses they expect by visualizing scenarios of their situation.Visualization—a right brain activity—is a vital characteristic of lead-ership, another right brain activity. We employ this technique to gaininsight into the logical and systematic project management and sys-tems engineering environments and processes—left brain activities.

cott_a03flast.qxd 7/1/05 3:49 PM Page xxiv

INTRODUCTION xxv

From road maps to wind tun-nels, models help us avoidcostly errors and dead ends—that is, if we’re correctly mod-eling the right things.

THE SIMPLIFYING POWER OF MODELS

Visual models enable us to see the big picture. They provide a pow-erful language for comprehending each key element in the projectenvironment and for visualizing how each element relates to thewhole and to the others:

• Models help us to explain and to understand how things work bysimplifying complexity. Models enable us to visualize and char-acterize what to expect. What young science student hasn’tbeen enlightened by a physical model of the reciprocating en-gine or of a molecule?

• Models can broaden our perspective as does a desktop globe ora model of the solar system.

• Models provide a common conceptual frame of reference just asa common vocabulary does for communications.

• Models can express rules and ideas more simply, models like pic-tures are worth more than a thousand words.

• Models clarify relationships, identify key elements, and elimi-nate confusion factors. In Thomas Kuhn’s words, “. . . all modelshave similar functions. Among other things they supply thegroup with preferred and permissible analogies or metaphors.”

The appropriate models help avoid costly errors that can lead tofailure. One of the major sources of project failure is f lawed re-quirements and scope management. Models of the project environ-ment, therefore, need to address the development and managementof project requirements. Continuing to work on the project solutionwith an insufficient understanding of stakeholder requirements anda deficient requirements development process often leads to expen-sive time delays and redesigns. This doesn’t have to be the case. Astrong requirements development and management process modelcan provide that ounce of prevention.

THE INTEGRATED PROCESS MODEL

The most popular models in the development project environmentfocus either on project administration, technical development, orprocess improvement, often to the exclusion of the other areas.

All too often projects proceed with innovation and sophisticateddevelopment without paying heed to the evolving business case. Fur-thermore, the managers of supporting subsystems or items usually

Model: A representation of thereal thing used to depict a pro-cess, investigate risk, or toevaluate an attribute.

“The power of a scienceseems quite generally toincrease with the number ofsymbolic generalizations itspractitioners have at theirdisposal.”

Thomas Kuhn

cott_a03flast.qxd 7/1/05 3:49 PM Page xxv

xxvi INTRODUCTION

To implement an effective pro-cess, any model must be intu-itive because it is impossibleto install if it can’t be quicklyunderstood and affirmed.

have little knowledge of the driving business case and of the deriva-tive cases at their level. This lack of awareness of the underlying busi-ness issues stems from inadequate collaboration between the businessand technical disciplines and can lead to a wrong project solution thatis ultimately rejected by the users, customer, or marketplace.

How then to best accommodate the evolving business case andto have it drive the technical and financial decisions throughout theproject life cycle? The answer begins with internalizing the inte-grated process model presented here, tailoring the processes, andthen putting the practices to work. The set of models presented inthese pages builds on the natural synergies of project managementand systems engineering, enabling project teams to:

• Develop new products and services that meet customer needs—the right solution the first time.

• Shorten time-to-market for new developments—effective busi-ness strategies and development tactics.

• Improve efficiency and productivity—organizational and per-sonal capability maturity.

• Establish competitive positions in national or world markets—best in class processes leading to best in class performance.

Installing an integrated project management and systems engineer-ing culture, based on the models in this book, coupled with trainingand certifying key team members has significantly improved projectsuccess rates. Moving beyond success to a strong project culture anda predictable performance improvement program can represent adistinct competitive advantage.

Navigating the Book—Exploring the Models

This book is organized with three goals in mind:

1. Visualizing what’s involved in mastering complex systems at theconcept level. Part One introduces the integrated process modelthat enables you to visualize the major relationships.

2. Internalizing the processes and understanding how to leveragethem. The chapters in Parts Two and Three correspond to thevisual process model’s building blocks and introduce supportingtactics, methods, and techniques.

3. Mastering complexity with a deeper understanding of systemsengineering principles and their application. Part Four presentsadvanced topics that prepare you to confidently accept respon-sibility for the challenges of complex projects.

The visual models presentedhere can broaden your per-spective on all aspects of yourproject, enabling you to leadfrom your right brain andmanage with your left.

Developers often focus onwhat is possible technicallyregardless of the constraintsof cost, a limiting schedule, orwhat the customer requires.

cott_a03flast.qxd 7/1/05 3:49 PM Page xxvi

P a r t O n e

UsingModels andFrameworks toMaster ComplexSystems

As in previous editions, the wheel and axle model is the center-piece—the basis for visualizing the overall project management

process and for structuring the book’s content. The theme of thebook, and our metaphor for a great project team, is a symphony or-chestra, each musician capable of solo performances, but committed

Note that the first violinist issystems engineering, theteam’s technical lead that, inproject teams, frequently setsthe pace and orchestrates thetechnical players in timing andintensity.

cott_c01.qxd 6/30/05 3:01 PM Page 1

2 USING MODELS AND FRAMEWORKS TO MASTER COMPLEX SYSTEMS

to teamwork. This edition emphasizes the pivotal role of systems en-gineering, the first violinist in the orchestra metaphor.

Visualizing Project Management, third edition, has four parts:

Part One draws on systems thinking to consider the project en-vironment, highlighting the critical role of solution and stake-holder requirements.Part Two applies our visual model to reveal the relationships andinterdependencies among the major project success factors.Part Three provides the tactics required to navigate skillfully inorder to achieve the project goals.Part Four describes how processes can best be deployed toachieve predictable performance improvements.

COPYRIGHTS AND SERVICE MARKS

PMI® and PMBOK® Guide are service and trademarks of the Proj-ect Management Institute, Inc. that are registered in the UnitedStates and other nations.

MARGIN NOTES

This third edition uses two forms of margin notes. As in previouseditions, margin notes are used to emphasize a point or to annotate adiagram, such as the systems engineering role in the first paragraph.The second form, shown here in the margin, is used to referencespecific sections of the PMI PMBOK® Guide and the INCOSE Sys-tems Engineering Handbook, Version 3 (2006).

SECTIONS

We occasionally refer to specific chapters by number and to a sec-tion nearby. Sections are delimited by headings in all caps and cen-tered, such as this one.

PMBOK ® GuideThis form of margin note isused for PMI PMBOK ® Guidereferences.

INCOSEThis form of margin note isused for INCOSE Handbookreferences.


3

1WHY ARE PROJECTREQUIREMENTS ACRITICAL ISSUE?

In the mid- to late-1980s, cellular phones had very limitedoperational range and were generally used only in large cities.A strong business case for a satellite-based mobile phone wasmade and the Iridium Program was born. By the time the 12-year development and deployment was complete, GSM cellulartechnology had matured and spread through all markets. Only afraction of the potential Iridium customers remained. Theconsortium, unable to pay the $5 billion debt, filed bankruptcy.A realistic business case, appropriately updated, would haverevealed that the program could not survive—and it would haverevealed the problem years before any satellites were launched.

This chapter speaks to the challenges of maintaining consistencyof the business case, the project scope, and customer needs. Sub-

sequent chapters address the many creative ways to maintain thisconsistency, including opportunity management. In the case of theIridium Corporation, opportunity seekers bought the assets for about2 percent of the original investment. By late 2004, the new team hadenlisted 100,000 customers and could be headed for success in a morelimited market and greatly reduced investment (the original IridiumCorporation needed 1.6 million subscribers to survive).

Projects and their solutions are the lifeblood of most businesses.Projects are either the main business, as in construction, or they areexpected to provide new products, as in most commercial product

“It was a painful lesson tolearn, but it was an engineer’sdream. . . . I had a great time,but, in the end, it taught me agreat lesson in businessplanning. You need tominimize the investment aswell as reduce the risks. We allneed to think in terms ofbusiness, not straightengineering anymore.”

Roger Taur1

Dr. Taur was a memberof the original Iridium

development team.

For some businesses, such asaerospace andcommunications, projectmanagement is the lifebloodof the enterprise and systemsengineering is the heart ofproject management.



Tougher competition demandsshorter time to market andsqueezes the break-even point.

companies. Whether for survival or to sustain market leadership,projects are the key to succeeding in world competition. Project suc-cess is delivering a result that does what it is supposed to; when it issupposed to; for the predicted development, operating, and replica-tion costs; and with the reliability and quality expected.

THE MARKETPLACE DYNAMICS DEMAND MORERESPONSIVENESS AND AGILITY

Marketplace shifts often force abrupt changes of direction. Longerprojects face particularly elusive targets. Budget and contingencyplanning rarely account adequately for market shifts and scheduleslips. A prolonged project can face inf lated labor and material costsand eroded prices when it eventually shoulders its way into the mar-ketplace. Competitive danger signs include:

• Shorter market windows with higher risks.• More contenders carving available markets.• Pricing pressure reducing profit margins.• Plethora of emerging technologies.

Conditions such as inf lation/recession cycles, lack of borrowingpower, and stockholder pressures have always existed, but not sotightly coupled with technology shocks and worldwide competition.Diversionary pressures include:

• High rate of technology change.• More attention to legal, ethical, and fair conduct.• Greater international involvement.• Internet-based worker mobility.

The only certainty is uncertainty, especially with regard to proj-ect requirements. The Agile Alliance, an organization formed to ad-dress the conf licting demands on software developers, has issued aset of principles and practices to deal with changing requirements.This excerpt of their principles acknowledges the inevitability ofchanging requirements:

• Requirements are not negotiated up front, but rather evolve as aresult of constant collaboration between the customer and de-velopment team.

• Welcome changing requirements, even late in development.• Agile processes harness change for the customer ’s competi-

tive advantage.

Outside influence ispersistent—an increasingdistraction.


WHY ARE PROJECT REQUIREMENTS A CRITICAL ISSUE? 5

Business and technicalconflicts are usually resolvedthrough trade studies,negotiation, or similarprocesses.

These tactics do apply to some environments, especially in smallerprojects, but they could lead to failure in others. Development tac-tics are addressed in Chapters 7 and 19.

PROJECT SUCCESS DEPENDS ON DELIVERING THERIGHT SOLUTION, DONE RIGHT—THE FIRST TIME

We refer to the purpose and final result of any project as the solu-tion. Delighting the customer with the right solution could be deliv-ering a product or service as expected, or even resolving a problem.“Done right—the first time” means it was developed as intendedwithout burning out the team.

Projects usually exist to address a business opportunity; there-fore, to achieve project success, all decisions must be consistentwith the business case (also known as the mission case for some gov-ernment projects). It is often difficult to achieve cooperation andbalance among the business and technical aspects. Business casesand technical issues are often subject to conf licting priorities andexternal forces, such as those in the previous section.

MANAGE REQUIREMENTS TOMANAGE THE PROJECT

The Project Management Institute (PMI), the leading certificationbody for project management, defines project management as: Theapplication of knowledge, skills, tools, and techniques to project ac-tivities to meet project requirements. Seasoned project teams viewmanaging requirements and the project scope as the most critical el-ements of managing the project. The project and its requirementsstart with expressed needs and end only when those needs are satis-fied as evidenced by successful user validation. Chapter 9 covers theend-to-end chain of technical and business development.

Once technical and business requirements are established as con-sistent, the balance (referred to as congruency) needs to be main-tained. The budget and schedule must enable achievement of thetechnical requirements. Conversely, the technical requirements mustbe achievable within the budget and schedule. Projects without con-gruency at the outset are usually doomed and unrecoverable unlessthe inconsistencies are resolved very early (Figure 1.1). In some in-dustries, projects of this type are known as a “suicide run.” Through-out a project’s duration, there is continual pressure to change the

Nonessential or overspecifiedrequirements frequently resultin missing schedule and costtargets.



Figure 1.1 The “suicide run.” Reprinted by permission of United Feature Syndicate, Inc.

established agreements. Schedules are compressed, available re-sources decreased, and technical features added. The project teammust be able to recognize and respond to serious inconsistencies.When implementing schedule, budget, and technical changes, congru-ency must be reestablished or the project will fail.

REQUIREMENTS MANAGEMENT: THEINTERSECTION OF PROJECT MANAGEMENT

AND SYSTEMS ENGINEERING

Why are project requirements a critical issue? The answer to thisquestion lies partially in the pervasiveness of the requirements, thediverging interests of project stakeholders, and confusion over roles.Just as we have done up to this point, stakeholders talk about man-aging requirements without a common understanding of just what—and who—it involves (Figure 1.2).

The two key stakeholders on the project team are the projectmanager and the systems engineer. The previous section beganwith the PMI’s definition of project management, which empha-sized the role of requirements. While we support and applaudthat emphasis, our definitions that follow ref lect the interdepen-dency of project management and systems engineering in regardto managing requirements.

Project management: The process of planning, applying, andcontrolling the use of funds, personnel, and physical resourcesto achieve a specific result.Systems engineering: The process of managing requirements toinclude user and stakeholder requirements, concept selection,architecture development, requirements f lowdown and trace-


WHY ARE PROJECT REQUIREMENTS A CRITICAL ISSUE? 7

Figure 1.2 Requirements management: The intersection defined.

ability, opportunity and risk management, system integration,verification, validation, and lessons learned.Requirements management: Management of the project busi-ness, budget, and technical baselines. The objective is to keepthe three baselines congruent. The process includes baselinechange management and authorization. Also included are re-quirements f lowdown, traceability, and accountability.

The business case and the systems engineering managementprocess provide the framework for requirements management—theplace where project management and systems engineering intersect.

In many environments, project managers are held accountablefor the cost and schedule performance of their projects even thoughthe technical solution is being developed outside of their range ofauthority. Because the solution development usually consumes thelargest portion of the budget and determines the schedule, this con-dition is likely to be unmanageable. Fortunately, this situation ischanging as project management takes center stage and the projectmanager ’s role becomes better understood.

In environments where project managers are responsible forthe development and deployment of the solution, the project man-ager should be skilled in the orchestration of solution development(systems engineering) or closely share that responsibility with some-one who is.

The next chapter examines the intersection between projectmanagement and systems engineering in the context of the overallproject solution environment.

In a recent meeting of one ofthe largest PMI chapters, only22 percent reported havingresource control.


8

2VISUALIZINGTHE PROJECTENVIRONMENT

Solutions to devastating events, such as forest fires, illustratethe power of systems thinking (Figure 2.1). For manydecades, the conventional wisdom for controlling forest fireswas to prevent them. This led to unacceptable fuelaccumulation and even greater devastation over the longterm when the accumulation did ignite in an uncontrollablerage. By considering the bigger picture, preemptivecontrolled burns emerged as the best solution. Similar biggerpicture approaches have been used successfully for solvingpest control and flooding threats.

When we fail to grasp the systemic source of problems, we areleft to treat symptoms rather than eliminate underlying

causes. Without systemic thinking, the best we can ever do is adaptor react. Systems thinking, powered by visual models, stimulatescreative—rather than adaptive—behavior.

On most complex system development projects, the systems engi-neer is the champion and curator of the big picture, including the cus-tomer’s perspective of the problem and the solution. To benefit fromsystems thinking, the project team needs to extend that viewpointupward to the bigger picture of the project’s overall environment.

Systems thinking encompasses critical thinking, solutionsthinking, future and forward thinking, longer-term thinking, and

Systems thinkers see the rootcauses and courses of actionthat control events.


VISUALIZING THE PROJECT ENVIRONMENT 9

high-level thinking. It is not analytic thinking, which is tactical andparts oriented. To illustrate the stretch in our training events, weask the participants to picture the class they are in as a system andto identify its major elements. The first responses typically focus onthe actors, the materials, and the dynamics of the event itself. Byasking the participants to consider everything they bring into theclassroom, including environmental factors, the brainstorming ses-sion leads to a result similar to the bigger picture illustrated in Fig-ure 2.2.

By providing frameworks and perspectives for systems thinking,models enable us to visualize the big picture, which is so vital toproject management and systems engineering. In this chapter, weemploy systems thinking to model and visualize the system solutionenvironment to provide context as we zoom in on the area withinwhich most of the system development decisions will be made, re-ferred to as the trade-off area or, more simply, the trade space.

The final result of any project is a product, service, or even aproblem resolution, all of which we refer to as the system solution.In the vernacular of systems thinking, a system and the project solu-tion are used interchangeably.

Figure 2.1 Systems thinkers take a broader view of the world. Adapted from Systems Thinking Playbook, Linda Booth Sweeney and DennisMeadows, 1995.



This next section characterizes the overall environment and spacewithin which the solution is created in terms of:

• The available trade space.• Models, frameworks, lessons learned, and best practices.• Project stakeholders.

Subsequently, the remainder of this chapter zooms back out to thebig picture to address the opportunities, risks, and ultimate payofffor those whose future depends on moving beyond project success tohigher levels of performance:

• The professional atmosphere.• Opportunities and risks.• The payoff.

ZOOMING IN ON THE SOLUTION TRADE SPACE

Trade-off studies are used to select the best solution by evaluatingthe alternative concepts and architectures against a set of criteria.The trade-offs are performed within the project’s trade space—the area bounded by project and solution constraints, as shown inFigure 2.3.

Figure 2.2 Systems thinking focuses on relationships, multiple outcomes,

holism and boundaries, the environment, the larger system, and feedback.

cott_c02.qxd 6/30/05 3:11 PM Page 10


Figure 2.3 The trade-off area at the core of the environment.

Environment

and

THETRADESPACE

Models, frameworks, and best practices inf luence the tacticalapproach and processes to be applied within the solution space.While these three terms are often used interchangeably, they aremost valuable when their differences are understood and properlyapplied. In the context of project management and systems engi-neering, the following definitions and descriptions apply:

Models: A model is a representation of the real thing used to de-pict a process, investigate an opportunity or a risk, or evaluate anattribute. Properly constructed models are valuable tools becausethey focus attention on critical issues while stripping away lessimportant details that tend to obscure what is needed to under-stand and to manage. Because they idealize a complex situation, avariety of different models can be constructed to represent thesame situation. A useful model will be simple, but it must retainthe essence of the situation to be managed—the driving force forthe process model defined in the next chapter.Frameworks: Within the solution space, a framework is a set ofassumptions, concepts, values, and practices that constitutes away of viewing reality. The Software Engineering Institute’s(SEI) Capability Maturity Model Integrated (SEI-CMMI®) is

“Everything should be madeas simple as possible—but nosimpler.”

Albert Einstein

cott_c02.qxd 6/30/05 3:11 PM Page 11


the centerpiece of the SEI framework for assessing, rating, andsubsequently improving an organization’s performance. We dis-cuss this framework further in Chapter 21.Best Practices: Best practices are about doing what has been con-sistently demonstrated to work well—processes, procedures, andtechniques that enable project success. Best practices need to bedocumented for the purposes of sharing, repetition, and refine-ment. Best practices are usually based on lessons learned by ex-perienced project managers, as was done in developing theProject Management Institute’s A Guide to the Project Manage-ment Body of Knowledge (PMBOK® Guide).1 The PMBOK®

Guide is updated periodically through feedback from practi-tioner experiences. The behavior-based process models in Visu-alizing Project Management integrate systems engineering andproject management best practices, the latter being consistentwith the PMBOK® Guide. Figure 2.4 continues the trade spacedelineation.Figure 2.5 illustrates the solution space shrinking to the trade

space (Figure 2.3), leading to the value-driven concept. The letterson the diagrams correspond to the following:

A. Stakeholder constraints imposed.B. Legacy system conformance requirements.C. Technology limitations.D. The trade space where requirements are satisfied by performing

trade-offs among alternative solution concepts.E. The ideal concept fills out the trade space.F. Low-value features are eliminated.

From a technical perspective, the ideal concept is one that fills outthe trade space, pressing on all boundaries. However, a well-con-ceived business case provides a basis for determining the value ofoptional system features or capabilities. When low-value featuresare eliminated, the value-driven concept is realized as shown instep F of Figure 2.5. The widely practiced techniques of Value En-gineering and Cost as an Independent Variable (CAIV) promote thisapproach.

IDENTIFYING THE PROJECT STAKEHOLDERS

The next step in characterizing the solution space is identification ofthe key stakeholders or groups. The project stakeholders fall intoseveral categories:

cott_c02.qxd 6/30/05 3:11 PM Page 12

13

Figure 2.4 The project environment boundaries.

The project environment is shown bounded by the relevant lessons learned. Process frameworks, best practices, and industry standards are depicted as overlapping areas.

User #3 Needs,

Expectations,and Solutions

User #2 Needs, Expectations,

and Solutions

User #1 Needs,

Expectations,and Solutions

Environment

Organization’sBest Practices

FrameworksSEI-CMMI,Six Sigma

Industry Best Practices

PMI, INCOSE,Agile Alliance

IndustryStandards

ISO, EIA, IEEE

Environment

The various user needs are overlaid, which may very well extend beyond the previously defined solution space in violation of either lessons learned or best practices.

When the boundaries imposed by the Business Case and User CONOPS (Concept of Operations) are defined, all of User #3’s needs can be incorporated, but not all of the others.

cott_c02.qxd 6/30/05 3:11 PM Page 13


• Customers and users.• Project participants.• Marketplace.• Professional societies, regulatory bodies, and standards organi-

zations.

The customers and users could be the same, but they are frequentlydifferent. For example, the project’s customer could be the sponsor-

Figure 2.5 Getting to the value-driven solution concept.

Environment

Stakeholder Constraints

Legacy System

TechnologyLimitations

Legacy

Technology

Stakeholders

System Requirements

andConcept Trade

Space

Value-Driven

Concept

IdealSystem Concept

cott_c02.qxd 6/30/05 3:11 PM Page 14


ing organization’s internal marketing department, which is servingas an intermediary for the final user or consumer of the projectproduct or service.

Project participants include the core stakeholders: the projectteam, sponsoring enterprise, internal customers (such as the mar-keting/sales department), and functional organizations.

The marketplace has two key stakeholders: sales channels andcompetitors.

Professional societies, regulatory bodies, and standards organiza-tions exert significant inf luence on project practitioners, the projectvocabulary, and the solution space. Several of the key organizationsare listed here and the most inf luential are profiled in Appendix Band in Part Three of our book Communicating Project Management.2

ASAPM—American Society for the Advancement of ProjectManagementDoD—U.S. Department of DefenseEIA—Electronics Industries AllianceIEEE—Institute of Electrical and Electronics EngineersIIE—Institute of Industrial EngineersINCOSE—International Council on Systems EngineeringIPMA—International Project Management AssociationISO—International Organization for StandardizationPMI—Project Management InstituteSEI—Software Engineering InstituteSESA—Systems Engineering Society of Australia

THE PROFESSIONAL ATMOSPHERE

A large number of professional organizations and societies sharetheir lessons learned, develop their own best practices, and offervarious forms of support and mentoring to their members. Theyrange in size from the Agile Alliance to the 28 separate professionalsocieties that make up the half-million-member Institute of Electri-cal and Electronics Engineers.

The Agile Alliance is of particular interest because its methods(such as Extreme Programming) and feature-driven tenets are fre-quently misunderstood to conf lict with a structured frameworksuch as the SEI-CMMI. We view Agile methods as means for opti-mizing requirements f lexibility and discovery while concentratingon constant improvement of the team’s development practices.

cott_c02.qxd 6/30/05 3:11 PM Page 15


From this perspective, agility may actually help an organization inachieving its capability and process maturity goals.

The SEI mission is to advance the practice of software engineer-ing and to make predictable the acquiring, developing, and sustainingof software-intensive systems, from design through operation. Theintegrated systems engineering/hardware/software CMMI ProductSuite was introduced in August 2000 to replace the Software Capabil-ity Maturity Model (SW-CMM) in use since 1987.

The SEI is one of the three professional organizations that,through continued growth in scope, inf luence, and collaboration,are expected to shape the future of the professional surroundingsfor projects. The Project Management Institute (PMI) and the In-ternational Council on Systems Engineering (INCOSE) representthe project management and systems engineering professional com-munities, respectively.

INCOSE expanded to international scope in 1995 and launchedits Certified Systems Engineering Professional (CSEP) certificationprogram in August 2004. The INCOSE Systems Engineering Hand-book, the organization’s certification guide, is referenced in marginnotes throughout Parts Two and Three of this book using the IN-COSE designation.

Holding a PMI PMP certification is the de facto basis for judg-ing an individual’s knowledge about project management, especiallyin the United States.

Professional certification of project managers and systems engi-neers is a strong short-term driver for career growth and personaldevelopment. Enlightened practitioners see certification as a meansto establish and maintain their life skills rather than as an end in it-self. For organizations, certification sponsorship represents a power-ful motivator for establishing a culture of professionalism andpersonnel development.

OPPORTUNITIES AND RISKS

As the professional atmosphere improves, so does the local climate.Project practitioners can look forward to increasing opportunities tobroaden their inf luence, enrich their knowledge, sharpen theirskills, and advance their careers in the emerging era of professionalcollaboration. But we’re not quite there.

Bad Habits Were Learned and Barriers Were Built

It starts with the universities and other institutions of higher learn-ing that separate their Schools of Business from their Schools of

cott_c02.qxd 6/30/05 3:11 PM Page 16


Engineering. New graduate engineers are ushered into the engi-neering environment and situated among other engineers—likewisethe new recipients of a master ’s degree in business administration(MBAs) move into the nontechnical side of the business. Similarly,engineering and business staffs are often located in different build-ings—possibly in different campuses or cities. Business and techni-cal collaboration, if present at all, is not emphasized or facilitated.The barriers between disciplines grow. In many companies, organi-zation structures keep technical and business management apartuntil the second level of management. It is often impractical tobridge the gap without abandoning one’s career path.

Historically, associated professional organizations have furtherexacerbated this situation by not having a common vocabulary andnot engendering collaboration.

Finally, technical and business professionals frequently establishtheir own independent customer contacts, each believing the otherdoesn’t really know how to communicate with their custormer. In-stinct replaces understanding, and when the product fails to satisfy,it is often attributed to the customer’s “lack of appreciation.”

Getting rid of past bad habits begins by recognizing them.

Breaking the Barriers—A Future of Collaboration

and Integration

The concept of ensuring business-driven technical decisionsthroughout the project by integrating project management and sys-tems engineering, while not new, is receiving renewed interest andinvestment in academic, government, and commercial venues. Sev-eral major universities, including MIT, Stevens Institute, and Stan-ford, are offering coordinated project management and systemsengineering programs or are aggressively preparing to do so.

The growing professionalism, certification, and recognitionof the systems engineering practice by INCOSE are deliber-ate steps to clarify the systems engineering role and recognize itssignificance.

The SEI provides a comprehensive framework for assessing anorganization’s system development process maturity and for estab-lishing an integrated processes culture from the project to the enter-prise level. Furthermore, the SEI-CMMI promotes blending of theengineering management disciplines and processes.

One of the primary purposes of this book is to encourage broadercollaboration among individuals and between the disciplines.

While this transformation is breaking down historical barriersat the institutional level, the real change agents are the readers of

cott_c02.qxd 6/30/05 3:11 PM Page 17


this book who have a vested interest not only in acquiring the skillsfor mastering complex systems, but also in realizing the payoff.

THE PAYOFF: PERFORMANCE IMPROVEMENT

Near-maximum productivity improvements have already beenwrought from conventional skills training and capital improvementssuch as computers and knowledge management. The integration ofproject management, systems engineering, and process improvementis being widely recognized as the wave of the future—the bestmeans to improve project performance and ensure career advance-ments. Forward thinking organizations are laying a new keel basedon this premise, which is the focus of Chapter 21.

cott_c02.qxd 6/30/05 3:11 PM Page 18

19

3MODELING THEFIVE ESSENTIALS

“Treasure hunters had no control. . . . They were subject totoo many whims . . . that is why most of them failed.”1

Treasure-hunt projects are notorious for ad hoc management.By contrast, the story of the search for the SS CentralAmerica and the recovery of its treasure, as told in Ship ofGold by Gary Kinder, is one of the most dramatic illustrationsof the power of blending business opportunity leadershipwith systematic engineering approaches.2 During the earlystages of the feasibility study, one of the key stakeholdersmade this observation: “Einstein didn’t create anything new,”said Glower. “Everything he did on the theory of relativitywas already in the literature, but other physicists just didn’tquite see how to put it all together.”

This chapter is about visualizing “how to put it all together”—amanagement process much bigger than the sum of its parts—

once the relationships among those parts are understood.

MODELING THE INTEGRATION OF PROJECTMANAGEMENT AND SYSTEMS ENGINEERING

The process model that frames this book was developed to pro-vide a visual depiction of the integrated project management andsystems engineering processes. We characterized the behavior of

“Principles that areestablished should be viewedas flexible, capable ofadaptation to every need. It isthe manager’s job to knowhow to make use of them,which is a difficult artrequiring intelligence,experience, decisiveness, and,most important, a sense ofproportion.”

Henri Fayol3

cott_c03.qxd 6/30/05 3:10 PM Page 19


project managers, systems engineers, and teams that exhibited con-sistent successes as differentiated from behaviors that led to trou-bled and failed projects. Our resulting integrated process model iscompliant with the many practices defined in the Project Manage-ment Institute’s (PMI) PMBOK® Guide as well as those of the Inter-national Council on Systems Engineering (INCOSE).4 The model isintended to:

• Communicate how a project should be managed.• Encourage stakeholder involvement.• Orchestrate the technical development process.• Keep the health of the project transparent and available.• Encourage pursuit of high-value opportunities while managing

their risks.• Trigger swift action to address problems.

VALIDATION CRITERIA FOR THE INTEGRATEDPROJECT MANAGEMENT MODEL

Experts have identified the general criteria for effective models, towhich we have added criteria specifically for project managementand systems engineering:

• Explicitly and operationally defined structures and relationships.• Obviously valid and intuitive to all project stakeholders. If a

model has to be studied each time it’s applied, it has minimal—perhaps even negative—value. It is difficult to install a processif the model isn’t quickly understood and confirmed.

• General applicability throughout the project environment in away that accounts for the complexity and dynamics of the proj-ect processes and the driving role of project requirements.

• Differentiates sequence-driven from situation-driven manage-ment. Viewing a project solely as a sequence of phases and eventscannot properly represent management dynamics, processes,roles, and responsibilities.

• Validated empirically on real projects by real teams. This modelis a result of the experiences—both successes and failures—ofthousands of practitioners and hundreds of projects.

• Easily remembered and effectively applied.

FIVE ESSENTIALS FOR EVERY PROJECT

The dictionary defines a team as a group of people working or play-ing together to achieve a common goal. But anyone watching a

cott_c03.qxd 6/30/05 3:10 PM Page 20

MODELING THE FIVE ESSENTIALS 21

swarm of 6-year-olds playing at soccer, with each child self-focusedrather than on the team, knows that this definition is incomplete.

Imagine the challenges faced by a newly formed jazz group,composed of highly trained specialists, each capable of an excellentsolo performance. Then consider one of the freest expressions ofcreativity in music—improvisational jazz. One of the apparent mys-teries is that, while it seems free and unstructured, at the same timeit doesn’t result in uncontrolled noise. Music is produced, just assurely as music is produced by a symphony orchestra that is respond-ing to a musical score.

However, each jazz session is unique—just like a project. It isimprovisational and thus being created at the time. That music is re-liably produced by the combined efforts of a group of jazz musicianssuggests that there is an underlying process that facilitates the musi-cians in a group setting. In fact, jazz has rules. For example, eachpiece has a time signature. The musicians exercise creativity withintheir adopted boundaries and respect each other ’s contribution, justas project participants should.

When musicians of any kind come together for a short-term en-gagement they depend on five essentials:

1. Resources and environment (organizational commitment);2. A common music communications language;3. Teamwork;4. A score or plan (cycle); and5. Guidelines, rules, and techniques.

The process model for a successful project team is based on thesesame five essentials:

Organizational commitment: The foundation for the proj-ect that includes: (1) a culture responsive to the projectmanager; (2) the project team’s charter to do the job;(3) the financial and other necessary resources; and (4) thetools and training for effective and efficient execution.

Communication: The language and the techniques used bya particular person or group to achieve understanding. Inproject management, this is the essential that enables teammembers to interact effectively and function as a team.

Teamwork: Efficiently working together to achieve acommon goal, with acknowledged interdependency andtrust, acceptance of a common code of conduct, and witha shared reward.

cott_c03.qxd 6/30/05 3:10 PM Page 21


Project cycle: The project’s overall strategic and tacticalmanagement approach that is performed in periods andphases punctuated by decision events. The broadest proj-ect cycle usually starts with the identification of userneeds and ends with disposal of project products. Theproject cycle is comprised of three aspects: business,budget, and technical.Management elements: The ten categories of interactivemanagement responsibilities, techniques, and tools thatare situationally applied throughout all phases of theproject cycle by all stakeholders.

Visualizing the Relationships among the Five Essentials

To aid in understanding and communication, the visual model dif-ferentiates between practices that are ever present (perpetual),those that are sequential, and those that are situational. When view-ing the structure of each essential and the relationships amongthem, organizational commitment, communication, and teamworkare perpetual properties of the enterprise that transcend theboundaries of any single project.

The phases of the project cycle are sequential and shouldbe tailored to each project. Project success usually depends onmeeting the business objectives by performing a set of technicaltasks within an authorized budget (cost and schedule). The threeproject cycle aspects (business, budget, technical) must be kept inbalance.

The ten management element groups are situationally applied tothe management of the project through the project cycle. There areseveral hundred techniques (practices such as using a spreadsheet orGannt chart to depict a schedule) and tools (the means to perform atechnique, such as Microsft Excel or Microsoft Project software)that successful project management and systems engineering practi-tioners use to address project situations. By grouping related tech-niques, we can identify homogeneous management elements. Forinstance, the work breakdown structure (WBS), WBS dictionary,project network diagrams, critical path analysis, scheduling, esti-mating, and others naturally fit into the planning element. Similarly,the techniques of measuring cost, schedule, and technical perfor-mance fit within the Project Status group. Iteration until all tech-niques and tools fit naturally into homogeneous specialties results ina ten-element structure.

The several hundredsuccessful techniques andtools for both projectmanagement and systemsengineering fit naturally intoten homogeneous groups.

cott_c03.qxd 6/30/05 3:10 PM Page 22


Figure 3.1 Management elements.

Techniques and tools are located within the element where theirbenefit is most significant. For instance, phase transition reviews(known as decision gates) provide the team with visibility as to whatis happening, but the most significant benefit of decision gates is toprovide project baseline approval and control. Therefore, decisiongates are included in the Project Control group.

The first nine management elements are depicted as the spokesof a wheel:

1. Project Requirements,2. Organizational Options,3. Project Team,4. Project Planning,5. Opportunities and Risks,6. Project Control,7. Project Visibility,8. Project Status, and9. Corrective Action,

and are held intact by the rim, Project Leadership (Figure 3.1).The project cycle is best visualized as an axle with the three

congruent aspects—business, budget, and technical—depicted as itscore (Figure 3.2). To illustrate the relationship between the situa-tionally applied management elements and the sequential projectcycle, a third dimension is required (Figure 3.3).

cott_c03.qxd 6/30/05 3:10 PM Page 23


The wheel progressing along the axle represents the project’slogical sequence of events. Turning the dial—rotating the wheel—represents the dynamic selection and application of the technique(s)and tool(s) appropriate to the project situation at any point and toany aspect of the cycle. This sequential project cycle axle and thesituational management wheel are supported by the ever-presentpiers of communication and teamwork on a foundation of organiza-tional commitment. Without a solid foundation, the model collapsesjust as real projects do when management support and the infra-structure is inadequate.

Figure 3.2 The project cycle portrayed as an axle.

Figure 3.3 The wheel and axle model.

cott_c03.qxd 6/30/05 3:10 PM Page 24


ELABORATION OF THE WHEELAND AXLE MODEL

This model has been validated by extensive project team experienceand through its application as a template for evaluating troubled proj-ects. Assessing how project teams address each aspect of the modelcan surface deficiencies and oversights in team conduct and manage-ment processes. Clients report that they have significantly improvedproject performance by basing their culture on this model. Even themost experienced project managers express a clearer understandingof their roles and increased confidence in their project execution.

Organizational Commitment—The Springboard

for Successful Projects

Project success is rooted in the foundation support systems that en-able effective teams. That support can be demonstrated every timeexecutive management charters a new project by authorizing theleadership role(s) and resources. The foundation is solidified by anorganizational culture that recognizes project management and sys-tems engineering as a team sport with the project manager callingthe plays. The foundation is further reinforced by infrastructurethat includes tools and training to support the project team in theachievement of its specific objectives.

Forward-looking organizations are equipping their teams withboth PM and SE computer-based tools that facilitate planning andtracking of progress, technical analysis of concepts, and assistance inconducting trade studies such as decision support systems. INCOSEis currently leading the development of a common graphical templatefor expression of both requirements and concepts that will beadopted and supported by multiple tool vendors.

Enterprise culture, team behavior, and interpersonal relation-sips are key factors of the organizational commitment. The answerto the ultimate “Why?” raised in the Introduction and addressed inthe next chapter is to be found in the execution of this essential.

A useful executive management project support techniqueis monthly and /or quarterly reviews that address progress andshortcomings with the objective of helping to resolve issues thatcan benefit from higher level assistance such as added or differentresources, high-level customer communication, pressure on suppli-ers, and the like. These reviews should not be a forum for blaming

cott_c03.qxd 6/30/05 3:10 PM Page 25


and criticizing team members or they will lose their effectivenessas a positive contribution to the project team support system.

Communication Based on a Common

Vocabulary—An Ever-Present Challenge

The imagery of a jazz group or a symphony orchestra illustrates theinterdependency among the five essentials. Removal of just one es-sential leads to vulnerability and instability. For example, imaginethe confusion triggered by simple misunderstandings if you were totry to recover lost luggage in a foreign country without knowing thelanguage.

The orchestra metaphor also reminds us that most of the orches-tra’s communication is based on a graphical vocabulary (notes) andthe physical motions and facial gestures of the conductor that musi-cians understand. During a performance, no words are used, yet com-munication is timely and effective. To be an effective team member,an orchestra member must be conversant in both the graphical andphysical languages. Similarly, team members must be conversant inthe project’s languages and communication techniques. Graphicallanguages, such as the Unified Modeling Language™ (discussed inChapter 9), and tools such as Microsoft Visio and PowerPoint, aidcommunication and are commonly used in project related communi-cation. While these tools may not always create substance, they dohelp display the results of team creativity and design evolution.

We are constantly reminded of the consequences of communi-cation breakdown in our consulting and training sessions. Severalterms we use to teach the practice of project management are con-fused with similar or identical terms used, with different meaning,in the context of a domain specific business or technical field.

A prominent project management word, status, has nothing todo with prestige. The project management context is usually unam-biguous, but what troubles some people is the common practice ofusing statusing as a verb.

Vocabulary problems lead to conf lict and serious misunder-standings. Therefore, a common vocabulary is necessary before youcan effectively communicate about the project and develop the nec-essary teamwork. Furthermore, the common vocabulary of projectsshould include both project management and systems engineeringterms. Communicating Project Management, a companion to thisbook, addresses communication techniques of many types and pro-vides an integrated vocabulary with definitions for project manage-

The trend toward emergingtechnology specialties, eachwith its own language,coupled with the global andtemporary aspects of projects,necessitates the definition of acommon vocabulary for eachproject—even small ones.

All project practitioners shouldunderstand earned value andthe implications ofincremental and evolutionarydevelopment.

cott_c03.qxd 6/30/05 3:10 PM Page 26


Conflict and confusion maydrive team members intoincorrect practices—even toperforming incorrect work.

ment, systems engineering, and software engineering, including theSoftware Engineering Institute’s CMMI® glossary.5 The Glossary tothis book defines terms that are frequently misunderstood and con-tribute to confusion.

Project Teamwork among All Stakeholders

Project stakeholders consist of people and organizations that can af-fect or be affected by the project.

Teamwork is often defined as working together to achieve acommon goal. However, this definition falls short of the scope ofthe teamwork required in the project environment. The work por-tion of teamwork—that is, the creative effort needed to harness thecreativity of all stakeholders—is usually not well understood. Be-cause of this, real teamwork is only partially achieved. For teamworkto f lourish, each of the following fundamentals must be developedand nurtured:

• Common goals;• Acknowledged interdependency, trust, and mutual respect;• A common code of conduct;• Shared rewards; and• Team spirit and energy.

Most project teams, including stakeholders, fail to adequately ad-dress these teamwork factors. Of these five factors, the most oftenoverlooked is the common code of conduct. All too often, managersassume that a code of conduct is implied and understood even thoughit hasn’t been explicitly defined and agreed to by all participants. Thiscan lead to tension and separation among the team members, destroy-ing teamwork. Many authors, including Jackman6 and Kinlaw,7 haveaddressed the issues involved in achieving successful teamwork.

Without a commitment to and implementation of teamwork,daily project activity would resemble rush hour in the subway. It’sdifficult to imagine a talented group of musicians making goodmusic without a common score and a conductor. Even in self-directed teams, the leadership role is filled circumstantially bystrict adherence to proven processes supported by all team mem-bers. And while it is possible for a leaderless group to become a teamcomplete with teamwork, it is a time-consuming process at best andlikely to fail in today’s rapid-paced virtual project environments.With company survival often riding on project successes, we doubt

The visual evidence ofteamwork . . .

The coffeepot is never leftempty for teammates!

cott_c03.qxd 6/30/05 3:10 PM Page 27


that most CEOs would gamble on the odds of creating effectiveleaderless project teams—any more than ticket buyers would gambleon the performance of a conductor-less orchestra.

With adequate organizational commitment and an establishedvocabulary, the project team will be equipped to tailor the projectcycle to match the challenges of their project.

The Sequential Project Cycle—The Template for

Achieving Predictable Performance

All projects have a cycle. It may not always be documented and itmay not be fully understood, but there is a sequence of phasesthrough which the project passes in pursuit of the project’s opportu-nity (Figure 3.4).

Figure 3.4 The sequential project cycle.

Act

ivity

Leve

l

Time

ConceptDefinition

Implementation Operations

Verification

Project CycleTypical Intensity Trend

Study

The Project Cycle containsPeriods such as

Each Period containsPhases

cott_c03.qxd 6/30/05 3:10 PM Page 28


Professional project management organizations usually have astandard or template project cycle that embodies their proven ap-proach and lessons learned. That reference cycle serves as a founda-tion for achieving predictable performance from project to projectand is tailored to the special characteristics of the project at hand.The resultant project cycle then becomes the parent or driver of theproject’s logic network (represented by, e.g., PERT and GANTTcharts) that will be developed during planning.

The project cycle for development projects should representsystem solution maturation. It usually contains Periods (such asStudy, Implementation, and Operations), and Phases within the Pe-riods (such as Requirements Development and Concept Defini-tion). Phases include activities such as Trade-Off CandidateConcepts, products such as System Concept Document, and deci-sion gates or phase transition reviews such as System Concept Re-view (Figure 3.5).

Figure 3.5 Recommended format for the project cycle.

DecisionGates

These events involve planning for, and securing,project funding to fuel the project through the cycle.

Specific actions taken to meet the goals of the project, e.g., Define user requirements, Trade-off candidate concepts, Develop user validation approach.

The output of activities—to be approved at the Decision Gate, e.g., System Concept Document Specifications, drawings, and manuals, Internal hardware and software feasibility models, Deliverable hardware, software, and documentation.

Predetermined decision check points to be satisfiedbefore advancing to the next set of activities, e.g., System Concept Review.

Periods

Phases

Budget

seitivitcA

stcu

dor

P

EL

CY

C T

CEJ

OR

P eh

T

cott_c03.qxd 6/30/05 3:10 PM Page 29


Known by a variety of names that help to characterize it,the project cycle has been called: budget cycle, acquisition cycle,implementation cycle, and others. These are typically condensedfunctional views of portions of the overall project cycle.

A complete project cycle is usually designed to achieve the proj-ect strategy and includes the tactical development and integrationmethods determined for the project.

There are three aspects of any project cycle that are best envi-sioned as layers: business, budget, and technical. Each layer uses thecommon periods and phases but contains its own set of activitiesand products. The interwoven events of the three aspects constitutethe total project cycle that is sometimes referred to as the projectopportunity cycle. The project cycle should span from user wants toproject deactivation or any reduced span appropriate to the project’sscope (Figure 3.6).

The business aspect of the cycle contains the overall businesstactics for accomplishing the business or mission case that is theroot justification for pursuing the project opportunity. The busi-ness aspect includes such activities as teaming, alliances, licensing,market analysis, market testing, and other events relevant to thebusiness case success. Important business decision gates include

Figure 3.6 The three aspects of all projects.

CollectUser

Req’ts

Technical Aspect

SelectConcept

Determine

Resource

Availability

Predict

Cost

(Rough)

Budget Aspect

Study Period

Business Aspect

Recognize

Opportunity

Develop

Business

Case

Prove

Business

Feasibility

Select

Acquisition

Approach

Select

Best Value

Contractor

Manage

Suppliers

Study Period

cott_c03.qxd 6/30/05 3:10 PM Page 30


The wheel-and-axle processmodel adds details that toooften are misunderstood,minimized, or ignored inpractice. Lack of attention tothese details is precisely thekind of omission that doomsprojects.

approval of the overall program plan and contracting and subcon-tracting milestones.

The budget aspect contains the management approach (tactics)for securing and managing the funding of the project. It includes de-velopment of the detailed project “should cost” and “should take” es-timates and the events associated with applying for and gettingapproval for the project funds. It also contains the financial manage-ment approach, such as phased work release timed with fundingavailability and cash f low management.

The technical aspect identifies the activities and events re-quired to develop the optimum technical solution in the most effi-cient manner, a systems engineering responsibility. Tactics such asunified, incremental, linear, or evolutionary development and singleor multiple deliveries should be ref lected within the technical as-pect of the cycle. While the business aspect is the driver of theproject for development projects, the technical aspect will containthe arrangement and sequence of periods and phases to best pro-duce the system solution. The technical cycle will usually frame theproject network and will most likely represent the critical path.

THE PROJECT MANAGEMENT ELEMENTS—TEN CATEGORIES OF SITUATIONAL

TECHNIQUES AND TOOLS

Technical, schedule, and cost performance are not naturally com-patible and synergistic. They are opposing forces in dynamic tensionthat require compromise based on knowledge of the project’s prior-ities and health. The management elements, summarized here, pro-vide the necessary techniques and tools that can be situationallyapplied to manage the project through the project cycle.

Many texts and organizations attempt to apply the Fayol model toprojects (depicted in the first column of Table 3.1). While the Fayolmodel and its more recent derivatives (second column) have a time-less validity to ongoing general management, they have critical defi-ciencies related to project management and the relatively shortduration of projects. They fail to address the unique role of require-ments as the project initiator and driver. Even more significantly,they do not provide enough detail to manage highly complex projectprocesses, particularly those of high-risk, emerging-technology proj-ects. To provide greater comprehension of what is required, we haveexpanded these models. The resulting ten elements, applicable to allphases of the cycle, identify those indispensable responsibilities of

Technical, schedule, and costperformance are opposingforces in dynamic tension thatrequire compromise.

cott_c03.qxd 6/30/05 3:10 PM Page 31


project management and systems engineering that are too often mis-understood, trivialized, or ignored in practice. This is not an aca-demic reorganization. Lack of attention to these techniques leads toomissions that often doom projects.

The added and changed elements are shown in bold. For projectcontrol, the distinction between being proactive and reactive, notedin the last column, is particularly significant. Project Control em-bodies those techniques that help ensure that events happen asplanned, and that unplanned events do not happen (proactive),whereas the three variance control elements define the means fordetecting and correcting unplanned results (reactive).

Table 3.1 Relating the ten elements to traditional models

Fayol(1916)

RecentDerivatives

MajorFocus

Our Ten-Element Model Rationale for Expansion

Formulate Proactive

Requirements Failure to manage requirements, whichinitiate and drive projects, is the majorcause for failure.

Organizing Organizing Organizing

Staffing Project Team Teams are newly formed for eachproject and include subcontractors andoutsourcing.

Planning Planning Planning

Opportunity

and Risk

Management

Usually ignored in the projectenvironment and a significant cause ofproject failures.

Project Control Often improperly implemented asmonitoring. Many failures are due to alack of proper controls.

Controlling ControllingVariancecontrol

Visibility Visibility systems must be designedand implemented to keep allstakeholders informed.

CoordinatingReactive

Status Hard measurement of progress andvariance, as opposed to the moretypical activity reporting.

MotivateLeadership Creation of team energy to succeed to

the plan.

Commanding Directing Corrective

Action

Innovative actions required to get backon plan.

Situational managementdepends on the properapplication of eachtechnique . . . skillfully.

Projects sometimes fail byflawed application of excellenttechniques.

cott_c03.qxd 6/30/05 3:10 PM Page 32


Because they are situational, the techniques must be applied re-sponsively, relative to the active project phase and the team or indi-vidual circumstances at the time. An example is the OrganizationOptions element that is applied frequently (almost continually) asthe project moves from phase to phase and changes its organizationform to best satisfy the objectives of the active phase. In addition,the organization option for a supplier or an internal manufacturingdepartment is likely to be considerably different from that of theproject office. Similarly, the element of Project Visibility will callfor those techniques that are best suited to the active project-cyclephase and the geographic distribution of stakeholders.

The ten project management elements (Table 3.1) are the team’stool chest containing the best available techniques and tools in eachcategory. This implicitly depends on the team being skilled in theapplication of all of the techniques and tools—which is often not thecase. Projects do fail by f lawed application of excellent techniques.

It is becoming increasingly popular for organizations to select atool suite for project management and systems engineering func-tions. Microsoft Project is by far the most popular project planningtool set. Risk management tracking is another popular tool capabil-ity. While the tools don’t discover the risks, they do help track themitigation progress. Many systems engineering tools are availableand range from requirements management all the way to executablesimulations. Some are feature rich and require training to realizetheir full capability.

The ten elements are summarized in Chapter 8 and discussed indetail in Chapters 9 through 18.

The project risk, size, andmanagement style determinethe extent of application, butnot whether a particularelement will be present ornot—all are essential forproject success.

cott_c03.qxd 6/30/05 3:10 PM Page 33

cott_c03.qxd 6/30/05 3:10 PM Page 34

P a r T T w o

The Essentialsof ProjectManagement

Part Two devotes one chapter to each of the five essentials of theprocess model introduced in Chapter 3.

Previous editions of Visualizing Project Management describefour essentials of project management: vocabulary, teamwork, theproject cycle, and the ten management elements.

While the project environment and enterprise infrastruc-ture have always been considered key to the four es-sentials, our lessons learned in building and sustainingproject cultures have illuminated the critical importanceof organizational commitment as the foundation and en-abler for the other four essentials.

The five essentials model,being behavior-based,provides the framework forrelating the functional areasand best practices of projectmanagement and systemsengineering.

cott_c04.qxd 6/30/05 3:09 PM Page 35

36 THE ESSENTIALS OF PROJECT MANAGEMENT

Nonverbal languages play an increasing role in projectmanagement and systems engineering, particularly in thegraphical expression of requirements. We must, there-fore, be more precise with our own process model vocab-ulary. While a concise vocabulary is a vital projectsuccess factor, it is now more properly characterized aspart of project communication.

The next five chapters, and the ten that follow in Part Three, in-clude margin notes (as defined in the opener to Part One) to corre-late the functional attributes of the five essentials with industrypractices set forth in the PMI PMBOK® Guide and the INCOSESystems Engineering Handbook.

cott_c04.qxd 6/30/05 3:09 PM Page 36

37

4ORGANIZATIONALCOMMITMENT

Commitments are sometimes triggered by a life-threateningevent. In the case of one high-tech company, it was thecorporation’s life at risk. A sharp drop in proposal win rates wasfurther complicated by a declining economy. Customers ratedthe company high on creativity and quality, but unacceptablylow on managing development projects. The 25 largestcontracts (Top 25) were all behind schedule—by as much as 50percent—and all were over budget. Prospects for recovery weregrim. A 20 percent layoff, the first in the company’s 20-yearhistory, was further evidence of the problems.

Despite the short-term crisis (or because of it), thecompany president acknowledged the need for a long-termsolution at the culture level. His team selected our company toestablish the necessary processes facilitated by a trainingprogram. Everything we provided was based on thefoundation concepts of this book.

Top management was trained first. Over the next twoyears, all professional staff—from accounting to marketing toengineering—were required to take two weeks of training inproject management, systems engineering, and projectbusiness management. One year into the program, despite nosignificant improvement in business results, the presidentinsisted on staying the course of rebuilding the company’sculture. He reinforced this commitment with a performanceimprovement incentive program tied to measurable results. Bythe end of the second year, all projects showed significantimprovement and the Top 25 were all performing withinbudget and on schedule to the amazement and delight of theexecutive team and their customers. The next 15 years sawfour presidents and many Top 25 project changes, but withonly one exception the on-time, in-budget, high-quality resultscontinued with significant client award fees and profit.

PMBOK ® GuideThe PMBOK ® Guide does notdirectly address organizationalcommitment.

However, PMBOK ® Guide Sec1.5.3 Understanding theProject Environment,2.3 Organizational Influences,and 9.2 Acquire the ProjectTeam contain relevantinformation.

INCOSEINCOSE also does not directlyaddress organizationalcommitment. Sec 7.2Enterprise EnvironmentManagement, 7.3 InvestmentManagement, and 7.5Resource Management areconsistent with this chapter.

Essential 1

cott_c04.qxd 6/30/05 3:09 PM Page 37


In the cited company, ESL, the commitment unlocked the doors ofimagination, allowed the vision, and provided the organization

with the right stuff. They cultivated a learning organization long be-fore the phrase was coined.

This ESL story illustrates many of the key messages that follow,particularly the importance of setting the overall objectives, estab-lishing priorities, staying the course and:

• Building a project culture, starting at the top,• Obtaining buy-in through shared discovery, and• Keeping the faith in the vision by staying focused on the long view.

Many organizations are benefiting from their own decision to in-vest in a project culture, one in which project management and sys-tems engineering are integrated as a core competency and as acompetitive force. What’s unusual about this case is the company’scommitment of energy and resources in a deteriorating situationwhere the typical response is to cut all discretionary spending. ESLsurvived and prospered because organizational commitment startedat the top, providing the fabric of the culture.

ESTABLISHING A PROJECT CULTUREWITH ALL THE RIGHT STUFF

Much more has been said than done about meaningful and lastingculture changes. Establishing a culture is not about creating a socialclub with a certain theme. All organizations exist to accomplishsomething; they have a core mission—a purpose. The delivered sys-tem is the end; the project culture is the means.

By project culture, we mean an enterprise-wide belief systemthat empowers the project manager to get the job done while openlyaddressing the critical balance needed between the enduring func-tional organizations and the relatively short-term project teams.What is needed is a project culture that views and rewards the proj-ect stakeholders inclusively; that is, by including all stakeholders, notjust the assigned team members.

Dr. Judd Allen likens the stages of cultural change to thoseof farming:2

• Analyze and plan:Prepare the soil.

• Introduce systems and processes:Plant the seeds of change.

Education programs areusually among the firstcasualties of a company’srecovery, but that’s the timethey’re most needed and havethe highest impact.

“Commitment unlocks thedoors of imagination, allowsvision, and gives us the ‘rightstuff’ to turn our dreams intoreality.”

James Womack1

cott_c04.qxd 6/30/05 3:09 PM Page 38

ORGANIZATIONAL COMMITMENT 39

• Integrate, train, and mentor:Water and fertilize—the seeds take root.

• Evaluate and extend:Harvest and gather new seeds to plant.

The Role of Executive Management

When a company forms a new division, the top executive makes anannouncement alerting everyone in the company. Personnel assign-ments are announced and roles and responsibilities are defined. Inparticular, relationships between existing and new organizations areclarified. In an effective project culture, each new project should beviewed as a temporary new division, with the project manager in therole of the general manager.

Executive management must determine the project manager ’slevel of authority and then hold him or her accountable consistentwith that defined authority. To hold the project manager account-able for cost and schedule with no power over the technical contentis irresponsible and unfair.

Just as every project needs a champion, the project cultureneeds its champions—the organization’s chief executive and appro-priate top management. This is a proactive role as represented bythe qualities in the middle column of the following list, yet many ex-ecutives provide only lip service (the last column). As an example oflip service, it serves little purpose to charter a project team andproject manager if the cultural support isn’t already in place:

Culture Proactive Lip Service

Ingredient Management to Project Team

Project manager Fully empowered Responsibilityauthority only

Communications Open to broad scrutiny Arbitrary

Project training Available to all levels None

Management Continuously Impossible edictssupport involved

Management process Kept up-to-date Counterproductive

Funding and budgets Planned and realistic No budget authority

Project controls Comprehensive Arbitrary

Why are some executive management teams reluctant tomake necessary cultural commitments? As managers rise in the

cott_c04.qxd 6/30/05 3:09 PM Page 39


Table 4.1 A project culture depends on proactive management

Proactive Reactive Slow React Lip Service No Interest

Projectmanagerauthority

Fullyempowered

Selectivedelegation

Reluctant todelegate

Responsibilitywithoutauthority

Unspecified

Communica-tions

Open to broadscrutiny

Formal Defensive Avoided Closed to anyscrutiny

Projecttraining

All levels Project team Managers only None None

Managementsupport

Continuouslyinvolved

Referencemanual

Reluctant Impossibleedicts

Sink or swim

Managementprocess

Up-to-date Standard As customerdemands

Counter-productiveinvolvement

None

Funding andbudgets

Planned Controlled By variances No budgetauthority

Excessspending withcash cow

Projectcontrols

Comprehensiveand effective

Basic Force fit Arbitrary Uncontrolled

organization, they often suffer a gradual loss of perspective re-garding the change process itself. Too many executives are reluc-tant to leave their comfort zones and depart from tradition. Theytypically don’t embrace or emphasize disciplined project manage-ment or systems engineering on any level. Their behavior can rangefrom resistive to showing no interest at all as contrasted with theideal proactive management attitude (Table 4.1).

Career Paths

Many companies treat project management and systems engineeringas roles or assignments rather than as professional career paths. Oth-ers provide career paths with compensation linked to demonstratedproficiency levels. These companies also encourage certification, usu-ally with financial support. In companies where project managementis a defined career step to general management, the project managerposition may be positioned more senior than a functional manager.This approach ensures that functional managers view the project

cott_c04.qxd 6/30/05 3:09 PM Page 40


A learning organization is onethat identifies ways in which itcould strengthen itself andsuccessfully incorporatesthose ideas into its culture andoperations.

manager as a customer. Cultures that are not project-oriented, wherefunctional management is perceived as a step up from project man-agement, generally exhibit less effective project execution.

The Learning Organization—Getting to the Ultimate “Why?”

Referring to the farming metaphor described previously, culturalchange starts with preparing the soil and turning over a few rocks byanalyzing the organization’s behavior. This begins by determiningwhy projects fail as addressed in the Introduction.

This analysis requires an open culture where participants learnto “admire” and solve problems, not to hide or excuse them.

A Culture of Learning

To install and sustain a project culture, project teams and stake-holders need ongoing training beginning with training in the cultureitself. A project culture views project management and systems en-gineering as essential core competencies—life skills to be sustainedand improved. Companies serious about their project performanceprovide both project management and systems engineering trainingand encourage certification in both disciplines—the PMP andCSEP discussed in Chapter 2. Organization performance improve-ment is also encouraged through capability assessments and ratingssuch as SEI-CMMI and ISO certification levels of achievement.

Enlightened organizations treat professional certifications as ameans to encourage professionalism and self-improvement, but notas an end in themselves. Support considerations should include bud-geting time for certification training and ways to recognize and re-ward the accomplishment.

Lessons Learned

Many projects fail by repeating the lessons learned—the technical orbusiness mistakes of others. For example, the SeaSat Satellite failedin orbit when an arc across the solar-array-slip rings caused a cata-strophic power supply failure. About a year earlier, a prior project atthe same company had solved this problem, which had been discov-ered in a thermal vacuum chamber test before their launch. Thisfinding was not communicated to the SeaSat team. Lessons learneddeveloped by project teams after project completion can be invalu-able to other project managers, present and future. But there is usu-ally no convenient mechanism for the lessons to get into the hands

Don’t fix the blame . . .

fix the problem.

cott_c04.qxd 6/30/05 3:09 PM Page 41


Projects defy tradition.Traditional managementmethods simply don’t apply.

(and minds) of those who would benefit most. There may even be acultural bias against exposing prior failures. Furthermore, projectteams are dispersed to other projects just at the time they should bedocumenting their learning experiences. Perhaps Thoreau had thispredicament in mind when he queried, “How can we remember ourignorance, which our growth requires, when we are using our knowl-edge all of the time?” One of the most neglected project manage-ment concepts is lessons learned from prior failures and successes.Later, we treat lessons learned as one of any project’s requirementsartifacts. In some U.S. government Request for Proposals (RFPs),the solicitation requires bidders to explain how they plan to respondto relevant lessons learned. The bidders must research and considerrelevant lessons as part of the requirements.

If You Can’t Change the People, Change the People

Few people embrace culture change. Some resist change openly (orworse, subversively). While it is important not to give up on someoneprematurely, one person with a bad attitude can destroy teamworkand drag down the team as well as affect the organization’s projectculture. When removing an uncooperative team member, the man-ager needs to let the others know why, in direct, factual terms.

THE PROJECT ENVIRONMENT

Projects are quite different from traditional operations. A commonform of development project is exemplified by a construction indus-try project or by DoD- and NASA-contracted developments thattypically create projects among many geographically and nationallydispersed companies. When the project team has completed its ob-jectives, it is disbanded and its members seek new assignmentsthrough their skill-center home organization. Still other projects areformed with one organization at the core that then uses other com-panies, divisions, and subcontractors as skilled resources. In allcases, project team members typically serve two managers: one forthe project duration focused on tasks, and the other, the functionalmanager, focused on career and technical performance (providingthe guarantee for the project assignment).

The evolution of a typical project, such as a new product or ser-vice development, usually follows three periods or stages (Figure 4.1).

Traditional management approaches deal well with the first andthird of these three periods. For development projects, they typically

cott_c04.qxd 6/30/05 3:09 PM Page 42


Conventional wisdom seldomholds true for projects. Inmany cases, it’s dead wrong.

Figure 4.1 The evolution of a typical project.

1. Proposal: A projectoften starts in afunctional organizationwith a proposal or inresponse to an externalrequest.

2. Development: For thedevelopment phases, across-functional team isformed and empowered.

3. Production: Forstandard productionand/or operationalsupport, it is common toreturn to a functional formof management.

do not work well during period two—the heart of project manage-ment. Traditional working conditions have meant stability, continuity,and security to the personnel. Conventional wisdom and traditionalmanagement textbooks have long emphasized the need for the man-ager to create a productive work environment and a consistent climateincluding:

• Stable work environment.• Minimum of conf lict among employees.• Ambitious employees driven to be their personal best by perks

and personal competition.• Simple, clear reporting structure and organization.• Responsibility matched with authority.• Maximum creative freedom.

There’s very little of this list that relates to the project environment.Conventional wisdom seldom holds true for projects. In many cases,it’s dead wrong.

As depicted by Figure 4.2, projects are as important to institu-tions as leaves are to a tree. Traditional management models focus onthe enduring organizations—the roots—such as functional depart-ments. By contrast, project management is more narrowly focused on the specific objectives of the project at hand. Like task forces andother temporary groups, project teams are drawn from various long-term permanent organizations. But, unlike other temporarygroups, projects are managed to a defined plan including a budget,schedule, and specific output—usually a product or service. Proj-ects are requirements driven. The customer or user defines the

cott_c04.qxd 6/30/05 3:09 PM Page 43


Figure 4.2 Projects are like the leaves on a tree.

The trunk and roots like functional organiza-tions, product centers, and executive staff,sustain long-term growth and security.

Projects, like shedding leaves,are dissolved when the projectis complete.

But without the renewalof leaves, the tree will die.

Projects should not be forcedinto traditional structures usedfor repetitive or long-termwork.

requirements to be met by the project team. This may be donethrough an intermediary such as the marketing organization.

Unlike the activities that occur wholly within traditional, func-tional organizations, project work depends on lateral f low across do-main specialties. Therefore, projects lend themselves to some formof matrix organization (see Figure 4.3). Horizontal dotted-line in-terfaces need to be encouraged and strengthened rather than usedreluctantly as exceptions to the linear chain of command.

The vast majority of projects exist in the matrix environmentwhere there is a small project office (typically under 5 percent of thetotal project team), and project managers rely on borrowed or con-

Figure 4.3 Typical matrix organization.

cott_c04.qxd 6/30/05 3:09 PM Page 44


Project management andsystems engineering aredifficult to describe succinctly.

tracted personnel to do the required work. Individuals on the projectoften answer to the project manager as well as their functional man-ager. This is a very powerful and positive structure, but the projectmanagers, functional managers, and all of the project team membersmust understand their respective roles or it can fail. Managementunderstanding of—and support for—the project environment is re-quired at all levels, from executive to first-line managers, from engi-neering to manufacturing, from contracts to procurement.

To effectively install project management and systems engineer-ing, a foundation is necessary. An executive should issue the projectcharter to authorize the project, appoint key personnel, and estab-lish the working relationships including the code of conduct andspirit of the relationships.

If the functional managers control what their people do, projectmanagers become powerless and are reduced to being project coor-dinators and monitors, simply reporting on what is happening andwhy projects are not meeting their objectives. Alternatively, if theproject manager has full control, the functional departments be-come “body shops,” supplying people on demand and removingthem when budgets are cut. Such managers are often judged by howlittle overhead funds are used to sustain their people, in which caseit is difficult to build a core corporate technical competence. Theseundesirable extremes can be balanced when executive managementworks with all organizations to define their roles and responsibilitiesin the project environment and culture.

PROJECT RESOURCES

Project management and systems engineering require substantialsupport systems. There is extensive planning, coordinating, commu-nicating, measuring, analysis, controlling, statusing, reporting, and ahost of other activities requiring thoroughness and attention to de-tail. Timeliness is of the essence since corrective action must beswift if projects are to meet their cost and schedule constraints.

The increasing complexity of projects is exacerbating this chal-lenge as the number of entities and interfaces soar exponentially. Nolonger are hand-entered tables and matrices effective and efficient.

Supporting systems for planning, work release, cost collection, sta-tus reporting, earned value, technical performance, personnel man-agement, material and parts procurement, subcontractor management,and so forth should all be designed to support the project with a mini-mum of overhead and bureaucracy. Well-managed companies have

INCOSEThe INCOSE Handbook Sec 7.5Resource Management citesthe necessity of coordinatingproject staffing with theresource needs of the entireenterprise.

cott_c04.qxd 6/30/05 3:09 PM Page 45


planning centers, planning software, cost collection daily, cost report-ing in real time (either daily or weekly), requirements-managementsoftware, system-simulation software, decision-analysis software,lessons-learned databases, and other support systems.

Forward-looking organizations are equipping their teams withboth PM and SE computer-based tools that facilitate planning andtracking of progress, technical analysis of concepts, and aid in in-formed trade studies such as decision support systems. INCOSE iscurrently leading the development of a common graphical templatefor expressing both requirements and concepts, which is to be madeavailable by multiple tool vendors.

A major support environment issue is authority of the projectmanager, which must be determined by executive management.There is a very wide dynamic range for this position that extendsfrom no power to supreme dictatorial power. In government-relatedprojects performed to defined contract terms and conditions, it isnot uncommon for the project manager to have complete authorityover the project. In these cases, the project is run as a line of busi-ness with cost-center performance. In this environment, the projectmanager decides and implements with autonomy and is held ac-countable for the results. The project manager “buys” internal ser-vices by issuing work tasks with associated budgets. If internalsupport systems fall short, the authority extends to cancelling the in-ternal services and acquiring the support from whatever organiza-tion can provide it, even from a competitive source. Buyers liketheir supplier project managers to enjoy this level of authority. Inthis environment, the concept of “make a promise, keep a promise”has a chance of working because of the threat of work cancellation.

The other exteme is caused when functional organizations arefunded on an annual basis by general management rather than bythe project managers. Project managers must then solicit functionalsupport by requesting it (begging for it) followed by managing theresource with no authority or financial power. In extreme cases, itcomes down to the project manager having to complain to seniormanagement to get the support needed to complete the project asplanned. Because the functional managers own the resources, theyare the ones that determine the project priorities and the effort ex-pended on them. In this environment, the concept of “make apromise, keep a promise” almost always fails.

The organization’s culture should recognize and respond to theproject manager as the overall authority of the project and to thechief systems engineer as the senior technical authority of the proj-ect and the keeper of the customer’s perspective. Functional man-

PMBOK ® GuideThe PMBOK ® Guide Sec 2.3.3Organizational Structureillustrates the degree ofauthority of the projectmanager as a function of thetype of organization createdby general management.

cott_c04.qxd 6/30/05 3:09 PM Page 46


agers should view the project manager as their customer with cus-tomer satisfaction as their ultimate driver. Functional managersshould be willing to guarantee the performance of their specialistsand be willing to step in and rectify substandard performance.

ORGANIZATION COMMITMENT EXERCISE

Based on your current or recent work experience, list the tangibleevidence of organizational commitment. Include executive support,career paths, processes, tools, and training.

Make a second list of those organizational actions that wouldsignificantly improve the project team’s ability to succeed.

cott_c04.qxd 6/30/05 3:09 PM Page 47

48

5PROJECTCOMMUNICATION

“The Board believes that deficiencies in communication,including those spelled out by the Shuttle IndependentAssessment Team (1999), were a foundation for the[Columbia] accident [on February 1, 2003].”

From the Final Report of the Columbia AccidentInvestigation Board, August 2003.1

“The greatest problem in com-munication is the illusion thatit has been accomplished.”

George Bernard Shaw

Communication problems are the root cause of many project fail-ures. Miscommunication routinely leads to conf lict that can de-

stroy teamwork. Techniques for communicating in the projectenvironment and a common vocabulary are prerequisites for develop-ing teamwork and for us to be able to discuss the remaining Essentials,Teamwork, the Project Cycle, and the Ten Management Elements.

It is beyond the scope of this book to enumerate the thousandsof communication techniques that can benefit projects of all sizesand complexity and to define the countless terms from which aproject-specific vocabulary can be assembled. We draw on ex-cerpts and examples from our companion book, CommunicatingProject Management, and refer to several other sources that wehave found especially valuable.2

Communicating is difficult enough in familiar work, social, andfamily settings. The project environment can be particularly chal-lenging. Due to their temporary nature, projects often bring to-gether people who were previously unknown to each other, which isreason enough for miscommunication, especially in the early project

PMBOK ® GuideThis chapter is consistentwith PMBOK ® Guide Ch 10Project Communications Man-agement.

• 10.1 Communication Plan-ning.

• 10.2 Information Distribution.

INCOSEThis chapter is consistent withINCOSE Handbook Sec 5.2Planning and Sec 5.7 ControlProcess.

PMBOK ® GuideCommunication process areas

are portions of three of the five

PMBOK ® Guide Chapter 3 Pro-

cess Groups:

• 3.2.2 Planning.

• 3.2.3 Executing.

• 3.2.4 Monitoring and Con-trolling.

Essential 2

cott_c05.qxd 6/30/05 3:04 PM Page 48

Figure 5.1 The Project Management Communication model.

Techniques Environment LanguageParticipants =X X XSUCCESSFUL

COMMUNICATIONS

Enablers

Barriers

Facilitators,Training

Polling,Constructive Feedback

Open Culture,Associations

Common Vocabulary,Integrated/Documented

Bad Attitude,Excessive Rivalry

Not Listening,Destructive Criticism

Security,Stovepipes

Jargon,Lack of Standards

PROJECT COMMUNICATION 49

To press a suit means onething to a tailor and somethingvery different to a lawyer.

phases. Because projects also integrate people with very differentbackgrounds, they represent a microcosm of a general organizationor company. Negative labels, such as geek and bean counter, exem-plify some of the attitudinal barriers that interfere with projectcommunications, not to mention the vocabulary ambiguities amongthe various disciplines. As illustrated in Figure 5.1, communicationresults can only be as good as the least of the multiplication factorsin this product:

Participants × Techniques × Environment × Language = Communications

Several general models have proven helpful in visualizing andunderstanding the communication process. Many models datingfrom the late 1940s are referred to as transmission models becausethey approach communications as an information transfer problembased on some variation of four fundamental elements:

Sender (or Source) > Message > Channel (or Medium) > Receiver

The transmission models have also inf luenced early studies ofhuman communication, but many theorists now consider them to bemisleading. These models and their derivatives focus more on thestudy of message making as a process rather than on what a messagemeans or how it creates meaning.

The issues of meaning and interpretation are ref lected in themodel depicted in Figure 5.2, introduced in 1960, which empha-sizes the interpretive processes. Berlo defined five verbal communi-cation skills: speaking and writing (encoding skills), listening andreading (decoding skills), and thought or reasoning (both encodingand decoding).

For those interested in a deeper understanding of the theo-ries underlying these and other models, we offer these references.

PMBOK ® GuidePMBOK ® Guide Figure 10-3identifies components of com-munication as:

• Encode.

• Message.

• Medium.

• Noise.

• Decode.

cott_c05.qxd 6/30/05 3:04 PM Page 49


Theories of Human Communication by Stephen Littlejohn is con-sidered the seminal text in the field.3 Richard Lanigan in Phenom-enology of Communication focuses on semantics—what a messagemeans and how it creates that meaning.4

The remainder of this chapter speaks to the communicationsissues of project teams by considering each of the four communica-tion model factors: participants, techniques, environment, and lan-guage (Figure 5.1).

PARTICIPANTS AND THEIR INFLUENCE ONPROJECT COMMUNICATIONS

We often think of project participants as being limited to the teammembers. But from total inf luence and broader communicationsviewpoints, the participants encompass a wide array of stakehold-ers, including:

• Functional and middle management;• Executive management;• Closely related stakeholders, such as policy makers, contractors,

customers, and potential users; and• Global stakeholders, such as professional associations and stan-

dards organizations.

Stakeholders all bring their own vocabulary, behaviors, commu-nication styles, attitudes, biases, and hidden agendas to the projectenvironment.

Figure 5.2 David Berlo SMCR model.

Communication Skills

Knowledge

Social System

Culture

Attitudes

Communication Skills

Knowledge

Social System

Culture

Attitudes

Elements Structure

etn

oC

tn

oC

ed

T

M

TN

EA

ER

T

RECEIVERCHANNEL

SEEING

HEARING

TOUCHING

SMELLING

TASTING

MESSAGESOURCE

cott_c05.qxd 6/30/05 3:04 PM Page 50


Personal Behaviors and Communication Styles

To communicate effectively, we all need to be aware of differing be-haviors and styles and their potential impact. Leaders often need toadapt their own style rather than “shape up” the other person.

There are numerous texts and self-study guides for analyzingyour style tendencies and preferences. In Chapter 18, we summarizetwo models proven to be particularly effective. However, the detailsof any specific self-typing or group analysis scheme are less impor-tant than the process itself—exploring your own preferences andstretching your range of styles. To benefit from that process, youhave to be self-aware and open to discovery.

Models help discern cognitive preferences and do not representbehavioral absolutes. They provide insight into how we gather infor-mation, process it, and communicate. Regardless of your preferredstyle, your actual style at any time should be affected by factors suchas the maturity level of team members and the gravity or priority ofthe situation. Variety and shifts in style are not only necessary—they’re healthy. Communicating in projects requires f lexibility andadaptability in dealing with the task at hand, the personalitiesinvolved, events, and the situation. As the Columbia Accident Inves-tigation Board noted, “In highly uncertain circumstances, . . . man-agement failed to defer to its engineers and failed to recognize thatdifferent data standards—qualitative, subjective, and intuitive—and different processes—democratic rather than protocol and chainof command—were appropriate.”5

Attitudes and Biases Can Build Bridges of

Understanding or Destroy Projects

We refer to negative personal biases regarding important projectmanagement techniques as the hidden enemies. For example, oursurveys of approximately 20,000 managers regarding their attitudeabout red teams revealed that only 20 percent of project partici-pants have a positive attitude about this important document evalu-ation and communication technique.

The Berlo SMCR Model (Figure 5.2) identifies attitude as one offive facets that affect personal communications. (Some models com-bine Berlo’s social system facet with culture.) An inappropriate atti-tude or bias regarding project subject matter or a specific technique,once understood, can usually be dealt with rationally and amicably.But undisclosed attitudes toward oneself or toward another in thecommunications loop are a much more significant barrier. If you

Red team—objective peer orexpert review of documenta-tion and presentation materialto identify deficiencies andrecommend corrective action.

(See the Glossary for a morecomplete definition.)

cott_c05.qxd 6/30/05 3:04 PM Page 51


Figure 5.3 Attitude: The slippery slopes of communicating.

have a low opinion of the person with whom you’re dialoging, you willcertainly formulate your message differently from the way you formu-late it for your respective collaborators. It is regrettable that the typeof productive dialog illustrated at the top of the mountain in Figure5.3 is so unstable and susceptible to sudden erosion and decline.

Constructive challenge (Figure 5.3) is a problem-resolving tech-nique that depends on good communication skills and a positive at-titude. Known as constructive confrontation in some circles, it caneasily turn destructive without the right intentions, skills, or thecommitment to immediately solve problems. To keep the processconstructive and effective the following ground rules apply:

• On recognizing a problem, go directly to the most likely prob-lem solver—independent of organization structure.

• Confront the problem, not the person, and use facts.• Exclude personalities from the discussion.• Work jointly toward resolution, holding each other accountable

for the shared responsibilities.

Used skillfully, this approach eliminates whining and solves prob-lems quickly. Some leading companies have built this practice intotheir culture. But when used in name only, as a weapon in rivalry orfor other wrong purposes, it can destroy teamwork and the project.Excessive rivalry can be just as destructive at the individual level as itis at the global level. As long-time participants in professional associa-tions and industry standards organizations, we have observed a trendof increasing cooperation among the key project disciplines. We ad-

PMBOK ® GuideThe PMBOK ® Guide Chapter 10Project Communications Man-agement recommends thatmeeting owners should planfor conflict resolution to ensuremeetings are productive.

cott_c05.qxd 6/30/05 3:04 PM Page 52


dress this collaborative spirit in several sections. Unfortunately, thisindustry-level collaboration frequently fails to permeate the very or-ganizations and projects that form their constituency. Sometimes thisis a result of competitive pressures. More often, it is ignorance or mis-directed ambition.

In the face of management and global barriers, how can projectmanagers ensure effective communications on their own project?Just like every other responsibility within a project, it starts athome—by taking responsibility for communicating skills, attitudes,and training at the individual and team levels. You, as project man-ager, need to assess the skills within your team and take the appro-priate measures, which often start with good guides such as thoseidentified in the next section.

The project participants have the greatest potential to promoteunderstanding by proactively strengthening the other three com-munication factors: technique, environment, and language. Whenyou or other key stakeholders anticipate a communication break-down or encounter a barrier, the best strategy may be to turn to anonstakeholder for objective feedback or assistance. For example,the initial project planning session is often held before the newlyformed project team has coalesced; therefore, they may benefitgreatly from an outside facilitator, one who is skilled in the subjectmatter as well as the art of communicating among disparate fac-tions. This approach can:

• Accelerate the convergence to a workable plan,• Provide valuable on-the-job communication training,• Lead to the building and realization of teamwork, and• Serve as a model for future conduct.

TECHNIQUES FOR COMMUNICATING IN PROJECTS

Exchange and feedback are key words in describing communicationtechniques. Whether engaged in a simple conversation or conducting amultifaceteddesignreview, themostpowerful techniquesare thosethatresult in some kind of exchange or feedback.

The next paragraph provides guides for communication tech-niques that are particularly helpful. While many of the suggestionsoffered in these sources may seem like common sense, they helpfocus on critical points that may be taken for granted, such aspreparing for a one-on-one conversation, testing a potentially touchyconversation, or actively listening to what other people say. In addi-tion, they offer some helpful conversational strategies and tips fordetermining when a meeting is going off course.

cott_c05.qxd 6/30/05 3:04 PM Page 53


In her book, Communicate with Confidence!, Dianna Booherprovides a compilation of 1,042 tips, all with explanations.7 Thecompilation is directed toward better governance with words, bothwritten and oral. The book by Harkins and Bennis describes provencommunication techniques for improving growth and productivity.8

Kegan and Lahey offer practical solutions to several communicationbarriers.9 The article by Brown and Isaacs elevates the casual con-versation to business process status.10

We previously discussed the situational nature of communica-tions, particularly in projects. In addition to being aware of yourown and others’ communication styles, you need to consider yourpurposes, such as:

• Social (entertainment, enjoyment, or passing time).• Relationship (build rapport, teamwork, trust, and commitment).• Information exchange (present, learn, and share).• Collaborate (work toward common goals or outputs).• Resolve problems (address issues, remove barriers, vent hostility).• Inf luence (persuade, negotiate, or direct).

You may find it useful to identify your purposes and describeyour situation in order to anticipate the way in which you and theothers involved may respond. Start by identifying your motivationsource (personal need served).

Over the course of a project, shifts in purpose and situationsoccur almost routinely. For example, you may start a project withgenerous support from the functional engineering department, onlyto witness that support later wane as another project competes forthe same resources. Apply the following when collaboration sud-denly turns to negotiation:

• Identify or reinforce the common vision or expected outcome.• Identify the interests of each party in the outcome.• Have each party prioritize his or her interests.• Generate alternative solutions.• Choose the solution that satisfies the most interests of both parties.

We next discuss communication techniques that are often over-looked or underused to the point of project failure.

View Dialog as a Core Process

Fundamental communication techniques are brought into playwhenever one project member engages another in conversation. Thepotential impact of the ubiquitous one-on-one conversation is toooften ignored or taken for granted. The caricatures in Figure 5.3 il-

“Communication is the soul ofmanagement: analysis andsolid decisions translated intoclear messages that influencepeople to act and feel goodabout their performance.”

Dianna Booher6

“Talk is by far the most acces-sible of pleasures. It costsnothing in money, it is allprofit, and it completes oureducation, founds and fostersour friendships, and can beenjoyed at any age and inalmost any state of health.”

Robert Louis Stevenson

cott_c05.qxd 6/30/05 3:04 PM Page 54


lustrate a few of the situations we have all been in—on one side orthe other.

Hundreds of valuable and creative conversational techniques areexplored in the sources listed earlier. Brown and Isaacs cite researchdemonstrating that informal conversations can often be much morepowerful and satisfying than formal communication processes. Theyoffer this thesis: “Consider that these informal networks of learningconversations are as much a core business process as marketing, dis-tribution, or product development. In fact, thoughtful conversationsaround questions that matter might be the core process in any com-pany—the source of organizational intelligence that enables the otherbusiness processes to create positive results.”11 We hasten to add that,while informal conversation techniques can be effective, their utilityand power is greatly diminished when they are practiced as a substi-tute for inadequate project visibility and statusing processes.

By definition, deep dialog goes beyond an informal conversation.It extends to the exchange of constructive feelings and attitudes inorder to reach a common understanding. The practice of this commu-nication technique is a good sign that teamwork is f lourishing. Open-ness and sharing can elevate passive dialog to active collaboration andcreate an environment for resolving conf lict, but it requires the in-vestment of time. One useful technique is to selectively schedulemeetings with no fixed agenda to facilitate open-ended discussions.

To promote dialog as a core process, consider these ground rules:

• Test assumptions and inferences.• Share all relevant information.• Focus on interests, not positions.• Be specific and use examples.• Agree on what important words mean.• Explain the reason behind one’s statements, questions, and actions.• Disagree openly.• Make statements, then invite questions and comments.• Do not take degrading “cheap shots” or otherwise distract the group.• All members are expected to participate in all phases of the process.• Exchange relevant information with nongroup members.• Make decisions by consensus.• Do self-critiques.

Be Proactive—Use Glance Management

The most important job for the project manager or technical leaderis to be in touch with the team members. You cannot manage yourproject by sitting in your office all day waiting for people to come

cott_c05.qxd 6/30/05 3:04 PM Page 55


to you. Management-by-walking-(or wandering)-around (MBWA)is a vital skill. Yet project communications often suffer becauseteam leaders spend too much time managing by PowerPoint ande-mail. By occasionally circulating among team members in theirwork setting, team leaders can resolve—or at least learn about—issues that may never make it to a formal review, address morale oreven technical problems before they become issues, or simply enterinto a brief conversation that helps maintain an open culture. InChapter 14, glance management and MBWA are discussed in moredetail.

Improving communications through brevity when less is more.Very often, the real impact of communication doesn’t occur untilthe information is recalled. As a rule of thumb, retention halves foreach of five communication steps, which leaves us with eight min-utes in the bank for a two-hour investment:

We hear half of what is said 2 hoursWe listen to half of what we hear 1 hourWe understand half of what we listen to 30 minutesWe believe half of what we understand 15 minutesWe remember half of what we believe 8 minutes

Beyond two hours in a single session, another factor takes over—fatigue.Hiding problems by saying nothing is not a positive application

of this technique.

Observing and Listening—Encouraging Communications

by Remaining Silent

Perhaps the most difficult communication technique of all is effec-tive listening. We all know this from our own experiences and fromthe proliferation of great thinkers who have lamented the lost art oflistening. Do you sometimes find yourself practicing one of the fol-lowing nonlistening behaviors?

• Dreaming—thinking of other things.• Acting—focusing on delivery methods rather than content.• Rehearsing—formulating responses or rebuttals.• Placating—agreeing, just to be nice.• Derailing—switching.• Debating—discrediting or discounting the message.• Filtering—hearing selectively or with bias.• Knowing-it-all—succumbing to the urge to talk.

“The more you say, the lesspeople remember.”

Anatole France

“It’s a toss-up as to which arefinally the most exasperat-ing—the dull people whonever talk, or the bright peoplewho never listen.”

Sydney Harris

cott_c05.qxd 6/30/05 3:04 PM Page 56


“He knew the precisepsychological moment tosay nothing.”

Oscar Wilde

One listening technique we favor begins by turning off the nat-ural tendency to immediately react to what you’re hearing. It re-quires turning up the gain on your receiver—and turning off yourtransmitter to fully experience the power of remaining silent. Some-times your silence can speak volumes. This is especially difficult ifyou are an expert in your field or a high-level manager and believethat you know it all. But that’s one of the most critical listening sit-uations for understanding and removing barriers, learning freshideas, building rapport, and demonstrating positive leadership at theproject level. Imagine the positive outcome if NASA managementhad really listened to the Challenger and Columbia interactions dis-cussed earlier.

Polling Techniques—Overcoming the Danger of

Remaining Silent

What do you do when people withhold their interpretations for thewrong reasons?

In her Tip 40, Dianna Booher asserts that you need to hear si-lence as it is intended (and we add, not as you want to interpret it).

She points out that people who believe that silence is consent arein for a big disappointment. She identifies 16 meanings for silence,including ref lection, confusion, anger, revulsion, rebuke, shock, andpowerlessness.12 We add one that often dooms projects: fear.

Polling is a communication technique that has been traditionalin aerospace programs for years. It consists of addressing individu-ally each representative in a launch operation and recording his orher decision as to proceeding with the launch. Every individual hasthe right and obligation to stop a launch if his or her area is notlaunch worthy.

The power of using this technique, and the danger of inappro-priately omitting it, is illustrated by ABC Television’s faithful reen-actment of the Challenger launch decision telephone conferencewith Thiokol. It shows a team of responsible Thiokol engineers beingoverpowered by their management, who are determined to pleaseNASA officials with a favorable launch decision even though the en-gineers believed that the low launch temperature was far too riskyfor the solid rocket booster O-rings. NASA attempted to ensure thatThiokol’s decision was based on team consensus by asking over theconference call telephone, “Is there anyone in the room with a differ-ent opinion?”13 The engineers fearfully remained silent, their facialexpressions and body language telling the true story of their discom-fort with the reckless decision. NASA management was unable to see

“The best way to persuadeothers is with our ears.”

Dean Rusk

“There are no facts, only inter-pretations.”

Friedrich Nietzsche

cott_c05.qxd 6/30/05 3:04 PM Page 57


the telling body language so that critical communication did notoccur. Had NASA recorded a poll requiring those present to statetheir name and launch decision, the launch probably would have beenpostponed.

Make Meetings Meaningful—and Don’t Neglect to Follow Up

This subject is addressed in Chapter 15, where meetings are re-ferred to as the project manager ’s dilemma. High-value meetingsare critical to project success while ineffective meetings can beworse than wasteful—they can destroy morale.

Constructive Feedback—Ensuring That the Exchange Is

Understood by All

You haven’t fully communicated until your intended meaning is con-firmed through your audience’s response or by some other form offeedback. For instance, the buyer and seller in the cartoon in themargin have very different views of what a “house” should be.

The importance of this communication technique is not onlycritical when eliciting requirements, but at every step in the projectcycle. Feedback provides the basis for project decisions:

Fast feedback enables fast decisions.Fast honest feedback enables fast sound decisions.

Projects are driven by the project cycle with its reviews and de-cision gates. Since these events bring together the key stakeholders,they offer one of the most powerful and efficient opportunities forproject communications. But unless that all-important feedback loopis reinforcing and constructive, the experience will be worse than nocommunications at all. Some situations can benefit greatly from atwo-way feedback agreement to establish trust and create a comfort-able environment for candor. Here’s one approach to consider:

In order for us to be effective, I give you permission to be totally hon-est with me. (As long as you focus solely on work content and don’t at-tack me as a person.)

I will do my best to comprehend your message and to remaincalm and objective as we resolve the issues together.

In turn I intend to be honest and forthright with you.

Feedback works best as part of an organizational culture thatencourages it to be given and received without reservation. Keepthese guidelines in mind:

cott_c05.qxd 6/30/05 3:04 PM Page 58


Effective Ineffective

Frank and objective Emotional and personalSpecific and complete General and vagueActionable Not actionableFacts OpinionsTimely Ill-timed

Before providing feedback, consider the categories depicted inFigure 5.4. Your approach should take into account the potential forconf lict (e.g., the degree of criticism or counseling), the sensitivityof the receiver, and your own skills.

In the management of projects, access to facts is necessary butnot sufficient. There must be confirmation that key decision makersare cognizant of the relevant facts and are bringing them to bear ondecisions important to the project. This is best accomplished at deci-sion gates where proof of concept performance and proof of designproducibility provide the basis for moving ahead. In the conduct ofdecision gates, constructive challenge and constructive feedback arekey to achieving confidence. Receivers must be open to this inputand concentrate on hearing the suggestions and solution as best in-tentions. No matter how caustic the delivery may be, don’t react as ifyou are attacked personally or you may end up shooting the messen-ger and inhibiting future valuable information.

Decision gates are not the only forums for constructive feed-back. Others include: personnel performance reviews, project statusreviews, fee evaluation reviews, proposal evaluations, proposal de-briefings, peer reviews, red team reviews, and tiger team reviews.There is no limit to the additional informal opportunities and meth-ods for providing essential, ongoing feedback, including conversationaround the water cooler.

Figure 5.4 Providing feedback.

COMMENDING

CONVERSING COLLABORATING

COUNSELING

Potential for conflict and need forcommunication skills and a thick skin

Significance ofcontent

and impact

Feedback Categories

“The secret of running a suc-cessful business is to makesure that all key decision mak-ers have access to the sameset of facts.”

Jack Welch14

cott_c05.qxd 6/30/05 3:04 PM Page 59


We have found peer reviews to be very effective when the re-view methods of all parties are aligned. There are three distinctivetypes of peer reviews for content and quality:

Type 1—Please Comment• Author requests comments.• Commenter provides comments without expecting feedback.• Author decides what will be incorporated and what will be ignored.

Type 2—Collaborate to Consensus (C2C)• Author requests C2C.• Reviewer(s) provides comments and expects discussion or de-

bate resulting in consensus.• Both are willing to vigorously defend the agreement.

Type 3—Red Team Reviews are used when comparing to areference such as a request for proposal or an industry standard.

• Reviewers score against preestablished criteria.• Reviewers assess strengths and weaknesses.• Reviewers recommend improvements.• Authors discuss details with the reviewers to ensure under-

standing of the scoring, strengths, weaknesses, and recommen-dations, but not to debate their validity.

• Authors respond to the reviewers’ suggestions as the authorsdeem appropriate.

THE ENVIRONMENT

This section considers the organization’s project environment,which has about as much variation as does the world’s political land-scapes—from free and open to dictatorial and suppressive.

Effective leaders need to be able to listen, and not doing so canhave dire consequences. In the final report on the Columbia Acci-dent Investigation,16 the Board noted the similarities between thetwo shuttle disasters and commented:

Risk, uncertainty, and history came together when unprecedentedcircumstances arose prior to both accidents. For Challenger, thelaunch time weather prediction was for cold temperatures that wereout of the engineering experience base. For Columbia, a large foamhit—also outside the experience base—was discovered afterlaunch. . . . In both situations, all new information was weighed andinterpreted against past experience. . . . Worried engineers in 1986

“A major obstacle to thedevelopment of a commonlanguage is our relative insu-larity. In the same way thatphysical isolation breeds lan-guage dialects, our intellectualisolation has bred projectmanagement dialects.”

William Duncan15

cott_c05.qxd 6/30/05 3:04 PM Page 60


and again in 2003 found it impossible to reverse the Flight Readi-ness Review risk assessments that foam and O-rings did not posesafety-of-f light concerns. . . .

In the Challenger prelaunch teleconference, where engineerswere recommending that NASA delay the launch, the Marshall SolidRocket Booster Project Manager repeatedly challenged and discred-ited Thiokol’s risk assessment. Similarly, Columbia’s Mission Man-agement Team Chair made statements reiterating her understandingthat foam was a maintenance problem and a turnaround issue, not asafety-of-f light issue.

In both cases, engineers presented concerns as well as possible solu-tions—a request for images of Columbia and a temperature con-straint on Challenger’s launch. Management did not listen to whattheir engineers were telling them and instead overruled their in-formed technical recommendations.

The organizational structure and hierarchy stif led effective com-munication of technical problems.

A Balanced Environment Encourages Feedback

An organization’s culture and process should not become one wherefeedback providers must spend excessive time massaging the mes-sage so as not to irritate the receiver. Speed and clarity must prevailin the interest of achieving swift but informed decisions.

Feedback receivers must develop immunity to being offended inthe interest of swift, clear communication. A Tef lon coat or thickskin helps. The receiver also needs to give the provider some slack.

Stovepipes and Silos

One form of organizational isolation is known as stovepipes or silos.This jargon refers to virtual barriers proudly built by functionalteams of a single discipline or power group. If not carefully man-aged, we might end up with “we creators” and “those bean counters”or, as another example, “our night shift” and “that dazed shift” orany other equally derogatory division. These virtual barriers, whichare so proudly built, not only partition and inhibit communicationbut also foster negative communication that alienates and punishes.One of the authors would visit customers without informing hismarketing personnel because he felt they were not technically qual-ified. This practice is seriously wrong and can be disastrous for anyproject depending on free and open communication to ensure thebest decisions.

IR

EE

NIG

NE

GN

NA

NIF

EC

TE

KR

AM

GNI

Silos

cott_c05.qxd 6/30/05 3:04 PM Page 61


LANGUAGE AND VOCABULARY—THE MANYMEANS USED TO EXPRESS THOUGHTS

By language we mean everything from a common vocabulary to ap-propriate attire and body language, and we also include the effectiveuse of silence. Some simple advice regarding body language: Believethe body language you’re seeing if it conf licts with the words you’rehearing. Likewise, intonation speaks louder than words.

Verbal communication problems are sufficiently widespreadthat they are spawning a niche business. Some consultants are find-ing that by the time project requirements are translated into imple-mentation tasks communicated either orally or in written form, theresulting task may have little to do with satisfying the project’s re-quirements and objectives. These consultants report eliminating atleast 40 percent of potential project work deemed irrelevant to theintended outcome, significantly reducing the project’s cost. Thecause of this inefficiency is illustrated by the parlor game where astory is passed around the table. When the last person recites thestory to the group, there is usually little similarity to the original.This same message erosion can occur in the project environment ascontract terms are converted into system requirements, which areconverted into concepts and architectures with design-to specifica-tions. Designers then respond to the specifications without everhaving seen the parent documents. This environment is one wheremisinterpretation can occur and grow unchecked. One of the rolesof systems engineering is to audit project work in the light of thecustomer’s objectives to ensure that all work is properly contribut-ing to the planned result.

Graphical languages, such as UML and SysML (discussed brief lyat the end of this section and in more detail in Chapter 9), are play-ing an increasing role in project communication, particularly for com-plex systems where words may not be enough (or may be too much).

To Communicate Effectively, You Have to Think Clearly

and Use a Common Vocabulary

The successful practice of project management and systems engi-neering involves areas of conf lict that can only be resolved with aclearly defined vocabulary.

John Beckley articulates the essence of clarity: “It isn’t hard towrite something which, if a person takes the time to study it, is ab-solutely clear. But writing that has to be studied is not good com-munication. The meaning of good writing is so immediately clear

To communicate clearly, youfirst have to think clearly.

cott_c05.qxd 6/30/05 3:04 PM Page 62


and obvious, it doesn’t have to be studied.”17 Beckley tells the fol-lowing story about a man who wrote to a government bureau askingif hydrochloric acid could be used to clean the tubes in his steamboiler:

This was the bureau’s reply: “Uncertainties of reactive processesmake the use of hydrochloric acid undesirable where alkalinity isinvolved.”

In appreciation, the man wired back: “Thanks for the advice. I’llstart using it next week.”

Washington wired back urgently, but still in the bureaucratic jar-gon: “Regrettable decision involves uncertainties. Hydrochloric acidwill produce sublimate invalidating reactions.”

This extra courtesy prompted this acknowledgment: “Thanksagain. Glad to know it’s okay.”

Finally, another urgent, but unmistakable, message: “DON’TUSE HYDROCHLORIC ACID! IT WILL EAT THE HELL OUTOF YOUR TUBES!”

Our society criticizes attorneys and politicians for their confus-ing, often incomprehensible, prose. It seems intended to obscurerather than to clarify events. But in a similar fashion, managers andtechnical people often use confusing jargon.

Unfortunately, Orwellian “doublespeak” has proliferated to allsegments of politics and business, often in the form of jargon thatfinds us blaming everything on “paradigms” or a lack of “infrastruc-ture.” On the other hand, capitalizing on new technologies and prac-tices can be facilitated by emerging, appropriately defined jargon.

Acronyms can simplify communication if they are uniformly un-derstood by the team. Remember to leave the jargon behind andspell out the acronyms when making presentations or writing for au-diences outside the project environment. If acronyms are used, de-fine them as they are introduced and provide a glossary.

The truly impressive communicator doesn’t set out to impressanybody—just tries to get ideas across in the simplest, clearest fash-ion. Such a person is likely viewed as an outstanding communicatorand project contributor.

We All Speak the Same Language, Don’t We?

Many words, which are viewed as synonyms in common usage, haveunique and distinct meanings in a technical sense. Stress and strain,commonly used interchangeably to refer to personal anxiety, refer toquite different technical phenomena, as do the project managementterms verification and validation. Few people confuse bread with its

“Snow jobs”—intended ornot—can backfire. Your wordsmay mean something quitedifferent to your listener.

Jargon needs to be used as ameans, rather than becomingan end, for communicating.

All too frequently, when anengineer sounds as if she’sspeaking a foreign language—one composed mostly ofacronyms—it’s because shewants to.

cott_c05.qxd 6/30/05 3:04 PM Page 63


chief ingredient, f lour, but the ingredient cement is often used in-correctly to refer to concrete. Not many people care, but the distinc-tion is critical if you are a civil engineer or a building contractor.

The assumption that we have a common language when we don’tcan have far worse consequences than trying to communicate non-verbally. After all, as jargon proliferates, the language of choice willoften revert to the more trustworthy standby: body language.

A leading corporation asked us to participate in a team buildingsession convened to identify the opportunities, associated risks, andappropriate actions for a new team. It was the first time the com-plete team had been brought together, so the project manageropened the meeting with a 40-minute overview of the project. Wejotted down approximately 20 terms we didn’t understand and laterasked the team members which of the terms they understood. Overhalf of the group didn’t understand any of the 20 terms. Without aclarifying reference, the team didn’t get the important message theproject manager was trying to convey. But each member remainedsilent, being too embarrassed to ask and assuming the others knew.The most dangerous assumption was on the part of the project man-ager, who assumed everyone understood.

A major corporation signed a contract with a foreign govern-ment to rebuild that country’s entire communication structurewithout understanding the meaning or implications of many of thecontract provisions. The resulting five-year, multibillion dollarproject was completed on time but at zero profit—not a career-enhancing outcome.

To prevent misunderstandings, one U.S. government agency in-cludes electronic and printed versions of their terminology manualwith their request for proposal (RFP) so that all received proposalsare based on identical definitions. Similar techniques are proliferat-ing to other project environments.

Each project needs its own terminology baseline. To make thispoint in our training sessions, we ask the class to define several com-monly used terms. We frequently select the following five from asubstantial list of misunderstood terms: prototype, baseline, qualifi-cation, verification, and validation.

The class participants always argue among themselves as to thecorrect meanings. The debate continues inconclusively until the or-ganization’s project management terminology manual is used to clar-ify the meanings.

There is a need for a common vocabulary at the project level be-cause most enterprises don’t have a common vocabulary and wordsare used differently across projects, companies, and industries. Fur-thermore, broad-based terminology manuals are often imprecise.

The listener’s ego maydiscourage him from seekingclarification.

It can be very costly to assumepeople understand when theydon’t.

“Validation” is a good exam-ple. The PMBOK ® Guidedefines validation as ensuringa product complies with thespecific requirements,whereas ISO 9000: 2000 (citedin the INCOSE Handbook)defines validation as, “confir-mation by examination andprovision of objective evi-dence that the particularrequirements for a specificintended use arefulfilled.”

cott_c05.qxd 6/30/05 3:04 PM Page 64


INCOSE The INCOSE Handbookdefines baseline as, “a specifi-cation or product that hasbeen formally reviewed andagreed upon, that thereafterserves as the basis for furtherdevelopment, and that can bechanged only through formalchange control procedures.”

The term qualified was not understood and not responded toduring the prelaunch readiness review of the space shuttle Chal-lenger, leading to the O-ring failure and causing the tragic deaths ofseven astronauts. One of the decision makers in the Flight Readi-ness Review asked, “It’s my understanding that the Solid RocketBoosters are qualified by contract for operation between 40 and90°F. . . . Are the solids qualified to 40 degrees or aren’t they?”18

The question was never answered, and since the predicted tempera-ture at launch was 29°F there should have been no question aboutpostponing the launch.

The process of creating a terminology manual of any kind is nottrivial. Consider the plight of James Murray when he agreed in 1878to take the assignment as editor to create the Oxford English dictio-nary.19 The job had been scoped several years earlier as a two-yearproject involving 60,000 definitions. It was completed 50 years laterwith over six million definitions (estimating project size and durationhas never been easy). However, the process we use today to build aterminology manual is not unlike that used by Murray, where multi-ple sources must be consulted to create a meaningful document.

When building a project-management terminology manual, onewould think that, in the present era, existing sources in the disci-plines supporting projects would provide a strong starting point.However, in reviewing one 387-page dictionary of mechanical de-sign, we could not find common project terms such as prototype, en-gineering model, mock-up, specification, or qualification.20 Yet, it isthe mechanical designer who must implement those concepts on anyproject involving hardware. Fortunately, the software profession hasbeen more aware of the need for accurate definitions; four of thesefive terms were found in the appendix to a software tutorial.21

When we turned to a well-respected reference from the project-management field, we were astounded by the absence of the termrequirements, which not only represents the intersection of projectmanagement and systems engineering but drives them both. We de-vote Chapter 9 to this topic. The PMI PMBOK® Guide uses scope torefer to requirements.22 Though these words are not identical inmeaning, this clearly illustrates the need for terms to be carefullydefined on your project. It also emphasizes the need for complete-ness. Requirement is a term widely used in high-technology indus-tries, and scope is widely used in the construction field.

A terminology database, tailored to the project at hand, can go along way toward fixing the problem. It needs to consider the termi-nology appropriate to the industry, company, and the specific proj-ect. The cardinal rule in constructing a project vocabulary is tomake sure every item added is justified. It must contribute more to

PMBOK ® GuideThe PMBOK ® Guide Glossarydefines baseline as “theapproved time phasedplan . . . plus or minusapproved project scope, cost,schedule, and technicalchanges.”

A secondary benefit of a project-terminology databaseis the increase in everyone’ssensitivity to the need for pre-cise communications.

Why use “utilize” when youcould utilize “use”?

PMBOK ® GuideBoth the PMBOK ® Guide andthe INCOSE Handbook includeglossaries of terms.

cott_c05.qxd 6/30/05 3:04 PM Page 65


understanding than it detracts as potential excess verbiage. Try firstto use ordinary language to represent a needed concept, using shortwords where possible. Only if the resulting expression is undulyburdensome should a new term or acronym be coined or borrowedfrom a related field or industry. In the latter case, the use of the ex-isting nomenclature should clarify, rather than mislead, through itssimilarities.

When Words Are Not Enough (or Too Much)

Flowcharts and behavior diagrams have long been used for express-ing ideas and designs. In recent years, these forms of graphical com-munication are replacing the written word as a means to expressproject requirements and as a primary artifact throughout systemdevelopment. The emerging role of the Unified Modeling Lan-guage™ (UML) and SysML in systems engineering is discussed indetail in Chapter 9 and in Appendix C.

The need for more precision to express requirements and con-cepts for complex systems is one reason for the growth in popularityof graphical languages and diagramming. The other main driver,analogous to the growth of the ubiquitous spreadsheet made into ahousehold utensil by Lotus123, is the availability of productivitytools that support language standards such as UML and that inte-grate with other productivity tools.

Some Critical Decision Gates Have Critically

Confused Titles

While the definition of decision gates involves more than terminol-ogy, some titles themselves have been a historical source of confu-sion. We will use this section to clarify particularly egregiousnomenclature. Decision gates are discussed in more depth in thenext chapter.

Professional societies have defined decision gates that are com-mon to both government and commercial projects. Since these defi-nitions are being broadly adopted by commercial industry ininternational environments, it is important to alert new users to mis-leading nomenclature. Some decision gate titles are incorrectlybased on their position relative to design approval (e.g., being pre-liminary to or critical to design approval). There is no universal setof terms all agree to. The Preliminary Design Review is also calledan Initial Design Review by some and a High Level Design Reviewby others. The intent of these three reviews is similar, but not iden-

cott_c05.qxd 6/30/05 3:04 PM Page 66


tical. The terminology we have selected is in wide use and clearlyrepresents the concepts we wish to convey.

The Preliminary Design Review (PDR) is actually the final“design-to” of the concept, specification, and verification plan re-view. PDRs are really Performance Guarantee Gates because testand analytical evidence should prove that all performance numbersare achievable, that no significant performance risk remains, andthe end product will satisfy the customer. But in many PDRs youcan count on only three things: coffee, donuts, and pictorials of theproject approach. Specifications (major evidence to be evaluated)are often conspicuous by their absence, as are verification plans,having not yet been developed. Because it’s preliminary, the audi-ence is easily contented, although it should not be. This confusingterminology may well cause the team to not deliver their decisiongate products. Countless hours are wasted in PDRs that don’t satisfythe criteria for the review.

All decision gates are the final points for important project de-cisions. Even though one of the better-known decision gates iscalled a Critical Design Review (which is the “build-to” design re-view), all decision gates are critical events in the project cycle.Critical Design Reviews (CDRs) are really Production GuaranteeGates because test and demonstrations should prove that buildingand coding to the proposed documentation is achievable with ac-ceptable risk and that the end product will satisfy the customer.That is, the design approach and processes are well understood andare repeatable.

The most critical of all design reviews is the System ConceptReview where the system concept is approved, thereby committingto the associated life cycle costs and risks of the concept selected.

Formal Is as Formal Does (Not as Formal Says)

We often find that formality is erroneously associated with theamount and appearance of documentation, rather than properly re-lating to project conduct that’s in accordance with establishedforms, conventions, and requirements.

Formality has to do with team adherence to baselined principlesand practices regardless of the elegance of their documentation.Well-documented projects are sometimes undisciplined, ignoringtheir own documentation and operating in an informal mode. Con-versely, we have witnessed projects with almost no documentationthat operated in accord with the requirements and conventionsadopted by the project—a very formal and binding discipline.

There is nothing uniquely criti-cal about the Critical DesignReview. It would be bettercalled the ProductionGuarantee Gate.

There is nothing preliminaryabout the Preliminary DesignReview. It would be bettercalled the Performance Guarantee Gate.

The most critical decision gateis the System Concept Review.

cott_c05.qxd 6/30/05 3:04 PM Page 67


Formality relates to whether the agreements (oral or otherwise) are“binding.” A “make a promise, keep a promise” culture is formal.

Accountability—Walking the Talk

Project managers should hold their teams accountable to the projectvocabulary. It is reasonable to have team members certify that theyhave read the baseline project terminology and that they are com-mitted to using it.

PROJECT COMMUNICATION EXERCISES

Jot down your definitions for prototype, baseline, qualification, ver-ification, and validation. Compare what you have to the definitionsin the Glossary.

For your project, identify the means used for communicatingand prioritize them as to their importance. Based on the informationprovided in this chapter, identify potential improvements.

Rank the four communication model factors (participant behav-iors, techniques, environment, and language) as to their relativecontribution to your project communication problems. Identify sev-eral examples of situations or behaviors that illustrate your highest-ranking problem areas and compare your results with others in yourorganization.

Accountability is an importantpart of every project’svocabulary.

cott_c05.qxd 6/30/05 3:04 PM Page 68

69

6TEAMWORK

“Coming together is a begin-ning. Keeping together isprogress. Working togetheris success.”

Henry Ford

There was a period during which the U.S. government taughtadversarial project management. The theory was that contractorsbeing told they were not measuring up would cause a positivereaction—work harder to improve—thereby benefiting thegovernment. Teamwork waned, as did morale. One governmentagency, the CIA, did not subscribe to this philosophy and decidedto find a better way to enhance teamwork and enhance bothcreativity and productivity. In 1988, Len Malinowski was assignedto develop a precedent-setting project management trainingprogram. It was to baseline the combined best practices in bothproject management and systems engineering for the entireagency. Len took this learning experience one step further,campaigning to team the government project manager with therelated contractor project manager. Security and ethics barrierswere thrown at Len, but he prevailed and the two-week, off-sitelearning experience was based on the teamwork concept. Thirty-five hundred personnel in team pairs learned of each other’sobjectives, methods, and biases. At the same time, they learned acommon vocabulary and a common approach to managingtechnical development projects. As a result, project performancedramatically improved throughout the agency. The program logo(at the end of this paragraph), prominent throughout the trainingmaterials, stressed the importance of teamwork. Therelationships were characterized as partners hooked at the hipwhile in an arm’s-length business relationship. The mostsuccessful learning experiences occurred when an entire projectteam of government, contractor, and subcontractor personnelwas trained as an intact team at project start-up.

PMBOK ® GUIDE This chapter is consistent withPMBOK ® Guide Sec 9.3.2Develop Project Team: Toolsand Techniques.

INCOSE The INCOSE Handbookemphasizes the value ofteamwork in the introductorysections and in Section 5, SEProject ManagementProcesses.

Essential 3

cott_c06.qxd 6/30/05 3:03 PM Page 69


Of all the challenges facingproject teams, the greatestinvolves the peoplethemselves.

Few terms are as evocative oftoday’s desired work setting asteam and teamwork.

Team effectiveness relies on many things, including chemistry,attitudes, and motivational sources. Achieving real teamwork

depends on three steps:

1. Forming a group capable of becoming a team,2. Creating and sustaining a teamwork environment, and3. Inspiring teamwork success through leadership.

In this chapter, we focus on the second of these: creating andsustaining a teamwork environment. Team formation emphasizes thetechniques for selecting the right people and defining their roles—an ongoing process throughout the project cycle. The motivationaltechniques needed to sustain the project team are an integral part ofleadership.

WHY DO SO MANY TEAMS FAIL?

Teamwork, so essential to effective project performance, receivesconsiderable attention today. We want our project staffs to becomeempowered teams—perhaps even self-directed teams. We organizeour work groups into integrated project or product teams. We useRed Teams for peer review and Tiger Teams to solve problems. Tomanage quality achievement, we team with our customers. We haveContinuous Improvement Teams. We agonize over the impact oftelecommuting on teamwork. And then with all this emphasis onteaming and teamwork, we still collect groups of people, tell themthey’re empowered, leave them alone, and hope that a functioningteam somehow emerges from that forced proximity of a small con-ference room or an Internet facilitated collaboration.

If that wished-for team fails to emerge from the self-discoveryprocess, then we resort to an event called a “team build” at an off-sitelocation. The staff discusses goals and generates mission statements.The event is full of good social activities—perhaps the traditional“build a tower out of drinking straws”—and even some outward-bound type of outdoor experience like a “trust fall.” Then, full of so-ciable camaraderie, we go back to work and watch the team thatstarted to jell so nicely in the woods or at the conference site fallquickly and quietly apart, back into the collection of individuals thatwe started with (Figure 6.1).

Failure usually results from a lack of a common approach to ac-complish the work as a team. Inadequate leadership fails to createthe environment in which teams can f lourish. Furthermore, poten-tial team members are seldom trained in how to share their efforts to

Once a group is formed, thepeople tend to believe they area team even when they’re not.

When teamwork fails, it’sseldom due to lack of goodintentions.

cott_c06.qxd 6/30/05 3:03 PM Page 70

TEAMWORK 71

The image of an orchestraperformance reflects today’sreal project environment andthe nature of operating projectteams.

accomplish team goals. The team may also assume they know moreabout teamwork than they actually do. So we need to be able to dif-ferentiate between superficial teamwork and the real thing.

THE FUNDAMENTALS OF AN EFFECTIVETEAMWORK ENVIRONMENT

Effective teams share several common characteristics. They can ar-ticulate the common goal that they are committed to achieve. Theyacknowledge their interdependency with their teammates, coupledwith mutual respect. They have accepted boundaries on their ac-tions—a common code of conduct for the performance of the task.They have accepted the reward of success they will all share. Addteam spirit and a sense of enjoyment when working together, andthe result can be a highly effective and efficient team that producesquality results.

One of our metaphors for a team is an orchestra with a commonscore and a conductor. A successful performance depends on the di-rection of the score (project plan) and a single point of accountabil-ity for setting the tempo. However, having a conductor just wave thebaton (or a project manager authorize tasks, which is the functionalequivalent in today’s project environment) is insufficient to buildand sustain a team.

Figure 6.1 The “work” in teamwork.

The special recognition usually given to the “team” portion of teamworkmakes members aware of the need for cooperation.

Most team efforts fail because of insufficient attention to the

Yet many teams fail.

involved.

cott_c06.qxd 6/30/05 3:03 PM Page 71


Our dilemma today is that we can’t take the time or risk for self-directed group discovery. And merely having a project manager and akick-off event is insufficient to sustain real teamwork. So, where dothe shared goals, the sense of interdependency, the common code ofconduct, and the shared rewards come from? That’s the work of cre-ating teamwork.

Fundamental 1: Common Goals

In contrast to a conventional, ongoing functional department, projectteams are usually comprised of a heterogeneous group of people fromvarious functional responsibilities. For this reason, as well as the na-ture of project people and the teamwork culture, each team memberwants involvement and proactive participation in management activi-ties. These include planning, measuring, evaluating, anticipating, andalerting others to attractive opportunities and looming risks.

Building teamwork begins with clearly defining the individualand joint objectives and outlining the various roles and responsibili-ties required to accomplish the objectives. Gaining consensus for thetop-level goal is often easy. You must probe to the second or third tierto reveal and resolve overlaps and gaps. Having that team activityavailable, ask each member of the group, “Now that you understandthe content of the tasks, do you really want to be a member of thisteam?” A “yes” identifies a potential team member.

Fundamental 2: Acknowledged Interdependency and

Mutual Respect

We concur with Stephen Covey’s assertion: “The cause of almost allrelationship difficulties is rooted in conf licting or ambiguous expec-tations around roles and goals.”1 In the team environment, mutualrespect, relationships, roles, and interdependencies are inextricableand develop in concert.

At the project’s beginning, a revealing team effort is definingroles. After team orientation and goal setting, the task of preparingpersonal task descriptions provides a maturity calibration point andoffers a revealing way of getting feedback regarding team role per-ceptions. The following are steps for the team to acknowledge inter-dependency and to establish expectations:

• Define thespecific functions, tasks, and individual responsibilities.• Develop an organizational structure and define team interde-

pendencies.• Define the scope of authority of each member.

Significant involvement leadsto a sense of responsibilityfor—and therefore, commit-ment to—project goals.

cott_c06.qxd 6/30/05 3:03 PM Page 72

TEAMWORK 73

Roles and mutual dependen-cies need to be acknowledgedby all project members.

Some roles are assumed, undeclared, and /or undefined, includingpersonal activities such as tutor, interpreter, cheerleader, or trou-bleshooter. While there are usually formal, written responsibilitiesfor project managers and leaders, team members’ roles are too fre-quently unwritten. In her book, Star Teams, Key Players, Jackmanemphasizes the responsibility of each team member for ensuring out-standing performance of the team by becoming a key contributor.2 Aseach member is added to the team, it is a wise, proactive practice forthat new member to define his or her roles and to have those roles ac-knowledged by the rest of the team and the project manager. Thenthe roles are adjusted as appropriate, to create both team synergy andminimize discord.

Later, in the planning process, the cards-on-the-wall technique(discussed in Chapter 12) provides a highly effective team buildingopportunity. As the schedule network evolves, personnel interde-pendencies are easily recognized.

You can have well-defined responsibilities, but if the interdepen-dencies are not acknowledged, there is no basis for teamwork—only awell-structured individual effort. For interdependencies to be recog-nized, there must be an acceptance of, and respect for, the roles thatmust be filled by each team member.

Like teamwork itself, mutual respect is easier said than done.You need to be aware of, acknowledge, and accommodate bothstrengths and weaknesses—both yours and others’.

Role biases can be major roadblocks to respect, and that canlead to potholes, as one of the authors learned long ago when mixingasphalt for a road-resurfacing project. The contractor personnel tookgreat pleasure in fooling the state inspector. A faulty scale allowedtoo much sand in the mix, causing the inspector to approve everybad batch. The workers thought it was a great joke until they de-pended on those roads. Many years later, the potholes are still agrim reminder of the deficient mix, and especially of the lack of ap-preciation for the inspector ’s vital role.

Role biases can be particularly true of the project managementand systems engineering disciplines. Systems engineers often seethemselves as the key technical contributors carrying the rest of theproject on their “technical backs.” They sometimes believe that noone else is capable of communicating with them or of appreciatingtheir “contributions.” Likewise, project managers believe systemsengineers have little regard for cost and schedule. This book is in-tended to help overcome these communication and teamwork barri-ers by providing the information necessary for the entire team toparticipate in determining the system solution approach.

Mutual respect means accept-ing the need for the role per-formed by each team memberand respecting his or her com-petency, especially if it is out-side your field of expertise.

cott_c06.qxd 6/30/05 3:03 PM Page 73


The right time to address legaland ethical issues is when theyare only potential problems—before they become a career-limiting lesson learned. Whenit comes to conduct, just as inplanning, an ounce of preven-tion is worth a pound of cure.

In a production environment, manufacturing often sees qual-ity assurance (QA) as an enemy to be circumvented rather thana vital member of the team necessary to project success. Con-versely, QA has been known to stop production lines just to exerciseits authority.

The space shuttle tile program, which developed and producedthe external heat shield for the orbiter vehicle, demonstrates howteamwork, based on mutual respect, can mean the differencebetween success and failure. In the transition from research to pro-duction, problems occurred that no one knew how to solve. Manufac-turing and QA personnel worked together very effectively, helpingeach other resolve the many technical challenges. Responsibilities fortraditional QA tasks were even shifted between organizations whenpeople on the production line found a better way. A true cooperativeand lasting team spirit, based on mutual respect, was developed be-tween manufacturing and QA.

Though respect is earned, it begins by putting your critical atti-tude aside and giving others the benefit of the doubt without beingcondescending or patronizing. By keeping an open mind, you can ac-quire respect for your lack of specific skills, for another ’s compe-tency, and for traditionally adversarial roles.

Fundamental 3: A Common Code of Conduct

Legal and ethical issues have been receiving widespread attentionin the news media as more and more companies restate their earn-ings. The most obvious conduct issues are usually well-documentedprohibitions by company or government policies. But they may notbe well known to all team members. And the gray (or ambiguous)areas, especially those involving contractor and customer inter-faces, may not be understood or interpreted consistently. The proj-ect manager is responsible for reviewing these issues, together withthe relevant company policies, to ensure that all team members aresensitized to areas of risk. Figure 6.2 lists legal conduct issues forreview with the team.

Ethical conduct issues are more difficult to enumerate. Ulti-mately, you have to depend on personal values to navigate throughthe possible conf licts that can occur between company practices,laws and regulations, and management direction. When dichotomiespersist, these guidelines may help:

Ask yourself, “Would I beembarrassed if my behaviorappeared on the front page ofthe newspaper?”

cott_c06.qxd 6/30/05 3:03 PM Page 74

TEAMWORK 75

PMBOK ® GuidePMBOK ® Guide Sec 9.3.2.4Develop Project Team: GroundRules relates to the team’scode of conduct.

Figure 6.2 Legal conduct issues.

• Seek higher management guidance to confirm difficult choicesfor conf licts among the various codes of conduct.

• If asked to operate in a potentially improper manner, make surethat the request is written and verify it with the cognizant au-thority. Do nothing that violates your personal ethics.

• Report any improper conduct, anonymously if necessary.

To be effective, a common code of conduct needs to:

• Resolve potential sources of conf lict,• Clear the air on gray areas, and• Cover areas not addressed by other standards such as:

—Working on new scope in response to an oral request and—Threshold value of a change proposal.

Categories to consider include:

Customer relations.Personal use and care of company property.Attendance and work hours.Safety.Sexual harassment.Smoking, alcohol, and drug abuse.Gambling.Falsification of records.

Ask each potential member ofthe team, “Will you commit toabide by these rules of con-duct?”

A “no”will surface issues to beresolved.

cott_c06.qxd 6/30/05 3:03 PM Page 75


Money spent on pizza for allmay be more effective than abonus given to the most out-standing contributor.

PMBOK ® GuidePMBOK ® Guide Sec 9.3.2.6Develop Project Team: Recog-nition and Rewards providesadditional reward information.

Instilling teamwork coopera-tion often begins with unin-stalling the “me-first”competition culture deeplyscripted in most people bytheir education and businessexperience.

Allow the team to come toconsensus even though youknow the answer and couldtell it to them. They will feelmore energized about thesolution if it is theirs.

Acceptance of gifts.Standards of quality.

Fundamental 4: Shared Rewards

Shared recognition for contributing team members of a successfulproject is often far more important than cash bonuses. People aremotivated to do a good job and to cooperate with one another whenthey are confident that their individual and team performance willbe publicly recognized and appreciated by their peers and theirmanagement.

Effective cash rewards begin with fair and equitable compen-sation for team members. You can also devise awards that canbe earned by the entire team. The concept of shared rewardssuggests dividing a bonus pool equally by the number of partici-pants. With this approach, the lowest paid receives the highestpercentage compared to base compensation causing a ground swellof enthusiasm.

A Hyundai executive was forced to resign because he rewarded370 quality management division employees for the dramatic im-provement in Hyundai quality, which surpassed even Toyota. Hiserror was that he failed to reward all 35,000 Hyundai employees.Hyundai ultimately agreed to include all employees, as the unioncontract required, and paid $29 million to the 35,000 employees (ap-proximately $830 per person).

Fundamental 5: Team Spirit and Energy

This quality depends on personal attitudes as well as company cul-ture and begins with:

• An agreement to pool resources.• Interdependence rather than independence.• Desire to do whatever is necessary to succeed.• Placing team needs above one’s own needs.• Never asking the team to do what you are not willing to do.• Setting the example for others to follow.

Independent thinking alone is not suited to the interdependentproject reality. Putting the team ahead of oneself, however, doesnot mean the elimination of strong pacesetters. Driving personali-ties need to exercise their assertiveness and energy without domi-

cott_c06.qxd 6/30/05 3:03 PM Page 76

TEAMWORK 77

Teams don’t always needmanagers to do things right,but leaders always need teamsdoing the right things.

The project manager is themost responsible for sustain-ing a whole that is larger thanthe sum of its parts.

PMBOK ® GuidePMBOK ® Guide Sec 9.3.2.3Develop Project Team: TeamBuilding Activities cites thevalue of project-related team-building events.

The kick-off meeting may bethe best opportunity theproject manager has tocommunicate the projectvision to the team in relation-ship to their work.

nating their teammates. This sometimes involves subtle leadershiptechniques.

TECHNIQUES FOR BUILDING AND SUSTAININGTEAMWORK: THE WORK OF TEAMWORK

Creating and sustaining effective teamwork requires ongoing work onthe part of all team members. Many team building efforts fail eitherbecause essential techniques are unknown or applied inappropriatelyby participants unaware of the situational nature of project manage-ment and leadership.

While team building is a total team responsibility, we will focusfirst on what the project manager can do to foster and nurture a f ledg-ling team. First, we need to refine our image of the team as an orches-tra led by the project manager. In the project reality, the projectmanager is both the composer and the conductor. To quote PeterDrucker, “This task requires the manager to bring out and make effec-tive whatever strength there is in his or her resources—and above all inthe human resources—and neutralize whatever there is as weakness.This is the only way in which a genuine whole can ever be created.”3

Like any other development process, there is a gestation periodinvolved. The project manager must avoid over directing and smoth-ering the team. Alternatively, too much freedom can cause a newteam to founder. The project manager must:

• Clearly define unambiguous responsibilities,• Define and communicate a project process and style,• Delegate wherever possible,• Empower the team to be accountable,• Balance support with direction as required,• Train the team, by example, to operate as a team,• Deal with underperformers who drag the team down,• Establish team-effort rewards, and• Designthe tasksandworkpackages inawaytoencourage teamwork.

The leadership techniques discussed next pertain especially tobuilding teamwork.

The Team Kick-Off Meeting—A Teamwork Opportunity.

The kick-off meeting should be a working session. When properlyled by the project manager, it can provide each team member with a

cott_c06.qxd 6/30/05 3:03 PM Page 77


sense of organization, stability, and personal as well as team accom-plishment. Proper leadership includes a detailed agenda. In Dy-namic Project Management, the authors offer a detailed agenda forthe team kick-off meeting.4 Emphasizing this opportunity to com-mit the team members to a common goal, they list ten meeting goals,which we have paraphrased:

1. Introduce project team members.2. Define the overall project (objectives, goals, strategy, and tactics).3. Describe key deliverables, key milestones, constraints, opportu-

nities and risks.4. Reviewtheteammissionanddevelopsupportinggoals interactively.5. Determinereportingrelationshipsand interactionwithother teams.6. Define lines of communication and interfaces.7. Review preliminary project plans.8. Pinpoint high-risk or problem areas.9. Delineate responsibilities.

10. Generate and obtain commitment.

A video recording of the kick-off meeting is an important resourceto bring new team members up to speed as they join the project.

Team Planning and Problem Solving

In a team context, planning and problem solving are excellent teambuilding techniques, offering opportunities for training, environ-ment setting, and reinforcement. For planning and network devel-opment, we use a technique called cards-on-the-wall, described inChapter 12, to actively involve the project team in the planningprocess. It facilitates team development of the tactical approachand buy in on the planned actions. Once created, the plan willneed to be revisited by the team at each phase transition point toensure that it remains valid and that current plans respond to pre-vious lessons learned.

Defining and Communicating a Decision Process and Style

Even though leadership style and the decision process will vary withthe project situation, most managers have a preferred or defaultstyle that needs to be communicated to the team. This is detailed inthe section on leadership in Chapter 18. In many project environ-ments, a consensus decision process fosters teamwork and is moreeffective than the extremes of unilateral or unanimous decisionmaking, depicted in Figure 6.3.

Planning is a continuingactivity, not a one-time event.

As in football, a successfulkickoff has the team lined upand heading for the commongoal (post).

cott_c06.qxd 6/30/05 3:03 PM Page 78

TEAMWORK 79

A consensus decision process consists of a thorough discussionuntil all team members have had a fair hearing and all members arecommitted to accept and support the group decision. Reaching aconsensus may require compromises, but it does not involve:

• Voting or averaging,• Bargaining or trading-off, or• Steam rolling or f lipping a coin.

Consensus decision making is most effective when:

• You don’t know who has the expertise,• Your facts are insufficient to decide and you need the judgment

of a group of involved personnel, and• You need the commitment of the group for the implementation.

Setting the decision environment is not a one-time activity.Let’s say you’ve decided to operate throughout the project on aconsensus basis. You find that it works well for team planning ofthe project, but not as you get into the actual work. Individual con-tributors with differing work habits and desire for f lexible work

Management styles need tobe appropriate to the situation.The key to success is incommunicating your styleappropriately as well.

Figure 6.3 Alternative decision processes.

UnanimityConsensusUnilateral

Decision TimeImplementationTime

Total Time

Tim

e T

o R

esu

lts

cott_c06.qxd 6/30/05 3:03 PM Page 79


A project information center—or project-specific web site—should portray timely,accurate, and relevantinformation.

When removing a teammember, the manager needsto let the others know why—in direct, factual terms.

Be careful not to leavesomeone out!

schedules make consensus building at each decision point cumber-some. Finally, as you hit a real crisis in the program, you can’t waitfor the team. You make a decision unilaterally and that irritates ev-eryone on the project. The urgency of the situation called for achange in style—an important right for the leader. But teamworksuffers when you change your style without letting the team knowwhen or why a change is necessary. An effective leader reveals thereasons when making a change in management style.

The Project Information Center

Sharing information with the team is a way of reinforcing the visionand setting a good communications example. A room, wall, or website where staff can review current information on the project innear real time offers an efficient means to share information. Cur-rent information also enhances the team’s ability to reach a sharedreward. But what information do you share and how often do youshare it? Typical project dynamics suggest that selecting relevant in-formation throughout the project is essential because as the projectchanges so does the type of information needed, as well as its time-liness. Out-of-date status charts and schedules vividly reveal a lackof attention to the details of project management and the lack of im-portance you place on team communication.

Dealing with Underperformers Who Drag the Team Down

All too often project managers are reluctant to lose a warm body be-cause of scarce replacements. This can be shortsighted. The under-performer may represent more of a drag than his or her contributionrepresents. It also sends the wrong message to the remainder of theteam. They need to know exactly what kind of performance it takesto earn job security.

Team Events and Celebrations

These are opportunities for creative team building. Events that sim-ulate the project environment through outdoor activities, for exam-ple, are extremely useful at start-up time. There is also a continuingneed for team rebuilding throughout the project as new challengesare faced and especially as new project members join. The tech-niques useful in the later stages of the project should focus moreclosely on actual project issues where lessons learned can be incor-porated into the event.

cott_c06.qxd 6/30/05 3:03 PM Page 80

TEAMWORK 81

PMBOK ® GuidePMBOK ® guide Sec 9.3.2.2Develop Project Team: Train-ing covers the role of trainingin team development.

Good performance needs tobe rewarded—what getsrewarded gets done.

Team members should takeany opportunities to reinforcethe team principles presentedin training sessions.

Look for positive events and report them publicly at staff meet-ings and project reviews. Enlist the customer when appropriate. Gooff-site—even if only for pizza and beer (no money is no excuse).

Training

Either as formal courses and seminars or as an integral part of any teamactivity, learning events can contribute significantly to teamwork.Project management and systems engineering courses, such as those weconduct for our clients, are only the starting point for training an ongo-ing management responsibility. Project managers should make oppor-tunities for team members to share their learning experiences.

Reward Achievement

Remember that rewards come in many forms and, wherever possi-ble, should recognize group contributions, as do the shared rewardsdiscussed earlier.

Rewarding achievement is the one technique that most considereasy to apply. There is a talent, however, in rewarding performanceeffectively. For example, if you like to start meetings by recognizinggood performance, you’re obliged to make sure you’re aware of thesupporting details. Many a compliment backfires by irritating some-one else who contributed to the work while the recipient was just themost visible (or worse, the highest ranking). Paying for accomplish-ments is another traditional reward that has to be done judiciously.

Reinforcement

Techniques that emphasize working as a team include: focusing on thecommon goal once established and accepted by the team; maintainingrespect for the functions, roles, and positions within the team; accep-tance of interdependencies; continued acceptance of the evolvingcommon code of conduct; and adjusting the shared rewards as theproject matures. The leader must emphasize the essentials of team-work throughout the project. Posters and slogans around a team room(reminding people of important aspects) can be helpful.

WHEN IS YOUR GROUP REALLY A TEAM?

Teamwork is something everyone claims to believe in. People tend tobelieve they’re a team, even when they are not. It would be useful to

You need to confirm that yourleadership is working on anongoing basis as measured byobservable behavior.

cott_c06.qxd 6/30/05 3:03 PM Page 81


have a means to assess if your team really is one. Kinlaw has drawnon his decades of experience in working with both industry and gov-ernment teams to create a “superior team development inventory(STDI).”5 His inventory questionnaire is presented in the appendixof his book. The surest way to get off on a false start is to convenethe troops for a kick-off session that is little more than a pep talk. Itmay cause good feelings but it will not last. Likewise, it is equally in-effective to use teamwork techniques only as reactions to problems.

Positive Teamwork Negative Teamwork

Indicators Indicators

A positive, cooperative climate A climate of suspicion and distrustprevails. exists.

Information f lows freely Information is hoarded or withheld.between team members.

No work is considered beyond an Finger pointing and defensiveness individual’s job description. If it prevail. needs to be done then someoneis doing it.

Interpersonal interactions are Counterproductive subgroups andspontaneous and positive. cliques begin to form.

The collective energy of the team Fear of failure causes individuals tois high. avoid or postpone making important

decisions.

Real teamwork focuses the The absence of teamwork doesn’t lead energy of a diverse group of just to low productivity, it creates a individuals, having different counterproductive environment that personality traits and skills, to saps the energy of the group and optimally accomplish a common demotivates the individuals.goal.

TEAMWORK EXERCISE

From your personal experience, work related and otherwise, iden-tify those teams that exhibited good and poor teamwork. For eachteam identified, evaluate to what extent they implemented the fourfundamentals to effective teamwork.

cott_c06.qxd 6/30/05 3:03 PM Page 82

TEAMWORK 83

RecommendedFactor Score Reason Improvement

Common goal

Acknowledged interdependency and trust

Code of conduct

Shared reward

Team spirit

cott_c06.qxd 6/30/05 3:03 PM Page 83

84

7THE PROJECT CYCLE

The impact of not establishing a gated project cycle can besubstantial, as in the case of a national Health MaintenanceOrganization (HMO) in the construction of new medicalfacilities. In the absence of a defined project cycle, the HMO’smanagement did not get involved in detailed designdecisions. Further, there were no binding decision gates thatinvolved the appropriate using stakeholders to get formalapprovals of the configuration before proceeding. Forexample, the doctors (the operational users) were notrequired to approve the dimensionally correct floorplan (anearly concept artifact) that vividly displays how the hospital islaid out to support the required medical functions. As aresult, after the hospitals were constructed, the doctorsdirected considerable redesign and rework before acceptingoccupancy—a costly and time-consuming impact. A gatedproject cycle, requiring doctor approvals, was adopted tocorrect this process deficiency.

The project cycle is the sequential Essential of project manage-ment and systems engineering. It’s about progressing from stake

to stake—the decision gates and other timeline events. Figure 7.1 il-lustrates the project cycle format. This chapter presents the signifi-cant features of a basic project cycle with a single thread frombeginning to completion. Many projects are more complex, so PartFour provides additional detail on the principles, techniques, andterms introduced here, such as the characteristics of unified, incre-mental, linear, evolutionary, and agile development, baseline man-agement, and the Waterfall, Spiral, and Vee models.

An appropriate project cyclecontributes significantly todoing the right project rightthe first time.

Essential 4

PMBOK ® GuideThis chapter is consistent withPMBOK ® Guide, Sec 2.1, TheProject Life Cycle

INCOSEThis chapter is consistent withINCOSE Handbook Sec 3Generic Life Cycle Stages.

cott_c07.qxd 6/30/05 3:52 PM Page 84

Figure 7.1 The project cycle format.

THE PROJECT CYCLE 85

We define the project cycle asan orderly sequence of inte-grated activities, performed inphases, leading to success.

Even though all projects travelthrough a sequence of phases,the road may not be clearlyunderstood.

DEFINING THE RIGHT ROAD TO SUCCESS

In our training and project management experience, we encounterthe following unfortunate situations; those teams that:

• Accept and follow a standard project cycle because it’s dictatedby their customers or management.

• Don’t define a project cycle, not having previously heard ofthe concept.

The former tolerate the concept because compliance is directed,and the latter resist it because it appears rigid and bureaucratic.Both are victims of a failure to appreciate the power of the projectcycle as a reliable road map for an enterprise and as a f lexible andeffective navigation tool to execute individual projects correctly thefirst time.

In the absence of a defined-management approach, and withoutthe defined milestones (decision gates) to ensure progress and base-line approval, project teams are left to create an ad hoc sequence ofevents believing they are navigating correctly.

Staying competitive often requires a short time to market.An institutionalized project cycle based on time-proven lessonslearned can be tailored up or down, but only if you first know thepreferred route.

This chapter presents a baseline template that can be applied toa wide range of development projects in all environments, whether

“We all want progress, but ifyou’re on the wrong road,progress means doing anabout-turn and walking backto the right road; in that case,the man who turns back soon-est is the most progressive.”

C. S. Lewis

cott_c07.qxd 6/30/05 3:52 PM Page 85


Eliminating a feature from aproven template must bejustified.

government, commercial, or nonprofit. This framework facilitatesthe sequential proactive management of projects that is:

• Orderly,• Methodical, and• Disciplined.

Since not all events and features in our template are universal inapplication, you should create your own version. To tailor a project-specific cycle, each entry must be evaluated, resulting in a consciousdecision to include it or not. This avoids errors of omission whiletaking advantage of proven baseline.

An effective way to build a tailored project cycle is to takethese four steps:

1. Decide on the appropriate periods or stages (Study, Implemen-tation, or Operations) for your project. The periods are relatedto the evolving system solution, which paces the project. Thedevelopment of the system is what is maturing and is a measureof progress.

2. Identify the decision gates and the associated phases withinthe periods that are required to ensure the best value systemdevelopment steps. There are always decision gates at the endof each phase; additional decision gates are often beneficialwithin a phase.

3. Define the products or artifacts (documents, models, test arti-cles, etc.) that must be in evidence and ready for baselining ateach decision gate to ensure that the project has delivered tothe objectives of the phase or subphase and is ready to move for-ward (exit and entry criteria).

4. Define the tasks required to create the products or artifacts.These tasks will provide the input for building the project net-work and schedule (discussed in Chapter 12).

Our baseline project-cycle template contained in this book is di-vided into three periods or stages: the Study Period, the Implemen-tation Period, and the Operations Period. These periods correspondto the major objectives of the system solution as it matures from anidentified user need through concept determination, implementa-tion, and ultimately to production and user operation. Figure 7.2 de-picts representative government and commercial periods and phasesalong with our project cycle template. The NASA cycle comes fromtwo references, one for the systems engineering cycle and the otherfor program or project management.1 The U.S. Department of De-fense cycle comes from a recent publication.2 The ISO/IEC cyclecomes from ISO-15288.3

Many disciplined companiesfollow some version of aproject cycle that is dividedinto periods and furthersubdivided into phases.

PMBOK ® GuideThe PMBOK ® Guide Sec 2.1.1Characteristics of the ProjectLife Cycle, provides relevantdiscussion.

cott_c07.qxd 6/30/05 3:52 PM Page 86


Figure 7.2 Project cycle templates.

In their book, Microsoft Secrets, Cusumano and Selby describethe Microsoft project cycle for new product development.4 The Mi-crosoft cycle, which typically lasts from 12 to 24 months, has threephases (Planning, Development, and Stabilization). Each of thephases has detailed activities, products, and decision gates. Thefinal decision gate, at the end of the stabilization phase, has a titlethat should delight Microsoft product users: “zero bug release.” Al-though their terms differ somewhat from those used in Figure 7.2,their description of the cycle maps exactly to our baseline model.

All cycles begin with a user needing something. Typically, cus-tomers determine the need and the user requirements and then con-tract with one or more providers (ultimately, the project team) todevelop the product or service. Customer types include governmentagencies, commercial enterprises, or a company’s internal marketingdepartment.

Even though projects can beinitiated very differently, theyare subject to similar projectmanagement and systemsengineering processesonce the requirements areestablished.

cott_c07.qxd 6/30/05 3:52 PM Page 87


Figure 7.3 Project cycle chart for amusement park exhibits and rides.

Brainstorming

Concept

Design

Implementation

System Verification

BeginExhibit/RideProduction

CompleteFacilityBuild-to

DrawingsBeginFacility

Construction

BeginExhibit/RideInstallation

BeginTest and

Fix

Begin OpsTraining

OpenExhibit/Ride toPublic

Feasible Concept- Complete Exhibit Lists and Ride Layout- Complete Cost, Schedule, and Technical Assessments

- Complete ConceptDevelopment

- Creative Buy-Off(Storyboards and

Sketches) for User Interface

Complete Design-to Documents- Design Details Established- Exhibit and Ride Design Requirements Complete

Candidatefor New

CustomerAttraction

KEY MILESTONES

CompleteSchematic

Design

State andLocal Agency

SafetyInspection

Development of Rides and Exhibits for an Amusement Park

Highly creative commercial organizations benefit from having adefined requirements-driven process. The development of newamusement park attractions usually begins with “blue sky” explo-rations and concludes with a new exhibit or ride (Figure 7.3). Manytheme park organizations, including Walt Disney Imagineering, fol-low a cycle like this.5 Note that this cycle closely matches theprocesses illustrated in Figure 7.2.

In government acquisitions and larger commercial projects,team members and managers may change with the project-cycle pe-riod. For example, in the case of a Department of Defense (DoD)project, once a mission need is identified, a project champion is se-lected and a core team is formed to develop the user requirementsand to produce the tender or bidder documents. That core team maychange during the implementation period, although some teammembers may stay to provide continuity throughout the three peri-ods. Bidders will generally form a proposal preparation team, thecore of which may also continue through all or part of the imple-mentation phases.

Large, decentralized corporations often follow the governmentpractice of having separate customer (e.g., product marketing) andprovider (e.g., product development) teams. In this case, the mar-keting team will prepare the user requirements for the product de-velopment team.

PMBOK ® GuideThe PMBOK ® Guide Sec 2.1.2Characteristics of ProjectPhases identifies “initial,”“intermediate,” and “final” asphases of a project.

INCOSEThe INCOSE Life Cycle Stagesidentifies stages as:

• Pre-concept exploratoryresearch.

• Concept.

• Development.

• Production.

• Utilization.

• Support.

• Retirement.

cott_c07.qxd 6/30/05 3:52 PM Page 88


The project periods oftenrepresent natural boundariesto team responsibilities andcomposition.

Large commercial suppliers of systems built up from their “stan-dard” components offer another example. The sales team signs a con-tract with defined requirements. The implementation team managesthe project after contract signing and procures, installs, and verifiesthe system. Their project cycle should ref lect the activities and prod-ucts for the required modifications, verification, and readiness tohand off to the operations team.

Smaller commercial projects are more likely to consist of a sin-gle project manager selected as soon as the scope and nature of theproject is established and who will serve throughout delivery. Evenin this case, the size and composition of the project team will likelychange as appropriate to the periods and phases.

THE STUDY PERIOD YIELDS A HIGHRETURN ON INVESTMENT

The Study Period typically determines the scope, feasibility, andfunding of a project (Figure 7.4), therefore, making or breaking can-didate projects. Yet, important cost estimation studies are often cir-cumvented in the rush to implementation. High-level governmentpanels, such as the Hearth commission and Packard commission,concluded that hasty Study Periods, resulting in f lawed or incom-plete requirements, are the major cause of project failure. Theirfindings continue to be reverified; the General Accounting Office(GAO) reported in 1999 that high-tech government projects con-tinue to fail for low-tech, often mundane, reasons. Typically theselow-tech reasons are f laws built in as a result of incomplete studiesas well as improper implementation of an otherwise sound projectmanagement process.

Flawed Study Period project estimation seems to be the rootcause of the predicted several billion dollar overrun for the twenty-first century construction of the Oakland-San Francisco Bay Bridge.The cost problem is so severe that a change in design concept isbeing considered even though construction is well underway. In ad-dition, the public is calling for an investigation of the study periodmanagers, CalTrans.

The Big Dig in Boston, with an overrun several times theoriginal estimate, is another example of f lawed project scope andcost determination in the Study Period and scope creep duringimplementation.

The project team generally must engage in considerable analysisand negotiation in order to develop the requirements. The project

A major cause of projectfailure is insufficient focus onproduct opportunities andinadequate attention toresolving development risksduring the study period.

cott_c07.qxd 6/30/05 3:52 PM Page 89


u

Figure 7.4 Typical expenditure profile: Committed versus spent.

100

80

60

40

20

0Study Implementation Operations Disposal

≈70%

≈85%

%Committed

% S

pent

(life

cyc

le)

≈40%

≈10%≈4%≈1%SCR PDR

100%

AR

% o

f Pro

ject

ed F

unds Total Expenditure

Profile

SCR = System Concept ReviewPDR = Preliminary Design ReviewAR = Acceptance Review

manager and systems engineer must work as a team to ensure thatthe technical requirements match the business case objectives.

A comprehensive analysis can often prevent the time lost andthe funds wasted on requirements-driven rework as illustrated inFigure 7.5. This figure is uncommon since most organizations do notcollect the necessary data to create this relationship. The chart au-thor, Werner Gruhl, worked in the comptroller ’s office at NASAHeadquarters and had access to actual project costs by category forboth the study and development periods. He also knew the develop-ment costs as estimated at the end of their study period, and heknew what the project requirements were at the start of the devel-opment effort. He was able to adjust for financial distortions causedby events beyond the control of the project team. For instance, themost expensive part of the Hubble Space Telescope Program wasnot the mirror or the spacecraft itself, but rather the three years ofenvironmentally controlled storage of the completed satellite fol-lowing the Challenger accident. Mr. Gruhl was able to compare theactual costs incurred for the work that was planned at the start ofthe development period to the estimated costs for that same effort.This resulted in the “Final Overrun as a Percent of the Commitment

cott_c07.qxd 6/30/05 3:52 PM Page 90


(Estimate) at the Start of Development.” The horizontal axis is theratio of the cost of the study period to the cost of the developmentperiod. He did this analysis for 26 space projects. The conclusion isthat greater investment in the study period will yield a more accu-rate estimate of the ultimate cost of development, enabling the proj-ect manager to manage the implementation period effectively.

As an example, if you estimate the development cost for yourproject to be $10 million, and if you have spent less than $1 millionon the study period, there is a high probability that you will have anoverrun in excess of 20 percent. After unacceptable project perfor-mance in the early 1990s, NASA implemented an executive require-ment that any project that is predicting greater than 15 percentdevelopment cost growth must appear at a Cancellation Review to“show cause” why the project should not be cancelled. Study periodinterest increased as a result.

Our baseline cycle template provides four phases within thestudy period: User Requirements Definition, Concept Definition,System Specification, and Acquisition Preparation. Systems engineer-ing has primary responsibility for the technical decisions during

Figure 7.5 Twenty-six NASA program files.

0

20

40

60

80

100

120

140

160

180

0 5 10 15 20 25

Study Period Cost as a Percentof Development Cost

Data points shown are for 25space programs including:• Hubble Space Telescope• TDRSS• Gamma Ray Obs 1978• Gamma Ray Obs 1982• SeaSat• Pioneer Venus• Voyager

Source: NASA HQ

Fin

al O

verr

un

(%

) to

Co

mm

itm

ent

atS

tart

of

Dev

elo

pm

ent

cott_c07.qxd 6/30/05 3:52 PM Page 91


these phases, but the project manager must ensure consistency withthe business case and with customer needs.

User Requirements Definition Phase

The major objective of the User Requirements Definition Phase isto determine exactly which of the user ’s many requirements will beincluded in, and satisfied by, the responsive project. In some cases,user requirements may be more comprehensive than can be reason-ably incorporated into a single project and those of lower priorityare rejected. Also included in this phase is the development ofstakeholder requirements that impose constraints on the solutiontrade space. This phase is essential in both government and com-mercial projects because it is key to correctly bounding the projectand avoiding over specification and grandiose expectations. It is alsoessential to establishing the feasibility of meeting the user ’s require-ments, because what may seem reasonable at the first communica-tion may be too challenging—or even impossible—to meet at asubsystem or component level.

Concept Definition Phase

The objectives of the Concept Definition Phase are to evaluate sys-tem concept alternatives, to select the best value concept and itsarchitecture, to develop the associated life-cycle budgetary should-cost estimate, the target should-take schedule, and finally, to iden-tify opportunities to pursue and risks to mitigate. During this phase,estimates of required funding are updated as the credibility of thebasis of the estimates is improved.

There is a pitfall, however. During this phase, aggressive sell-ing of a project concept is often necessary to secure the funding to move ahead to the implementation period, and in so doing unachievable expectations (both for cost and schedule) are oftenestablished. The Boston Big Dig, the Denver Airport, and the Oakland-San Francisco Bay Bridge projects take their place withcolossal projects of prior centuries, such as the Panama Canal. Allof these projects were (or will be) successfully completed, but withhuge cost and schedule growth—and with career-limiting impactto the succession of project managers who each advanced the proj-ect incrementally forward. The proactive defense against false ex-pectations is a comprehensive study period to size the projectcorrectly.

cott_c07.qxd 6/30/05 3:52 PM Page 92


A positive example is provided by the project team that man-aged the Øresund Bridge-Tunnel project (between Copenhagen,Denmark, and Malmö, Sweden, at the time the world’s longestbridge) from concept development through construction. Startingon a predicted decade-long effort in 1991, they spent three years inthe study period, and then finished the bridge early (July 2000) andwithin budget.6 In addition, they are currently meeting their trafficgrowth prediction, which is more than the English Channel Tunnelhas achieved. It can be done.

System Specification Definition Phase

The objective of the System Specification Definition Phase is toquantify the system and interface requirements for the selectedconcept and to perform technology opportunity investigations andrisk reduction actions in areas where technical feasibility is uncer-tain. Experimentation and modeling should ensure that all specifiedperformance is achievable and affordable. There can be substantialcost and schedule penalty if this is not done properly. One programconsisting of incremental delivery of satellites over a 15-year periodencountered significant problems in initial manufacturing. The firstsystem was years late and could only be delivered with a waiver ofspecification requirements. But as evidence of a nonachievablespecification, the last satellite in the series, due to launch in 2008,will also require the same waiver because it still will not be able tomeet the initial specifications.

Acquisition Preparation Phase

The final phase of the study period, the Acquisition PreparationPhase, is used to prepare for the implementation period. It includesdevelopment of the schedule and budget for acquiring or develop-ing the proposed system and ensures the availability of the fundingat the level of the most-probable cost for the project. This phasealso defines the method of acquisition, identification of partici-pants in the acquisition process, and identification of candidatesuppliers, which may include internal organizations. The final eventis to obtain approvals needed to proceed with the project. For inter-nal development projects, the final event in the study period is topresent the technically substantiated business opportunity to exec-utive management and secure their commitment.

cott_c07.qxd 6/30/05 3:52 PM Page 93


THE IMPLEMENTATION PERIOD IS FORACQUISITION OR DEVELOPMENT

The Implementation Period consists of three phases: Source Selec-tion, System Development, and Verification. In government projects,the implementation period may be referred to as the Acquisition Pe-riod. In this case, it sets the contractual foundation for procuring theproject and initiates the process of building the buyer-seller teamthat will work together through at least development.

Source Selection Phase

The objective of the Source Selection Phase is to choose, throughfair and open competition and through the comprehensive evalua-tion of contractor proposals, the “best value” bidder. For acquisitionprojects, the buyer releases the Request for Proposal, receives andevaluates bidders’ proposals, and negotiates a contract with the se-lected bidder. For internal developments, the implementation pe-riod may have one or more Source Selection Phases for individualincrements of the system. These phases often occur after the “de-sign to” specifications are available.

System Development Phase

In both external and internal developments, the objective of theSystem Development Phase is to design and build the first article ordevelop the service concept if the solution consists of services only.

Verification Phase

In the Verification Phase, the project team integrates and verifies(by inspection, test, demonstration, or analysis) the system or ser-vice in accordance with defining specifications. These activitiesprove that the solution has been built right. It is high risk to deploythe system without verification. However, this sometimes happenswhen executive management eagerly deploys a new system forreasons outside the project’s scope or beyond the control of theproject manager. Skipping verification is almost always far morecostly in time, money, and reputation than following the propersequence.

President Carter agreed to build a new embassy in Moscow, eventhough his security team said they could not verify the structurewould be secure. After five years, the six-story building was nearing

cott_c07.qxd 6/30/05 3:52 PM Page 94


completion when the project had to be stopped because listening de-vices were found to be cast into the concrete of the Russian-builtcolumns and beams. The building stood idle for almost a decade. Amodified version, built by U.S.-security-cleared workers, was com-pleted in 2001, 22 years after the project was initiated.

More recently, the Bush administration mandated deploymentof the $15 billion missile defense system without a single successfulsystem test. As widely reported in major U.S. news media, eventhough no f light tests had been conducted previously, 7 untestedmissiles were already in underground silos by the end of 2004 with12 more scheduled for 2005 deployment. “Pentagon officials defendwhat they call a ‘spiral development’ approach to the program, say-ing it’s designed to put a missile defense system into operationrapidly by simultaneously deploying, evaluating and upgrading com-ponents. ‘This is not a traditional development program, where op-erations begin only once testing is complete,’ Taylor said [ChrisTaylor is a spokesman for the Missile Defense Agency].”7 In thiscase, spiral development means uncontrolled management practicesthat bear very little resemblance to the Spiral Model discussed laterin this chapter.

THE OPERATIONS PERIOD IS FORFULFILLING USER NEEDS

The Operations Period proves that user needs are fulfilled throughrealizing the project solution. It consists of three phases—the first iscalled either Deployment or Production, depending on the main pur-pose, such as a system acquisition versus a commercial product to bemanufactured and marketed. The second phase is Operations andMaintenance or Sales and Support, again named to ref lect the pur-pose or emphasis. The third and last phase of the Operations Period isDeactivation for both government and commercial projects.

Deployment and Operations/Maintenance Phases

In government acquisition projects, the objectives of the Deploy-ment Phase are to transfer the system from the contractor ’s facilityto the operational location and to establish full operational capability.Operations and Maintenance consists of operating and maintainingthe system in conformance with user requirements and identifyingsystem improvements for future implementation.

There is technical logic for therecommended sequence ofstages and phases. Perceivedpolitical necessity cannotovercome engineering reality.Deploying a system before asuccessful system test is highrisk.

cott_c07.qxd 6/30/05 3:52 PM Page 95


Decision gates are used toreview and approve the base-line elaboration.

Production and Sales/Support Phases

In commercial projects, the objective of the Production Phase isto transfer to manufacturing operations, often accompanied by ahand off to a new project team dedicated to the production func-tion. Finally, the system is delivered to users in the marketplaceand the Sales and Support Phase begins. During this time, theproject team handles design changes justified by manufacturingor by market demands.

Deactivation Phase

The Deactivation Phase disposes of all elements of the project. Tofacilitate this requirement, many products are being built with therequirement that they be totally recyclable. Early planning for adeactivation phase is vital in certain projects. The NASA Skylabrandomly fell to earth in an uninhabited part of Australia. Piecesof a Russian satellite fell uncontrolled onto Canada. Love Canaland other super-fund sites are also examples of inadequate deacti-vation planning. (Super-fund refers to U.S. government money setaside for high-priority environmental clean up.) Deactivation anddisposal considerations should be a part of the concept selectioncriteria.

Recycling considerations, now mandated by some Europeancountries, have long been normal design and manufacturing prac-tice at BMW. Environmentally oriented thinking and practicesgeared toward closed-loop recycling are today as much a part of thecompany’s culture as “Sheer Driving Pleasure.” Integrating the Re-cycling and Dismantling Center into the automobile developmentprocess has resulted in car designs that consider the full product lifecycle—all the way to recycling. Starting in 2006, manufacturers inthe European Union retain lifetime responsibility for the environ-mentally sensitive materials in their products.

THE IMPORTANCE OF DECISION GATES

A decision gate (also referred to as a control gate or quality gate) is abaseline approval event in the project cycle, sufficiently importantto be defined and included in the schedule by executive manage-ment, the project manager, or the customer. Decision gates repre-sent major decision points in the project cycle. They ensure that newactivities are not pursued until the previously scheduled activities,

cott_c07.qxd 6/30/05 3:52 PM Page 96


Decision gates focus thecreativity where it is mostneeded.

Decision gates, althoughheavy in technical content, arebusiness reviews. They needto occur throughout the proj-ect phases to control all threeproject cycle aspects: busi-ness, budget, and technical.

PMBOK ® GuideThe PMBOK ® Guide Sec 2.1.2defines phase-end gates andnotes that they are also called“phase exits,” “phase gates,”or “kill points.”

The critical role of gates inapproving the elaboration ofthe baseline is not addressed.

Each decision gate’s definitionshould be included in the proj-ect’s terminology database.

on which the new ones depend, are satisfactorily completed andbaselined. The primary objectives of decision gates are to:

• Ensure that the elaboration of the business and technical base-lines are acceptable and will lead to satisfactory verification andvalidation.

• Ensure that the next phase team is prepared, and that the risk ofproceeding is acceptable.

• Continue to foster buyer and seller teamwork.

While many decision gate titles sound like design reviews andare often conducted as such, they are business reviews addressingthese questions:

• Does it still satisfy the business case?• Is it affordable?• Can it be delivered when needed?

Too often decision gates like Preliminary Design Review (PDR)and Critical Design Review (CDR) are conducted as technical re-views rather than combined technical and business reviews. Marketdemand, affordability, and realistic schedules are important deci-sion criteria leading to concept selections and should be updated andevaluated at every decision gate. Inadequate checks along the waycan set up subsequent failures—usually a major factor in cost over-runs and delays. At each decision gate, the decision options are:

Acceptable: Proceed with project;Acceptable with reservations: Proceed and respond to actionitems;Unacceptable: Do not proceed; repeat the review when ready; orUnsalvageable: Terminate the project.

Upon successful completion of a decision gate, the elaboratedbaseline, usually in the form of artifacts (documents, models, orother products of a project cycle phase), is put under configurationmanagement, requiring buyer and seller agreement to incorporatechanges. All future creativity must be based on the updated baseline.

Decision gate definitions should identify the:

• Purpose of the decision gate,• Host and chairperson,• Attendees,• Location,• Agenda and how the decision gate is to be conducted,

cott_c07.qxd 6/30/05 3:52 PM Page 97


• Evidence to be evaluated,• Actions, and• Closure method.

A broadly employed decision gate, the System RequirementsReview (SRR), should be held to confirm that a provider adequatelyunderstands the customer’s requirements. It usually occurs near thebeginning of the project cycle and involves the primary customerand the primary provider. Subequently, it occurs when any newprovider is added to the project, the primary provider then becom-ing the customer of the added provider.

The consequences of conducting a superficial review, omitting acritical discipline, or skipping a decision gate altogether are usuallylong-term and costly. The executives at a leading conglomerate liter-ally choked on their new product (a microwavable meal) when theyset out to investigate its market woes. When challenged to evaluatetheir own product, the executive group identified 28 product defi-ciencies that should have been caught during the project cycle, wellbefore product introduction to the marketplace. A few of the moresignificant f laws included: when positioning the open carton to readthe heating instructions, the contents spilled; the instructions,printed in black on a dark blue background, weren’t legible; thespecified microwave heating time was insufficient to heat the food,but when the time was increased adequately food material migratedinto the plastic container material.

Car design f laws and recalls provide many examples of thehazards of skipping decision gates or omitting critical skills, suchas human factors, in the baseline decision process. Such problemscan also result from inadequate concurrent engineering, a subjectaddressed in Chapter 9.

Even when appropriate decision gates are mandated, such as inbuilding construction, there is little chance of success if the partici-pants do not scrutinize the artifacts. A neighbor of one of the authorshad a custom-designed home built with an attached garage. He re-quested that one garage bay be designed extra wide and extra high toaccommodate his recreation vehicle. After the building was finishedaccording to the drawings and passed all inspections, his vehicle didnot fit. He found the architect’s error on the drawings, which he hadpersonally approved and signed 10 months earlier—a mistake costlyto him.

After completing a new post office building in a major U.S. cityat a cost of $140 million, the city engineers found that post officetrucks would not fit into the enclosed loading dock. Similarly, nor-mal food service trucks are too large to service Denver Airport’sconcourse restaurants.

Decision gate approval mustinvolve the necessary disci-plines and stakeholders andmust be based on hard evi-dence of compliance.

INCOSEINCOSE Handbook Sec 3.2covers decision gates asrelated to the developmentmaturity of the project or ser-vice.

cott_c07.qxd 6/30/05 3:52 PM Page 98


Study

Figuring out what to doImplementation

Doing itOperations

Using it

Collect userrequirements,userCONOPS, andselect systemrequirements

Ensurevalidation

Selectconcept;developsystemCONOPS

Provetechnicalfeasibility.Developspec

Identifycapablesuppliers

Selectcapablesupplier

Manage design-to, build-to. Buy, build, code.Ensure integration andverification

Providetechnicalsupport

Providetechnicalsupport

Technicalaspect

Is the customer smiling?What is the problem and the solution? How to do it and prove it?

Determineresourceavailabilityand source

Managevalue

Predictshould-costandphasing

Refineshould-costandphasing

Ensurephasedresourceavailability

Determinemostprobablecost

Manage budgets,funding, and value

Managevalue

Provideclosure

Budgetaspect

Can we afford to do it and is money available? Was it financially worth it?Are financials on plan?

Recognizeopportunity

Managedoers

Developbusinesscase

Provebusinessfeasibility

Selectacquisitionapproach

Select bestvaluesupplier

Manage suppliers.In-process ROIprojections

Improve;add value

EvaluateROI

Businessaspect

Is it worth doing? How to acquire? Are we glad we did it?Are we getting value?

PeriodPhase

User Require-ments

Deploy-ment

ConceptDefinition

SystemSpec

AcquisitionPrep

SourceSelection

Develop-ment Verification

Ops andMaint

Deactiva-tion

THREE ASPECTS OF THE PROJECT CYCLE:BUSINESS, BUDGET, AND TECHNICAL

The three aspects of the project cycle can be viewed as layers (Fig-ure 3.6 and Table 7.1). Each layer—business, budget, and techni-cal—contains its own logic set. The interwoven events for the threeaspects constitute the total cycle, which can also be considered asthe project opportunity cycle. The project cycle can span from userwants to project disposal or a reduced scope in accordance with theproject objectives.

The business aspect (Table 7.1) drives the project and is basedon the business case that justifies the pursuit of the opportunity.The business aspect contains the necessary business events relatedto customer management, justifying the project, business alliances,the overall business management events, and associated contractorand subcontractor management. Also included are the tasks neces-sary to solicit, select, and manage vendors. In the government proj-ect environment, the business case is usually called the mission case.The business aspect starts with seeking value-driven project opportu-nities to help achieve the strategic objectives of the enterprise.Trade-offs are made to select those projects suitable for the organiza-tion’s portfolio as justified by the business case. The business case an-alyzes the project’s fit within the organization’s business objectives,the investment required, the expected market and market share, the

Table 7.1 The three aspects of the project cycle

cott_c07.qxd 6/30/05 3:52 PM Page 99


profit expected, and the associated risks. It’s essential that the busi-ness case is accurate in predicting both the need and the demand forthe product or service and what customers will be willing to pay.Perhaps most important of all, the business case must be kept up todate as the business environment evolves.

To get approval to start a new project, the project champion mustcreate an attractive business proposition and then aggressively sell itto the stakeholders. In their eagerness to get approval to proceed withtheir project, some project champions exaggerate the return and min-imize the costs of development, so the seeds of failure are sownearly—and it is often a business constraint that forces creation of anunworkable technical solution, which is then driven to the point ofcollapse. That is what happened to NASA’s “faster, better, cheaper”approach in the 1990s. Early successes seemed to validate this busi-ness approach, but budget cuts were made for each successive projectuntil ultimately the “cheaper” attribute drove the design teams tocreate fragile technical solutions taking shortcuts to proven processesresulting in too many failures (NASA has abandoned “faster, better,cheaper” in favor of a more balanced and traditional approach).

History offers many examples of setting out on a f lawed base,driven by an aggressive business case. The French selected Ferdi-nand de Lesseps to head their Panama Canal effort because of hisSuez Canal experience. His experts recommended:8

• A sea-level canal (no locks), just like the Suez canal,• Reducing the time to complete the canal from 12 years to 8 years,• Reducing the projected cost from $240 million to $169 million,• Reducing the contingency in the cost estimates from 25 percent

to 10 percent, even though the cost estimate did NOT includepaying interest on the capital, the large cost for purchasing thePanamanian railroad, administrative costs during construction,and sums due the holder of the canal option in the selected area,

• While reducing the estimated cost, the reviewers increased theanticipated volume of excavation by 50 percent.

De Lesseps made one trip to Panama, spent a week touring theproposed route, and then returned to speak to potential investors. Inhis speech he further cut the predicted costs from the optimistic$169 million to $132 million (compared to the $240 million engineer-ing estimate). He also discounted the deadly climate as, “an inventionof adversaries” (ultimately over 20,000 died from malaria and yellowfever). The ultimate failed French effort cost about $287 million, thelargest expenditure on any single peaceful undertaking of any kind.9

The business case must beupdated to reflect changes inthe business environment thatcould significantly impact thejustification for the projectbeing in the portfolio or con-tinuing at all.

cott_c07.qxd 6/30/05 3:52 PM Page 100


The roots of the failure were that estimates were based on what theteam (De Lesseps) thought they could sell, not what it would actuallytake to do the job. This process is still alive and well. From mega proj-ects (i.e., space station, Boston Big Dig) to small ones, intentional un-derestimates to “get the job going” are common. In every such casethe initial project manager starts off with a severe handicap and is ona suicide run.

These disasters could have possibly been avoided by having eachproject-cycle decision gate reaffirm the business or mission case andcarefully adjust to the ever-present dynamics of the market. This isparticularly relevant and meaningful because most project teammembers do not know and cannot articulate their project’s businesscase nor the business case at their level of responsibility.

Sometimes financial challenges are created by external projectstakeholders and are outside project control. The agreement betweenthe governments of Sweden and Denmark established the rules gov-erning the Øresund bridge-tunnel construction and operation. “Theagreement stipulates that the Øresund Bridge and its operations mustbe financed by toll fees (the road section) and fees from the rail op-erators. However, it was subsequently decided that the operators arenow liable for Value-Added Tax (VAT) on revenue from the road traf-fic. As competing ferry routes do not pay VAT, the bridge operatorscannot compensate for VAT payments by increasing charges on pri-vate vehicles. This has led to lower-than-expected income.”10

The original budgets and schedules for the bridge and tunnelwere met, but the change in revenue rules forced a longer bond re-payment schedule.

The business aspect of the project cycle also ref lects the ap-proach to acquisition and fielding, including competitive source se-lections, if required. During the acquisition period, the focus is onsupplier management and on the trading of features and benefits inthe marketplace as designers and producers seek to enhance theproject’s concept. Then as production and fielding begin, theactivity shifts to customer service and increasing value by continu-ous improvement in both service and product performance. Incre-mental or version upgrades are the generally accepted way ofimplementing this approach. In software, this is done with timelyenhancements and automatic downloads that keep users at thestate of the art.

The budget aspect of the project cycle depicts the activities andevents necessary to secure funding and to fuel the project through-out its project cycle. The executive’s challenge is to prioritize theprojects (by business case) and then to allocate available funds

cott_c07.qxd 6/30/05 3:52 PM Page 101


among the proposed and active projects. The project manager ’schallenge is to secure the necessary funds for the project at handand to properly manage them.

Government and commercial organizations usually have to op-erate within a total budget, typically established on an annualcycle. New project initiatives have to compete with ongoing proj-ects for a share of the total budget. This reality may present diffi-cult timing constraints, especially with increasingly narrow marketwindows.

The budget aspect for government projects is complex, involvingboth the executive and legislative branches. In the past, projectswere often approved without knowledge of or preparation for theoperating costs that often loomed as the most significant. Now life-cycle costs are included when estimating project cost.

The budget activities and business management activitiesare combined with the technical aspect (Table 7.1) to yield thecomplete project cycle. The technical events of development proj-ects are usually the most significant force driving project lengthand development cost, and they’re often the most difficult tomanage. For these reasons, we will treat the technical aspect inmore detail than the other two aspects. However, this does notmean that the business and budget aspects should be discounted. If the project is to succeed on both financial and technical crite-ria (the only true definition of success), all three aspects of theproject must be skillfully balanced using ultimate project value asthe driver.

SYSTEMS ENGINEERING IS VITALLY IMPORTANTTO THE TECHNICAL ASPECT

The technical aspect starts with user needs, which are developedinto system functional and performance requirements by adjusting,adding, and eliminating requirements to yield a set that has thepromise of being satisfied while providing sufficient value to besupported. Concept trades are then performed to determine thebest value concept to satisfy the system requirements. The SystemConcept Baseline is decomposed into the entities of the system andthe concepts and specifications for each entity. The resulting de-composition represents the system architecture. This process andthe resultant artifacts define the concepts for all the entities downto the lowest-configuration item (LCI) from the systems engineer ’s

The technical aspect usuallydrives the project’s length andcost.

Systems engineering is doingthe right thing right, the firsttime.

INCOSEThe relevant section of theINCOSE Handbook is Sec 1.2The Purpose and Scope ofSystems Engineering.

cott_c07.qxd 6/30/05 3:52 PM Page 102


viewpoint. The technical artifacts should also define the approachfor system integration and for the verification and validation at eachlevel of integration, including that the final result satisfies the ulti-mate customer and users. That is the essence of the systems engi-neering process.

Systems engineering’s role is sometimes confused with that ofdesign engineering. Systems engineering does not create the design;rather, it creates the requirements, concepts, and architecture thatare documented in baseline specifications and other artifacts. Start-ing with the User Requirements Document, systems engineering isresponsible for conducting the analysis and trade studies that lead tothe concepts and their specifications.

One of the most important responsibilities of systems engineer-ing is the overall system architecture. As Rechtin and Maier noted,“Clearly, if a system is to succeed, it must satisfy a useful purpose atan affordable cost for an acceptable period of time. . . . But of thethree criteria, satisfying a useful purpose is predominant. Without itbeing satisfied, all others are irrelevant. Architecting therefore be-gins with, and is responsible for maintaining, the integrity of thesystem’s purpose.”11 Stevens et al. said, “Architectural design de-fines clearly what is to be built. This is potentially the most creativepart of the system process, and the point at which the cost of thesystem is largely fixed.”12

Examples of systems engineering failures illustrate the distinc-tion. In the initial B-1 bomber, the advanced electronic and counter-attack systems interfered with each other—the plane’s own electroniccountermeasures for jamming enemy systems jammed its own B-1targeting electronics—yet the design engineers met the individualspecifications for each system. On the Blackhawk helicopter, the “f ly-by-wire” system failed when exposed to radio broadcast at shortrange—a test f light crashed when f lying over a radio station. On thecommercial front (waterfront, that is), a shipping container from aBritish exporter was fully loaded with hair dryers for sale in theUnited States. The dryers were built only for 50-cycle, 220-volt power.The exporter did not know that the U.S. commercial home productsoperate on 60-cycle, 110-volt power.

The systems engineering manager should direct the overall pro-cess toward achieving the optimum technical solution, including:

• Systems engineering planning,• Requirements development and management,

Systems engineering defineswhat is to be done technically;functional engineering decideshow to do it.

cott_c07.qxd 6/30/05 3:52 PM Page 103


• Requirements analysis and audit,• Concept and architecture development,• Performance management,• Baseline management,• Design audits,• Interface control,• Opportunity and risk management, and• Verification and validation management.

The systems engineering process progressively f lows down fromsystem and entity concepts and requirements to the lowest level ofdecomposition (e.g., hardware and software units), usually the low-est configuration item or lowest replaceable unit (LRU). Each levelof decomposition represents one or more entities or configurationitems (CIs) that make up the system at that level. A CI typically re-quires its own:

• Specification (functions, performance, interfaces, design con-straints, quality attributes),

• Design reviews,• Qualification testing and certification,• Acceptance reviews, and• Operator and maintenance manuals.

A CI should be selected to facilitate management accountabilityand replacement capability. For example, a car and a car batteryare both CIs to the consumer, because they can be readily acquiredand replaced. However the battery’s individual cells are not aCI, because they cannot readily be purchased and replaced by theconsumer.

MODELING THE TECHNICAL ASPECT

This section summarizes several historical and current models usedto represent the technical aspect. While these models enhance thevisualization process and provide insight into specific characteris-tics of the product development cycle, they all have important omis-sions. Part of the problem is that there is no widely understood oruniversally accepted model for managing the technical aspect ofprojects. While a variety of models are available, some err in the se-quencing of project events while others focus on entity developmentand ignore the management of architecture complexity.

There is no universallyaccepted approach to manag-ing the technical aspect ofprojects.

cott_c07.qxd 6/30/05 3:52 PM Page 104


Figure 7.6 This circular model has several flaws.

This continuouslypresent situationalactivity is incorrectlyshown as a sequentialevent.

ConceptDevelopmentshould occurimmediatelyafter #1.

These continuousprocesses areincorrectly shownas sequentialevents.

ImplementationPlanning shouldoccur early in thecycle and SystemIntegration occursat the end.

We often hear strong preferences voiced for one model to theexclusion of all others. This is dangerous. It is important to take ad-vantage of the wide array of management models by understandingtheir strengths and limitations and then applying them appropri-ately. For example, some models are useful primarily for visualiza-tion and comprehension while others are better suited for day-to-daymanagement. Our critique has two purposes:

1. To use the strengths and contributions of each model to enhanceunderstanding and the visualization process.

2. To become aware and learn from the important omissions inpopular portrayals of the project management and systems engi-neering processes.

The circular model in Figure 7.6 was previously used by a lead-ing government agency to manage complex technical projects. Thismodel’s visible f laws, noted in the diagram, are highly instructive.In this and other linear, sequential models, continuously present sit-uational activities, such as risk analysis and management and config-uration management, are incorrectly depicted as sequential eventsrather than continuously applied processes.

Some early models, such as DoD STD 2167A, depict hardware-related events as independent from software-related events (Figure7.7). The message that these two vital development paths can andshould be managed separately until final system integration resultedin hardware-software incompatibility for many projects. This model

Most approaches fail to differ-entiate among ongoingprocesses and sequential andsituational events.

cott_c07.qxd 6/30/05 3:52 PM Page 105


Figure 7.7 Hardware- and software-related events are erroneously separated.

CSCITesting

CSCIntegrationand Testing

Coding andCSU Testing

DetailedDesign

SystemRequirements

Analysis

SystemDesignSRR SDR SSR

PDR CDR

PDR CDR

TRR

SystemIntegrationand Testing

FCA

Testing andEvaluation

PCA

FCA PCA

FQR Production andDeployment

Hardware (HWCI) Development

AllocatedBaseline

FunctionalBaseline

Software (CSCI) Development

Development Configuration

† †

System Requirements Review

System Design Review

Software Specification Review

Preliminary Design Review

Critical Design Review

Test Readiness Review

Functional Configuration Audit

Physical Configuration Audit

Formal Qualification Review

SRR –

SDR –

SSR –

PDR –

CDR –

TRR –

FCA –

PCA –

FQR –

† – May be multiple reviews andmay be integrated withhardware reviews

ProductBaseline

SoftwareRequirements

Analysis PreliminaryDesign

HWCITesting

FabricationDetailedDesign

PreliminaryDesignHardware

RequirementsAnalysis

System RequirementsAnalysis/Design

was in use for several decades, but was abandoned in the mid-1990swhen the Department of Defense directed its staff and contractorsto apply commercial standards for software development.

The 2167A model (Figure 7.7) and the Waterfall Model (Fig-ure 7.8) require that work downstream should not begin until up-stream uncertainties are resolved and major reviews (decisiongates) have been satisfied. The Waterfall, developed by Dr. Win-ston W. Royce, is so named because software development is de-picted as f lowing from the top to the bottom in discrete,sequential, linear phases.13 The model represents the software de-velopment cycle as a series of steps progressing diagonally fromupper left to lower right. In complex, high-risk projects, this is in-appropriate. Rona Stillman, a computer scientist at the U.S. Gen-eral Accounting Office, maintains that, “The waterfall model isrisk-averse. It encourages unrealistic cost and schedule estimatesand the appearance of problem-free development.” There is oftena need to initiate software design and coding, as well as hardwaremodeling, earlier in the development cycle to ensure that the re-quirements are properly understood and to prove technical feasi-bility. For these reasons, many organizations do not embrace theseand similar technical development models.

cott_c07.qxd 6/30/05 3:52 PM Page 106


Figure 7.8 The Waterfall Model.

System Requirements

Software Requirements

Preliminary Design

DetailedDesign

Code andDebug

Test andPre-operations

Operations and MaintenanceRoyce (1969)

• Sequential phases that may overlap• Promotes orderly development

– Requirements before design

– Design before coding

• Emphasizesrequirements flowdown

• Allows upward / backwarditeration to change baseline

– Sometimes called rework

– Horizontal dimension is not time since backward iteration is allowed

The Spiral Model (Figure 7.9) is an excellent risk-driven modelthat attempts to address the shortcomings of the Waterfall. Thismodel was developed by Dr. Barry W. Boehm to resolve the Water-fall deficiencies.14 Dr. Boehm addresses the need for early require-ments understanding and feasibility modeling including operationalscenario modeling. Many software organizations use the Spiral astheir development method and model. Microsoft, for instance, uses aprocess that is, “. . . similar to the risk-driven, incremental ‘spiral’life cycle model.”15 The Spiral is another view of the technical aspectof the project cycle that emphasizes early risk analysis and software“prototyping.” While it does achieve the objective of early risk miti-gation, the spiral representation can be confusing. The circular timerepresentation is inconsistent with traditional left-to-right time rep-resentations and risk management is portrayed as a sequence of ser-ial analyses (in the upper left quadrant) preceding and delayinglow-risk product development rather than offering the option of per-forming risk management as an ongoing, parallel part of the develop-ment process. In addition, all risk management is shown to ceaseonce the concept represented by the operational prototype is avail-able, giving the impression that the required detail design, coding,

The Waterfall Model replacedhacking with a repeatable,phased software-developmentprocess.

cott_c07.qxd 6/30/05 3:52 PM Page 107


Figure 7.9 The Spiral Model.

and testing will be risk free as in the Royce Waterfall representation.This is rarely the case. To draw on the Spiral’s strengths for riskmanagement, we return to it in Chapter 13.

VEE MODELS: TOOLS FOR VISUALIZING ANDMANAGING TECHNICAL DEVELOPMENT

Project cycles progress from left to right in a series of phases usuallydepicted horizontally consistent with the conventional time axis.However, some models have altered the depiction to emphasize se-lected attributes. In the Waterfall, the series of phases descendfrom the upper left down to the lower right. Emphasis here is on thef lowdown of requirements as the system detail is elaborated. TheSpiral Model’s phases are shown wrapped around a center point inthe form of a spiral; emphasis is on repetitive modeling (each revo-

Why the Vee Is a V

The V form most accuratelyrepresents system evolutionfrom the perspective of systemdecomposition and integrationactivities.

The Vee models are valuabletools for visualizing and man-aging the systems engineeringprocess.

cott_c07.qxd 6/30/05 3:52 PM Page 108


Figure 7.10 Architecture Vee Model.

SystemDevelopment

SystemDevelopment

SubsystemRealizationSubsystemRealization

Solution/SystemRealization

Solution/SystemRealization

SubsystemDevelopment Subsystem

Development

Integration, Verification, & Validation Planning

Integration, Verification, & Validation Planning

I, V, and V Planning

Architecture Vee

LCILowest

Configuration Item Realization

LCILowest

Configuration Item Realization

LCILowest

Configuration Item Development

LCILowest

Configuration Item Development Ar

chite

ctur

e In

tegr

atio

n

& V

erifi

catio

nArchitecture D

ecomposition

& Definition

lution) to address known risk. The final wrap of the spiral, however,contains Royce’s Waterfall.

As depicted by the Waterfall, system decomposition extendsfrom the needs of a user or customer down through concept devel-opment and subsystems to low-level entities. In reality, the entitiesare then built and integrated with others up through system realiza-tion. The resulting Vee form (Figure 7.10) most accurately repre-sents system evolution from the perspective of decomposition andintegration activities.

There can by any number of levels in the decomposition. Asa reference, the INCOSE Handbook defines seven decompositionlevels (system down to part). For simplicity, the basic ArchitectureVee is illustrated with three levels, refering to the lowest level as theLCI from the architectural perspective of the systems engineer.

At each decomposition level, there is a direct correlation betweenactivities on the left and right sides of the Vee. This is deliberate. For

INCOSEThe INCOSE Handbookdefines these sevendecomposition levels:

1. System.

2. Segment.

3. Element.

4. Subsystem.

5. Assembly.

6. Subassembly.

7. Part.

cott_c07.qxd 6/30/05 3:52 PM Page 109


example, the method of verification to be used on the right must bedetermined on the left—at the time requirements are first defined—for each set of requirements developed at each level. This minimizesthe chances that requirements are specified in a way that cannot bemeasured or verified.

System Decomposition and Definition

Decomposition: The hierarchical, functional, and physical parti-tioning of any system into hardware assemblies, software compo-nents, and operator activities that can be scheduled, budgeted,and assigned to a responsible manager.Definition: The design to, build to, and code to artifacts that de-fine the functional and physical content of every entity.

The increasing thickness of the Vee (orthogonal to the paper)is symbolic of the number of entities at each decomposition level,which relates to system complexity. Referring to Figure 7.11, theconcept of the evolving baselines, progressively increasing in ar-chitecture depth and under change control, is represented bythe Vee core. The left leg of the Vee represents system decomposi-tion and definition and the right leg represents integration andverification.

Our Vee model supports the real-world need for exploratorytechnical investigation early in the cycle to pursue opportunities andreduce risk. For example, we encourage early hardware and softwarerequirements-understanding models and technical feasibility mod-els. This helps clarify user requirements and ensures that customerrequirements are achievable. Early participation of domain expertsis essential to the credibility of this process. Upward iteration withthe user is often needed to get buy-in to the opportunities and tomanage the risks in the continuous process of user requirementsclarification. The details of these “off-core” studies are explored ingreater depth in Chapter 13.

Time and project maturity f low from left to right on the Vee;therefore, once a decision gate is passed, backward iteration is notpossible. However, vertical iteration is encouraged all the way upto the user and user requirements and down to the lowest-levelhardware component or software unit (along the “time now” verti-cal line). This is the typical activity at every “time now” point pro-gressing along the core of the Vee. Changes in user requirements

Business case and budget allo-cations flow down with thetechnical requirements andconstraints. When properlyallocated, each entity receivesa business case and a budget.Hence, all three aspects of theproject cycle take a Vee formto faithfully represent the solu-tion development path.

cott_c07.qxd 6/30/05 3:52 PM Page 110


introduced after the PDR will impact baselined concepts and theirdesign-to specifications and may best be held for later versions orreleases. If substantive changes to user requirements must be madesubsequent to the PDR, then the project should be reset to the po-sition, within the Vee, of the requirement impact. The repeat ofmuch of the development sequence may be faster because of previ-ous experience and lessons learned, but all affected phases and de-cision gates must be repeated in view of the major change inrequirements.

As the project progresses, requirements f lowdown analysesand opportunity and risk investigations continue. This is shown inFigure 7.11 by the vertical off-core activities that descend to the

Figure 7.11 Vee Model: Decomposition and definition.

cott_c07.qxd 6/30/05 3:52 PM Page 111


decomposition level necessary to evaluate available opportunitiesor to satisfy concerns. For instance, if there is a question about newmaterial or piece part technology, the downward off-core activitywill descend to the material or part level where modeling canprove that incorporation will be beneficial.

While technical feasibility decisions are based on these off-core activities, only the decisions at the core of the Vee are putunder configuration management (change control). Off-core analy-ses, studies, and modeling are performed to substantiate the coredecisions. The studies ensure that opportunities have been as-sessed and are being managed and that risks have been mitigatedor determined to be acceptable. The laboratory or model shop off-core analysis may not require rigorous controls and will usually berepeated at the appropriate decomposition level to justify baselin-ing the result.

The Vee development approach is consistent with—and sup-ports—the current best practices in iterative evolutionary softwaredevelopment. If iterations are expected to be part of development,the architecture must be robust and f lexible enough to adapt to theevolving requirements. As Craig Larman states:

The Unified Process (and most new methods) encourage a combina-tion of risk-driven and client-driven iterative planning. This meansthat the goals of the early iterations are chosen to pursue the oppor-tunity of a solution by: (1) identifying and driving down the highestrisks, and (2) building visible features that the client cares mostabout. Risk-driven iterative development includes more specificallythe practice of architecture-centric iterative development, meaningthat early iterations focus on building, testing, and stabilizing thecore architecture. Why? Because not having a solid architecture is acommon high risk.16

The project development process is dynamic. Throughout theproject cycle there is iteration at all levels, studying user needs, inves-tigating alternate concepts, performing analyses, building models, andconducting evaluations. The Vee model establishes order out of whatmight emerge as a chaotic process. The baselines on the core are theanchor for the “time now” iterations, but these baselines can be re-vised through the change management process. The upward iterationsaddress the evolution of user requirements, while downward itera-tions evolve improved solutions. This iterative, evolutionary process

cott_c07.qxd 6/30/05 3:52 PM Page 112


can continue for as long as the project team desires, constrained onlyby the user ’s schedule, the customer’s budget, and the project’s ulti-mate objectives.

Beware, however, of system-level changes made late in the de-velopment process. Such changes carry a high risk that the conse-quences will not be completely identified and implemented. Thecause of the Apollo 13 disaster was traced to a late change.17 It tooka sequence of five events to trigger the disaster, but the root causewas an increase in the spacecraft bus voltage incorporated after thePDR. All hardware was modified to accommodate the voltage in-crease except for one part that was eventually overstressed by thehigher voltage and sparked the explosion that almost caused the fatalfailure of the mission.

During the development of the Space Shuttle, a series of droptests were performed to verify the landing characteristics of the or-biter. A full-scale engineering model (named the Enterprise), withpilots on board, was carried on the back of a Boeing 747 to a high al-titude and released to glide back to the Dryden Flight Test Facilityand verify landing behavior. Because this vehicle would not go toorbit, and hence did not have the high-temperature reentry, sheetsof styrofoam were machined and bonded to the external surfaces tosimulate the tile contours. The styrofoam was painted green to sim-ulate the color of the insulation tile coating being used at that time.During the year it took to prepare the orbiter engineering model,work continued on the tile project to develop a better coating. A newblack coating passed a series of verification and qualification tests,and, because it was superior in most respects to the green coating,the black coating was adopted as the updated baseline. A few daysbefore the f light test of the full-scale orbiter model was to begin, anexecutive on the shuttle project decided that even though the colorof the vehicle had nothing to do with the landing tests, it would bebetter for publicity if the orbiter was painted black on the bottom.18

The RF signals to transmit the test data should be unaffected by thevehicle color. So the vehicle was repainted. This change, being con-sidered so trivial, did not go through the change control process.During checkout just before the test was to start, it was found thatno signals could be transmitted or received. The black paint thatcovered the antennae contained lampblack, which was opaque toRF. Thus, RF opaque lampblack covered the antennae. Consider-able rework was required before the tests could start. No change is asmall change.

cott_c07.qxd 6/30/05 3:52 PM Page 113


As a design matures, concept and design iterations must de-crease and ultimately stop. When design solutions are under config-uration management, engineers and designers can often see furtherpotential improvement. Just remember the post-PDR decision gatemotto: “Better is the enemy of good enough.” Late changes triggercontinually changing requirements to other areas, usually withbroad and expensive impact to the system.

Agile software developers have adopted the motto, “Embracechange,” and have designed their development processes to accom-modate frequent changes. However, there should be limits. If theteam is developing network software for a cellular wireless system,and after PDR the customer decides that the system should be basedon satellite communication, the impact to project cost and schedulewill be substantial. There is another post-PDR rule: “Meeting cus-tomer requirements and walking on water are equally easy—whenboth are frozen.”

System Integration and Verification

System Integration and Verification ascend the right side of the Vee.

Integration: The successive combining and testing of systemhardware assemblies, software components, and operator tasksto progressively prove the performance and compatibility of allentities of the system.Verification: Proof of compliance with specifications.Validation: Proof of user satisfaction.

The method of verification to be used at each level on the rightVee leg must be determined as the specifications are developed atthe corresponding decomposition level on the left Vee leg.

The critical aspects of the integration and verification processare indicated in Figure 7.12. Note the overt distinction on the rightleg of the Vee between verification and validation. Verification isthe process of proving that each entity meets its specifications. Val-idation is the process of demonstrating (as opposed to proving) thatthe users are satisfied, regardless of the specified performance.

As the integration and verification processes ascend the rightVee leg, anomalies encountered should involve systems engineeringin anomaly identification, assessment, and resolution. Issues that can-not be resolved but can be tolerated may require a waiver or devia-tion from the customer in conjunction with a modified as-verified

Validation is about buildingthe right thing.

Verification is about building itright.

A complex verification processmay overdrive cost and sched-ule and be the determiningfactor when considering alter-native decomposition andintegration concepts.

cott_c07.qxd 6/30/05 3:52 PM Page 114


Figure 7.12 Vee Model: Integration and verification.

baseline. In some environments, a deviation (to a specification) isgranted before the fact (the requirement does not need to be met),while a waiver is granted after the fact (the entity is built and failsverification). In many organizations, the terms are used interchange-ably, just as concrete and cement are used (incorrectly) as synonymsin common usage.

Applying the Vee to Business and Budget Aspects

If the technical aspect naturally tracks the Vee form, what aboutthe business and budget aspects? Do they also form a Vee or someother shape?

In the management of many projects, the business and budgetaspects do not track the Vee shape of the technical aspect. But they

cott_c07.qxd 6/30/05 3:52 PM Page 115


Evolutionary developmentprovides for investigation andexperimentation to develop acapability. Delivery is usuallyin entity versions each deliver-ing improved performance.Individual increments can bedeveloped using the evolu-tionary approach.

should. For comprehensive project management, all tasks for all sys-tem entities should have individual business cases and commensu-rate budgets. For this to occur, the business case and budgetallocations must f low down with the technical requirements andconstraints. When properly allocated, the lowest configuration itemmanager will receive a business case and a budget. Hence, all threeaspects of the project cycle take a Vee form to correctly representthe system development path.

TECHNICAL DEVELOPMENT TACTICS

The strategic goals of a project will drive the development tactics. Asingle instance of the basic Vee Model represents the most straight-forward tactical approach: a unified, linear development with a sin-gle delivery. If a project goal is to upgrade the system over timewith newly developed improvements, then a system architecturewith increments configured for easy upgrading and fielding is thebest tactical method. This alternative to a unified method deliber-ately decomposes the concept into modular entities to be developedincrementally, that is, separately for later integration as is done inthe auto industry. If a goal is to migrate technology into the systemover time, then an evolutionary development method may be appro-priate. The concepts of incremental and evolutionary developmentare only summarized here. Chapter 19 addresses technical develop-ment tactics in more depth.

If some user requirements are too vague to permit final specifi-cation at the design-to decision gate (PDR) or if the developmentprocess itself uncovers unforeseen needs and system applications, atactic is to proceed with a combination of straightforward (linear)development and evolutionary releases, typical of commercial soft-ware development. We illustrate this combination in a productstructure with four increments: A, B, C, and D. Figure 7.13 depictsa combination of development tactics selected to meet specificstrategic objectives: The evolving product breakdown structure isshown in the margin.

Development and delivery decisions are usually driven by thebusiness case in response to the demands of the market or the cus-tomer. While the project manager should be well versed in thebusiness case, the systems engineer usually has the best apprecia-tion for the f lexibility of the project to accommodate and benefitfrom the various tactical development and delivery methods dis-

INCOSEINCOSE Handbook Sec 3.4identifies life cycle develop-ment approaches such as:

• Single Thread Development.

• Incremental Development.

• Evolutionary Development.

cott_c07.qxd 6/30/05 3:52 PM Page 116

117

Figure 7.13a Solution initiation.

D

B

C

Time and Maturity

Later, B and D start at the same time, while C is further delayed

Increment A starts first

Time Now

A

The solution architecture consists of four increments: A, B, C, and D

D1 D2

ALinear

Increments A, B, and C are straight-forward linear developments requiring no experimentation or version iterations

C

Evolutionary

Time and Maturity

Time Now

Increment A is completed, providing Initial Operational Capability (IOC)

Linear development continues on increments B and C,which will be combined later.

The requirements for subsystem D are ill-defined and an evolutionary approach is adopted. Two iterations have been pursued at this point.

A

B

A

A

B C

D(BC)

Product Breakdown Structure

Figure 7.13b Increment A completed, providing initial operating capacity.

cott_c07.qxd 6/30/05 3:52 PM Page 117

118

D1 D2 D3 D4

Increment A is combined with BC to expand functionality of the initial system

Increments B and C are integrated to form subsystem BC

Time and Maturity

A ALinear

BBC

Linear

LinearC

Evolutionary

Time Now

A(BC)

Evolutionary development continues to produce successive versions D1through D3

Time Now

D1 D2 D3

Time and Maturity

A ALinear

BBC

Linear

LinearC

Evolutionary

A(BC)

D4

A(BC)D4

IncrementsA, BC, & D are integrated into the ultimate solution ABCD4

A(BC)

A

B C

D(BC)


A(BC)D4

A

B C

D4(BC)


Figure 7.13c Solution subsystems A, B, and C complete.

Figure 7.13d All increments are integrated to form the enhanced system.

cott_c07.qxd 6/30/05 3:52 PM Page 118


cussed here. To arrive at the best decision for the sake of the mar-ket and the project, the project manager and the systems engineershould collaborate until consensus is reached. Then, the decisionshould be baselined and broadcast to the project team so that thetactics can be built into the tailored project cycle and all subse-quent planning.

TECHNOLOGY INSERTION

Projects are sometimes initiated with known technology shortfallsor anticipate an emerging technology. Technology development canbe done in parallel with the project evolution, shown in Figure 7.14,

Figure 7.14 Technology insertion.

PDR

Fabrication

Code and Unit Test

Manage as Critical Issues

New Technology Development

Hardware

Software

New technologymay “create” userrequirements

Use

r

Req

uirem

ents

Sta

tem

ent

cott_c07.qxd 6/30/05 3:52 PM Page 119


and inserted as late as the design-to decision gate when the perfor-mance of the new technology must be specified and guaranteed. Inthe example, the required technology development is representedby a horizontal bar shown off-core at the level where it will impactthe project if expected performance is not available. Technologydevelopment should be managed and statused by the project man-ager and systems engineer as an opportunity critical to the successof the project.

BASELINE MANAGEMENT

Baselines contain all the business, technical, cost, schedule, and de-liverable requirements that are sufficiently mature to be acceptedand placed under change control, usually at decision gates or phasetransition reviews. The project team then relies on these baselines asthe approved state of the project for further elaboration. Projectsshould be managed to a coordinated business or mission baseline(contract, schedules), budget baseline (should cost, most probablecost), and technical baseline (requirements, concepts, specifica-tions, verification plans, etc.).

Baseline management is accomplished by configuration manage-ment including a formal change control regimen that, for each typeof artifact, establishes:

• The event that places that artifact under change control,• The method for considering change, and• The required change approval, usually involving both a buyer

and a seller.

The overall objective of baseline and change managementis to establish a reliable knowledge reference for the project businessand design maturity. This is necessary for accurate communicationsamong supporting business, technical, training, sparing, replication,and repair personnel. The change control process, addressed inChapter 14, is usually initiated by the first official artifact of theproject, which in many cases is the contract (for internal projectsthe contract may be a memorandum from management). This firstartifact is usually business based and provides the overall objectivesand business (or mission) case for the project. It is especially important that this artifact be managed so that any changes to the business or mission case are properly accounted for and re-

Effective BaselineManagement depends oneffective change management.

cott_c07.qxd 6/30/05 3:52 PM Page 120


sponded to. Too often, projects drift from their initial, undocu-mented objectives, no longer ref lecting what was originally or evencurrently intended.

It is common over the life of a project for the sponsor to change,bringing new personalities and requirements to the project. Thesenew requirements should receive disciplined change management sothat they are properly interpreted and accommodated with com-mensurate changes in budget and schedule constraints.

The technical baseline is often initiated by the User Require-ments Document—usually the first technical artifact to be placedunder formal configuration management. As the project cycle pro-gresses, systems engineering together with the contributing engi-neering disciplines produce a series of technical baselines consistentwith the maturation of the solution and the phases of the project.Examples of technical baselines are:

User Requirements As-Replicated (Production Release)System Requirements As-BuiltConcept Definition As-TestedSystem Specification As-Deployed“Design-to” As-Operated“Build-to” (Pilot Production)

Changes to the business, budget, or technical baselines requirejoint action (review and approval) by the customer and the provider.In the case of commercial projects, the customer is often repre-sented by the marketing manager or general manager. In this case,the business baseline is established by the initial agreement betweenexecutive management and marketing as to the project scope, fund-ing, and schedule.

For contractual work authorized by an external customer,the provider ’s business baseline is usually a contract. Business base-line changes require contract action, and for large federal governmentcontracts funding changes may even require congressional action.

Systems engineering should work closely with the business man-ager (both customer and provider) so that the technical require-ments are congruent with business and budget baseline provisions.When there is a reduction of funds, systems engineering and theproject manager have to ensure there is a commensurate reductionin technical scope and work content.

Baseline management is discussed in more depth in Chapter 14.

cott_c07.qxd 6/30/05 3:52 PM Page 121


Figure 7.15 A technical project cycle tailored for developing a toothbrush.

PMBOK ® GuideBoth the PMBOK ® Guide andthe INCOSE Handbook cite theneed to tailor generic cycles tothe specifics of the project.INCOSE Handbook Sec 8describes tailoring of thecycle.

TAILORING THE PROJECT CYCLE

A project for hosting the Olympics is unlikely to perform well if it isfollowing the technical project cycle tailored for developing a tooth-brush as illustrated in Figure 7.15.

Each project, or at least each project type, needs a project cycletailored to the strategic objectives and the tactical approach toachieving those objectives. Major project types, which usually havea template project cycle and are common to both the governmentand commercial environments, include:

• System development—creation of a new product to meet a need.(Example: mobile telephone system)

• System integration—combining of existing entities into a func-tioning system. (Example: automated manufacturing facilityusing commercially available equipment)

• Production—process improvement of product replication to exist-ing documentation. (Example: reduce cost of building computers)

cott_c07.qxd 6/30/05 3:52 PM Page 122


Most well-known examples offailures and lessons learnedcome from big projects. That’sbecause failures of small proj-ects get little publicity.

Table 7.2 Project Types Characterized by Driving Force and Risks

Project Type If Driven By Then the Risk Is

System development #1 Performance Cost, schedule

System development #2 Cost Performance, schedule

System integration Compatibility Entity availability

Production Cost Performance, quality

Research and Technology Strays from corporatedevelopment needs

Facility Schedule Quality, cost, trades personnel

Deviations from the relevanttemplate cycle need to be sub-stantiated with solid rationale.

• Research and development—discovering a new approach to solv-ing a problem. (Example: use biological models to increase com-puter capabilities)

• Facilities—produce a new facility to meet a prescribed need.(Example: Airport, hospital, wafer production facility)

Each project type is characterized by its driving opportunityand risk factors. Table 7.2 is ordered by degree of risk and manage-ment complexity, with system development projects at the high end.There are exceptions: A company depending on specialized technol-ogy research for the bulk of its income could attribute the highestrisk to research projects. Some pharmaceutical companies fit thiscategory. Likewise, a company that develops very simple and pre-dictable products, such as campaign buttons, but depends on verylow-cost production, will view manufacturing projects as high-risk.

The project cycle template developed by your organizationneeds to be adapted to each project based on the:

• Project type, content, scope, and complexity.• Management environment—customers, contractors, and top

management.• Mandated constraints.• The management style.• Balance between project opportunities and risks.

The customer and provider project managers should jointly definetheir project cycle, the content and conduct of the decision gates,and the nature and content of the required decision gate artifacts.

Tailoring may add or delete project cycle features as shown:

cott_c07.qxd 6/30/05 3:52 PM Page 123


Select the lower level decisiongates.

Identify decision gateproducts.

Identify all activities.

Review pertinent lessonslearned.

Feature Modified: Example Modification

Phases Deactivation Phase addedSource Selection Phase deleted

Decision gates Consent-to-Pour-Concrete Review addedQualification Acceptance Review deleted

Products and activities Field Test Model addedOn-Site Training deleted

Tailoring requires foresight and informed judgment on the partof everyone involved, orchestrated by the project manager. We rec-ommend these tailoring steps:

• Phase selection is based on project type (development, research,product integration, production, facilities, service); content (e.g.,the hardware/software balance); tactical development and deliv-ery method (unified, incremental, linear, evolutionary, single,multiple, as defined in Chapter 19); scope; and complexity.

• Decision gate selection is based on the baseline sequence andartifacts to be developed and managed. Decision gates shouldalways occur at phase transitions and are often beneficial withinsome phases. Some decision gates can be included to help keepthe project sold to supporting organizations. Too few decisiongates allow the project to operate without control. Too manymay overburden the project with superf luous administration.

• Interim gates should be chosen to enhance opportunities and tominimize risk. Plan interim decision gates to ensure readinessfor the baseline management decision gates.

• Identify the products (artifacts) required at the decision gates:documents, deliverables, models, and agreements.

• Identify the activities necessary to produce the products re-quired at each decision gate.

• Validate the project cycle against past experience. Consider andapply lessons learned from related projects and previous con-tract experience, secured directly from project officials and incontract files.

• To obtain approval for your project cycle, develop justificationfor all deviations from the organization’s template. Although tai-loring is encouraged, changes need to be justified.

Specific internal and external standards may be an explicit fea-ture of your project cycle template. Those standards, as well as allrequirements and standards, should be appropriate to the reliability

Get executive concurrence.

Select the baseline manage-ment decision gates.

The tailoring process is one ofthe most important aspects ofproject planning.

Select the phases.

cott_c07.qxd 6/30/05 3:52 PM Page 124


and risk level of the project. Those embodied in contracts need tobe critically reviewed as part of the tailoring process. Situationsthat prompt tailoring of standards include:

• Inappropriate application of standards.• Blanket imposition of standards.• Underimposition of standards.• Implementation of a “no-tailoring” policy subsequent to con-

tract award.• Cost versus benefits of standards implementation is ignored.• The inappropriate imposition of high reliability or severe envi-

ronmental standards.• Standards applied arbitrarily, “just to be safe.”• Extensive and uncontrolled cross-referencing of standards.• Imposition of obsolete standards.• Application of government standards where commercial prac-

tices are acceptable.

These tailoring techniques are applicable to standards and otherartifacts, especially contract terms and conditions:

• Specify exact applicable paragraphs.• Specify exempted provisions.• Specify tailored values for referenced standards.• Expand referenced standards as necessary.• Specify exact documentation deliverables.• Extract selected standards and include in contract documentation.• Allow contractor choices when risk is acceptable.• Prioritize requirements.

SHORTENING THE PROJECT CYCLE TIME

The increasing challenges of time to market and technical obsoles-cence are familiar pressures for shorter schedules. Not only areshorter schedules less expensive, but they free up skilled personnelwho are usually needed on other projects.

The project cycle is the driver of subordinate project net-works and, consequently, the project schedule and its critical path(Figure 7.16).

Approaches to shorten the schedule should begin at the broad-est level—the project cycle. Techniques such as shortening thecritical path or running multiple shifts will be addressed in Chap-ters 12 and 17.

cott_c07.qxd 6/30/05 3:52 PM Page 125


The best way to ensure the shortest schedule and quality resultsis by applying a strategically and tactically correct project cyclemanaged by qualified and motivated personnel. Consider reducingthe technical risks and other impediments by selectively using pre-viously developed or previously qualified products.

The Geostationary Operational Environment Satellite (weathersatellite) project team decided to shorten the project cycle by gam-bling on a short cut.19 To reduce the predicted four-year develop-ment, the study period was deleted. The satellite was delivered nineyears later, an embarrassing five years late. Technical feasibility de-velopment under the direction of creative scientists was performedconcurrently with ongoing system development. This approach even-tually drove costs and schedules to multiples of the original predic-tions. Conversely, properly planned technology insertion projectshave succeeded in many instances at NASA and elsewhere.

When exceptional performance is required, the project teamshould be staffed with experts and co-located to facilitate efficientcommunications and reduce distractions. This approach is calledskunk works after Kelly Johnson’s Lockheed organization that pro-duced quantum leaps in technology in very short time spans.20 John-son’s team applied project cycle discipline, baseline management,change control, and decision gates. The team applied all practicesusing a “sweet spot” approach that was simple, yet formal, with lowamounts of documentation.

A skunk works may beappropriate for time-criticalmissions or emergencies, butthere are not enough expertsto staff all projects using theskunk works model.

Figure 7.16 The project cycle template drives the network.

Cost Account 14Cost Account 15Cost Account 16Cost Account 17

ITEM 1 2 3 4 5 6 7

WP No. 1WP No. 2

Cost Account 16

WP No. 3

Start Stop

Task 1 Task 2

Task 3

Task 4

Task 5

Task 6 Task 8

Task 9Task 7 Task 10

Project Network

UserRequirements

DefinitionPhase

ConceptDefinition

Phase

SystemSpecification

DefinitionPhase

AcquisitionPlanning

Phase

SourceSelection

Phase

SystemImplementation

Phase

DeploymentPhase

Operationsand

MaintenancePhase

Study Period Operations Period

DeactivationPhase

Implementation Period

When you do it right the firsttime, you get there quicker.

cott_c07.qxd 6/30/05 3:52 PM Page 126


The pursuit of “better, faster, cheaper” has caused some teamsto discard the discipline of the gated project cycle or to skip se-lected phases and decision gates without due regard for the conse-quences. This approach has proven to be unacceptably riskyand multiple failures have confirmed that proven practices wereoften eliminated in the desire to meet a “faster, better, cheaper”mandate.

The key to success is to tailor a gated cycle, based on a proventemplate, so that it is lean, efficient, and effective. Decision gatesshould add the value of baseline review and approval without caus-ing schedule delay or stalling ongoing progress. In a skunk worksenvironment, decision gates are usually working sessions, but re-tain the discipline required for ensuring binding and informed exe-cution. Decision gates should not require lengthy and cumbersomeprocesses and should not include people who are peripheral to the baselining decision. For example, to skip a Consent-to-Pour-Concrete Review is irresponsible and can result in a misplaced orpoorly constructed foundation. The review should take just a fewminutes requiring only an inspection of the layout, forms, steel,concrete mix, and the personnel credentials.

The following are inspiring examples of successful transitions tofaster cycle times:

Implementation Period

in Months

Product Original Improved

HP computer printer 54 22Ford automobile 48 16Ingersoll-Rand air grinder 40 15Warner clutch brake 36 10

PROJECT CYCLE EXERCISE

You and your partner are preparing to build a custom home on a siteyet to be selected. You want to ensure a smooth process and that youremain friends with each other and with all the other stakeholderswhen it is completed.

To minimize risk, you are to create your preferred project cyclecomplete with periods, phases, and decision gates by formulating thethree parallel congruent aspects (business, budget, and technical).

For the business aspect, consider: site location; resale; commu-nity trends; school districts; selection of architect, engineer, and

cott_c07.qxd 6/30/05 3:52 PM Page 127


contractor; whether you will act as general contractor or not; com-munity approval; architecture committee approval; planning permits;building permits; and certificate of occupancy. This is not a completelist. Add to it as necessary to ensure consideration of all stakeholders.Make sure your phases and decision gates structure an orderly pro-gression and provide the necessary agreements.

For the budget aspect, consider: target budgets, should-cost esti-mates, available assets, loan qualification, loan commitments, prog-ress payments, funds disbursements, management reserve, contractorholdbacks, performance bonuses, and penalties. This is not a com-plete list. Make sure your phases and decision gates structure an or-derly progression and provide the necessary agreements.

For the technical aspect consider: zoning, community or subdi-vision themes, concept development, design-to specifications, build-to artifacts, code compliance, quality control, material control, andinspections. This is not a complete list. Make sure your phases anddecision gates structure an orderly progression and provide the nec-essary agreements.

Your final product should be a three-row project cycle, one rowfor each of the three aspects. The columns should represent periodsand their phases. For example, the first period might be the studyperiod with the first phase defined as Owner Requirements Defini-tion. This is the phase in which you and your partner establish re-quirements, along with the overall budget and schedule, for theproject, independent of the selected site or building design.

cott_c07.qxd 6/30/05 3:52 PM Page 128

129

8THE TENMANAGEMENTELEMENTS

Effective management can indeed move mountains. One ofthe management breakthroughs in the Panama Canal projectwas the realization that the major challenge was logistics—how to relocate what amounted to a mountain of dirt, insteadof the prior view of digging a big ditch.

In a very different logistics challenge, that of supportingthe Gulf War with a military force equal to the population ofAlaska, General William G. Pagonis offers severalmanagement lessons. In his book, In Moving Mountains,1

Pagonis outlines his management style, which includes:

• Constant informational flow on index cards to all levels ofthe organization,

• Daily bulletins and stand-up meetings (limited to 30minutes and anyone interested, regardless of rank, canattend), and

• Articulation of each leader’s management style, “so thatsubordinates need zero time and energy guessing howthe manager manages.”

General Pagonis also had some sage advice regardingproject planning, control, and execution. “If you have goodpeople, and if you have the capability to expand anddelegate, and you have a centralized plan, imagination andingenuity will always win. I believe in centralized control anddecentralized execution.”

Essential 5

INCOSEThe INCOSE Handbook cites16 technical and 10 projectmanagement processes.These are analogous to the tenproject elements describedhere but do not correlateexactly as these elements arebehavioral rather than func-tional.

PMBOK ® GuideThe PMBOK ® Guide identifies nine knowledge areas.

cott_c08.qxd 6/30/05 3:50 PM Page 129


ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

ControlP

roje

ctS

tatu

s

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadership

ProjectVisibility

Project management and sys-tems engineering techniquesand tools share the samedrawers because they aremost commonly usedtogether.

This chapter and the ten that follow are about those good people;the planning, control, and execution together with organizing

the project and installing the management processes. The integratedprocess model (wheel and axle), introduced in Chapter 3, helps to vi-sualize project management and to appreciate the functional rela-tionships. The wheel depicts the first nine situational managementelements as the spokes of a wheel, held together by its rim, ProjectLeadership.

“Effectiveness lies in balance,” is Stephen Covey’s way of ex-pressing the need for a sense of proportion. Too much focus, hequips, “. . . is like a person who runs three or four hours a day, brag-ging about the extra ten years of life it creates, unaware he’s spend-ing it running.”2

THE ELEMENTS

The elements are the project’s tool chest, with project managementand systems engineering techniques and tools sorted and groupedinto like categories requiring ten drawers. The ten categories ofmanagement responsibilities, functions, techniques, and tools are allessential to orchestrating the team and developing the project’s sys-tem solution. They apply to:

• All types of projects.• All phases of the project cycle.• All organizations participating in the project.

An important facet of the wheel metaphor is the actual interde-pendence of the spokes of a wheel. The wheel is structurally muchgreater than the collection of its parts. But, one weak spoke reducesits overall effectiveness. The elements are described brief ly in thefollowing section and are then detailed in the ten correspondingchapters that follow.

Project Requirements

Project Requirements is all about managing the three baselines:business, budget, and technical. It covers both the development andmanagement of requirements. Included are business, budget, andtechnical requirements and spans from project conception to deac-tivation. Business requirements include, for example, the businessor mission case; contracts involved; stakeholder constraints; indus-try standards, policies, and trends; and funding sources. The budget

PMBOK ® GuideThis element is consistent withPMBOK ® Guide Ch 5 ProjectScope Management.

INCOSEThis element is consistent withINCOSE Handbook Sec 5.6Technical Processes andDecision-Making Process.

cott_c08.qxd 6/30/05 3:50 PM Page 130

THE TEN MANAGEMENT ELEMENTS 131

INCOSEThis element is consistentwith INCOSE Handbook Sec5.3 Organizing Process.

aspect covers the securing of funding and the spending plan. Thetechnical aspect covers system maturation across requirementsidentification, substantiation, concept selection, architecture selec-tion, decomposition, definition, integration, verification, and valida-tion. The requirements element is situational rather than sequentialsince new requirements, which can be introduced at almost anypoint in the project, need to be managed concurrently with the re-quirements already driving the development. While the project’sbusiness case drives this element, systems engineering accounts formost of the execution.

Organization Options

Organization Options considers the strengths and deficiencies of var-ious project structures (wiring diagrams), how each resolves account-abilities and responsibilities, and how each promotes teamwork andcommunications. Complex projects do not have to result in complexstructures, and there is no single “best” organization. There are manyoptions including matrix, integrated product teams, and integratedproject teams—even skunk works, where exceptional systems engi-neering has been demonstrated.3 (The skunk works is a name adoptedby the highly creative Lockheed aircraft development organization.)The Organization Options element is personnel-independent and of-fers a basis for selecting and changing the structure appropriately asthe project progresses through project cycle phases from inception todeactivation.

The Project Team

The Project Team element addresses staffing the organization. Selec-tion criteria should consider character attributes, qualifications, andthe specific skills demanded by the challenges of each project phase.Competency models that include necessary attributes and qualifica-tions should form the basis of selection for key positions such as theproject manager, the business manager, the systems engineer, theplanner, and the subcontractor manager. The preferred managementapproach requires that the team participants be matched to the re-qurements of the project cycle phase.

Project Planning

Project Planning spans the team’s conversion of the project’s re-quirements into team task authorizations, including delivery sched-ules and resource requirements. But it doesn’t end there. Too often

PMBOK ® GuideThis element is consistentwith PMBOK ® Guide Ch 9Project Human ResourcesManagement.

PMBOK ® GuideThis element is consistentwith PMBOK ® Guide Sec 2.3.3Organizational Structure, Ch 4Project Integration Manage-ment, and Ch 9 Project HumanResources Management.

INCOSEThis element is consistentwith INCOSE Handbook Sec5.3 Organizing Process andSec 5.11 Concurrent Engineer-ing Process.

cott_c08.qxd 6/30/05 3:50 PM Page 131


PMBOK ® GuideThis element is consistentwith PMBOK ® Guide Ch 6 Proj-ect Time Management and Ch7 Project Cost Management.

PMBOK® GuideThis element is consistent withPMBOK ® Guide Ch 11 ProjectRisk Management.

planning is done once and is then forgotten as the project straysfrom its intended path. Plans must be kept current, ref lecting newinformation and actual progress. The planning process should in-clude both manual and computer tools that support the developmentof the best tactical approach for accomplishing the project’s objec-tives. We encourage the use of the cards-on-the-wall technique de-scribed in Chapter 12 to develop the project’s task network andschedule.

Opportunities and Risks

Opportunities and Risks is about pursuing opportunities and manag-ing their risks. It encompasses the identification, evaluation, and man-agement of both opportunities and their associated risks. It spans thetechniques for determining and quantifying the value of potential ac-tions to enhance the opportunities and those necessary to mitigatethe risks. Opportunities and risks may be identified at any point inthe project cycle, so the techniques and tools of this element must beapplied perceptively as the project progresses through the cycle. Al-though an integral part of planning, it is common for both of thesefactors to be treated superficially by the project team and many proj-ects have failed as a result. The conventional mode of focusing theteam just on risks tends to foster negativism. An alternative is to havethe team seeking and seizing opportunities to excel and then to exam-ine and manage the risks of those opportunities. This approach en-courages innovation and fosters positive teamwork. The uniquenessand importance of opportunities and risks and how they should bemanaged justifies treatment as a separate element.

Project Control

Project Control is often misunderstood because many projects have aproject controls organization that reports activity and status ratherthan actually controlling anything. Controlling the project is neces-sary to ensure that planned events happen as planned and that un-planned events don’t happen. Control methods should apply to allthree baselines (business, budget, and technical). In our approach,proactive control is recognized as process control where every aspectthat needs to be controlled must have a control standard, a control au-thority, a control mechanism, and a variance detection system. Usingschedule control as an example, the standard is the baselined masterschedule, the authority is the business manager, the mechanism is thechange board, and the variance detection is schedule status. Cate-

PMBOK ® GuideThis element is consistent withPMBOK ® Guide discussionson control in Sec 5.5 ProjectScope, Sec 4.5 Monitor andControl Project Work, and Ch 8Project Quality Management.

INCOSEThis element is consistent withINCOSE Handbook Sec 5.2Planning.

INCOSEThis element is consistent withINCOSE Handbook Sec 5.8Risk Management Processes.

INCOSEThis element is consistent withINCOSE Handbook Sec 5.7Control Process and Sec 5.9Configuration Management.

cott_c08.qxd 6/30/05 3:50 PM Page 132

THE TEN MANAGEMENT ELEMENTS 133

PMBOK ® GuideThe PMBOK ® Guide and theINCOSE Handbook do notspecifically address visibilityas a management techniquecategory, although both citethe need to monitor ongoingwork.

PMBOK ® GuideThis element is consistent withPMBOK ® Guide Ch 5 ProjectScope Management, Ch 6Project Time Management,and Ch 7 Project Cost Manage-ment.

gories of controlled processes may include baselines, configuration,security, safety, requirements, manufacturing processes, software de-velopment environment, schedule, cost, and so on. Reactive controlconsists of corrective action initiated in response to unacceptablevariances. Many projects fail when control systems are not estab-lished or are circumvented.

Project Visibility

Project Visibility encompasses all of the techniques used by theproject team, including external stakeholders, to gather data anddisseminate information to ensure that the health of the project istransparent to the project team. It includes techniques like manage-ment by walking around (MBWA) and project information centersas well as electronic techniques such as voice mail, e-mail, andvideo conferencing. The visibility system and associated techniquesmust be designed to serve the active project phase, the organiza-tional structure, and geographic complexity.

Project Status

Project Status is frequently confused with project activity ratherthan performance metrics. Project Status is comprehensive measure-ments of performance against the plan to detect unacceptable vari-ances and determine the need for corrective action. Status shouldencompass schedule, cost, technical, and business progress. The eval-uation and measurement should also include the rate of change ofvariances if not corrected. Technical Performance Measurement andEarned Value Management are included in this technique and tool set.

Corrective Action

Corrective Action is the culmination of variance management andemphasizes that reactive management is necessary and proper for ef-fective project management. Corrective Actions are taken to returnthe project to plan and usually take place as a result of project status-ing. The techniques may include overtime, added work shifts, an al-ternate technical approach, new leadership, and so on. Projects thatignore variances and fail to implement corrective action are usuallyout of control.

Project Leadership

Project Leadership is the mortar that holds the other elements ofproject management and systems engineering intact and ensures that

PMBOK ® GuideThis element is consistentwith PMBOK ® Guide treat-ment of corrective actions ineach knowledge area.

INCOSEThe INCOSE Handbook Sec 6.3addresses TechnicalPerformance Measurement.

INCOSEThe INCOSE Handbookaddresses deviations fromspecifications.

cott_c08.qxd 6/30/05 3:50 PM Page 133


all are being properly implemented and applied. Leadership dependson the ability to inspire—to ensure that project members are moti-vated on both the individual and team levels to deliver as promisedwithin the desired project management culture. Leadership empha-sizes doing the right things, while doing things right is a primarymanagement responsibility. Leadership depends on the skillful ap-plication of techniques such as handling different personalities andmaturity levels, and team composition and rewards. History has con-firmed that, without strong leadership, the team is likely to strayfrom sound fundamentals and implement high-risk, failure-proneshort cuts. If the team members are fully trained in the worth of theelements and are believers in the process, then the need for strongleadership is reduced.

PROJECT MANAGEMENT ELEMENTS EXERCISE

Make a list of every project management technique that you can thinkof. Then group them according to the ten project management ele-ment categories. When a technique serves more than one element, lo-cate it in the element with the most significant impact. For instance, adecision gate often provides visibility, status, and control of baselineevolution; however, the primary purpose is baseline control.

Example:

Requirements Organization Options

Specification Functional organizationLessons learned Integrated product teamProcess standard Matrix organization

PMBOK ® GuideBoth the PMBOK ® Guide andthe INCOSE Handbookaddress the importance ofleadership but neitherembraces leadership as a separate knowledge area ormanagement category.

cott_c08.qxd 6/30/05 3:50 PM Page 134

P a r t T h r e e

The TenManagementElementsin Detail

The axle and wheel in the following figure depict the relationshipbetween the sequential and situational essentials of our model.

The project cycle, represented by the axle, is the time-phased back-bone of the project and identifies the tactical approach, project deliv-erables, and the sequence of major events. The movable wheel is theproject’s tool chest, representing the ten categories of processes,techniques, and tools that the enterprise encourages and supports forskillful application. In organizations that employ the CMMI, ISO, orSix Sigma frameworks, these processes and techniques are usuallycontrolled and well documented to ensure proper application. Like-wise, the knowledge areas identified in the PMI PMBOK® Guide andthe best practices in INCOSE Systems Engineering Handbook can beorganized and mapped into these ten categories to complete the inter-related set of management methods for consistent deployment.

The ten management ele-ments facilitate the tacticalapproach to realizing thestrategic goals of the project.

Each chapter in Part Three isdevoted to one of the ten man-agement elements—thespokes of the wheel.

cott_c09.qxd 6/30/05 3:47 PM Page 135

136 THE TEN MANAGEMENT ELEMENTS IN DETAIL

The techniques and tools in each category are applicable to proj-ect management and systems engineering as well as to hardware andsoftware development. In today’s evolving tool environment, includ-ing more extensive use of symbolic languages, widespread toolknowledge is rare. Care must be exercised to guard against f lawedcommunication through improper tool or language application. Ashift in the tactical approach, or the introduction of unfamiliar, so-phisticated tools, may require specialized training.

Skillful application of a feature-rich tool chest is becomingincreasingly relevant to mas-tering complexity.

cott_c09.qxd 6/30/05 3:47 PM Page 136

137

A major challenge in expressing project ideas in writing is theselection of words that accurately represent the thingsthemselves. Unfortunately, poorly chosen or missing wordsoften create major problems. This excerpt from the 1907specification for the Wright brothers’ first production contractmay be the ancestor of one of our most abused requirementclichés, the ubiquitous “user-friendly.”1

Wright Brothers’ production contract, circa 1907.

. . . Requirements

only half a word:

user requirements,customer requirements,

stakeholder requirements,contract requirements,internal requirements,

baselined requirements,unbaselined requirements,

concept independent,concept dependent,

allocated requirements,derived requirements

functional requirements,performance requirements,

design requirements,verification requirements,

requirements musts,requirements wants,

requirements weights.

PMBOK ® GuideThis chapter is consistent withPMBOK® Guide Ch 5 ProjectScope Management and Ch 10Project CommunicationManagement.

INCOSEThis chapter is also consistentwith the entire content of theINCOSE Handbook.

It is always a challenge to ensure that the requirements and theirimplications are understood. When the U.S. Signal Corps in 1907

released the invitation to bid on a heavier-than-air f lying machine,their overall objective was clear, even though the specification hadmany unclear details. At that time, it was not certain that anyone

9PROJECTREQUIREMENTS

ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

Control

Pro

ject

Sta

tus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project LeadershipProject

Visibility

managementelement 1

cott_c09.qxd 6/30/05 3:47 PM Page 137


could satisfy the requirements. Technical experts argued, “there isnot a known f lying machine in the world which could fulfill these re-quirements.”2 Only the Wright brothers knew the project wasachievable and that the U.S. Army had written the specificationbased on the Wright brothers’ claim that they had already built ma-chines that proved feasibility of the concepts. The army expectedonly 1 bid, but received 41. There were 40 bidders who had littlechance of succeeding because they did not have a clear understand-ing of what the vague requirements really implied, and what wouldbe needed to meet them. Two contracts were awarded, but only theWright brothers delivered.

SIGNS OF OUR IDEAS

Project requirements start with what the user really needs (not whatthe provider perceives that the user needs) and end when thoseneeds are satisfied as evidenced by successful user validation. In theend-to-end chain of technical and business development, there is anongoing danger of misunderstanding and ambiguity. This often leadsto nonessential, overspecified, unclear, or missing requirements, asillustrated by Figure 9.1—a cartoon familiar to every marketingstudent. Beyond just humor, this illustrates the current drive towardgraphical representations of system and mission requirements, solu-tion concepts, and solution behavior.

Overcoming Paradigm Paralysis

Recognizing a user need and having a great idea for solving it are notenough. Consider the typewriter. Viewing it as a widely used officeappliance for more than a century, one could conclude it had beenan instant success. On the contrary, acceptance was so slow that itspromoters nearly abandoned it as a failure. It took more than adecade for users to realize that they needed the typewriter.4

In more recent history, the word processor had a similar slowbeginning. Users (mostly typists) did not appreciate the significanceof the new technology. When surveyed in 1970 about what couldimprove their productivity, many typists requested a way to correctthe spelling of the last word typed before the text was transferred tothe paper. Typewriters were then produced that displayed one lineof text on a built-in one-line screen, with software to check spelling.It took several years for users to understand that, if the software

“We should have a greatmany fewer disputes in theworld if words were taken forwhat they are, the signs of ourideas only, and not for thethings themselves.”

John Locke3

Nonessential or overspecifiedrequirements frequently resultin missing schedule and costtargets.

cott_c09.qxd 6/30/05 3:47 PM Page 138

PROJECT REQUIREMENTS 139

Figure 9.1 Swings, a classic revisited.

As the RFP requested itAs the work statement

specified itAs it was negotiated

As it was built What the customerwanted

As engineering designed it

G

OODYEARBF

GOODRICH

could handle one line, a larger screen would allow composition andspell checking paragraphs and even whole pages.

For several years, management strongly resisted the conceptthat a word processor was a tool that engineers and managers shoulduse. The executives who viewed word processors as typewriter re-placements could not make the paradigm shift needed to envision atime when it would become commonplace for engineers and execu-tives to create their own text documents.

Reliance on the wrong users can be misleading. Clayton Chris-tensen presents a strong argument in his book, The Innovator’sDilemma,5 that relying on current users may prevent you from takingadvantage of an emerging technology poised to sweep away your cur-rent product. Competitors and new entrants with a more accurate vi-sion may capture your business. Christensen uses the computer harddisk and its evolution to illustrate his point. Early mainframe com-puter manufacturers used 14-inch hard drives. When smaller, lower-capacity 8-inch drives were demonstrated, disk manufacturers asked

Project requirements end onlywhen the user has beensatisfied.

cott_c09.qxd 6/30/05 3:47 PM Page 139


the mainframe manufacturers for their user requirements. Computermanufacturers were not interested in the smaller drives because thesmaller size advantages could not offset the associated higher cost permegabyte and the associated reduction in storage capacity and speed.Established disk manufacturers stopped their small drive develop-ment. However, emergent disk drive companies found minicomputermanufacturers who were willing to pay a premium for reduced physi-cal size. Within a few years, the 8-inch drive matured and surpassedthe larger drives in capacity and speed while maintaining a lowerprice. The emergent companies had captured the new market. Chris-tensen said, “Ultimately, every 14-inch drive maker was driven fromthe industry.” What is compelling about his thesis is that this cyclewas repeated at every change in disk size evolving from 14 inch to 8inch to 5.25 inch to 3.5 inch to 1.8 inch. The emergent firms that de-veloped a new market became the established firms that were in turndriven out of business by the next technological advance. Christensensaid, “The problem established firms seem unable to confront suc-cessfully is that of downward vision and mobility. . . .” He noted thatdisk manufacturers, held captive by their customers, delayed in mak-ing the strategic commitment to lead the market transition.

When Users and Developers Converge

It is important to decide on the approach to developing requirements,as it will directly affect the team’s ability to perform successfully.

Most projects start with relatively well-defined user or customerrequirements that can be further refined and developed by a struc-tured process. These processes are based on frameworks, methods,techniques, and tools all rooted in lessons learned and best prac-tices. Projects managed to these principles can usually be accuratelyplanned and predicted.

However, many projects start with ill-defined user and customerrequirements, leading to their discovery by the development processitself. Today, Rapid Application Development, Agile Development(including Extreme Programming), Hardware Model Shop Develop-ment, and others are f lexible approaches to simultaneous discoveryof both requirements and their solutions. Schedules and costs forthese projects are difficult to predict.

Many techniques have been developed to help project champi-ons more effectively discover and elicit user needs, and more effec-tively market solutions to meet those needs. One such technique,Quality Function Deployment (QFD), has proven to be very usefuland enduring.6 QFD defines and prioritizes product quality (re-quirements satisfaction) from the users’ perspective, and conveys to

INCOSEINCOSE Handbook Sec 4.6cites user involvement in theImplementation Process as abest practice and lack of userinvolvement as a traditionalproblem area. The INCOSEHandbook also emphasizesuser involvement in:

• Sec 4.7 Integration Process.

• Sec 4.8 Verification Process.

• Sec. 4.9 Validation process.

On most projects, newrequirements are introducedthroughout the project cycle.

cott_c09.qxd 6/30/05 3:47 PM Page 140


the designers what to emphasize. It then maps the system featuresto the prioritized requirements vividly illustrating both unsatisfiedrequirements and satisfaction overkill. This and other techniquesare illustrated in the following section on the decomposition analy-sis and resolution process.

There is a notable trend that impacts the timely development ofuser requirements. In his book, Business @ the Speed of Thought,Bill Gates emphasizes the orders of magnitude reduction in time re-quired to gather data on customer interests and customer reactionsto fielded products.7 He discusses how corporations such as Coca-Cola and Jiffy Lube have made very effective use of such data min-ing to better profile user interests and needs to improve theirresponsiveness and competitive position.

Rapid access to data via the Internet does not alter the basic de-velopment processes. As noted in Chapter 7, Microsoft follows a proj-ect cycle consistent with our template.8 Gates’s vision of the nextdecades reemphasizes the need to continually hone project manage-ment and systems engineering processes.

Getting the right set of users’ requirements is a major challengefacing the systems engineer, the project manager, and marketing or-ganizations. For new products or for substantially new applicationsof existing ones, some combination of incremental and evolutionarydevelopment is often the most effective approach to adjust to chang-ing market demands.

The Chain of Requirements Baselines

The project’s customer usually controls the definition of user re-quirements. The provider further refines these requirements withinthe baseline definition. User requirements are typically the first tobe baselined and placed under configuration management. An exam-ple is when a couple decides to build a house, they each make a listof their individual requirements. The combined list is the User Re-quirements Document (URD). Paired with this set of requirementsis the context of implementation or user Concept of Operations(CONOPS), which describes the project’s solution space, behavior,and environment.9 In general, CONOPS is similar to, but broaderthan, current system or software “use cases.” This is changing withthe development of SysML, the object-oriented systems engineeringmodeling and design language. The Object Management Group(www.omg.org) is designing templates for systems engineering sce-narios and use cases to include all the content necessary for a com-plete CONOPS. The intent is to eliminate the need for a separateCONOPS document.

The CONOPS for a house char-acterizes the community, cli-mate, and infrastructureassociated with the selectedbuilding site and describeshow any house solution isexpected to be used by theresidents.

cott_c09.qxd 6/30/05 3:47 PM Page 141


System development proceeds from system requirements to thecreation of the “design-to” and “build-to” artifacts (documents,drawings, architectural models, engineering models, etc.) for everyentity of the architecture. Each entity can adopt linear, unified, in-cremental, or evolutionary development, but for simplicity of expla-nation we use linear development here. The process is appliedrepeatedly until the requirements have been elaborated to piecepart and process details (Figure 9.2).

REQUIREMENTS MANAGEMENT: A CRITICALACTIVITY THROUGHOUT THE PROJECT CYCLE

We must concern ourselves with both requirements developmentand requirements management. The requirements artifacts, whichare products of the project-cycle phases, detail the maturing sys-tem solution.

The requirements management element is situational since newrequirements can be introduced into the project at almost any time

Figure 9.2 Requirements management: The chain of requirements baselines.

cott_c09.qxd 6/30/05 3:47 PM Page 142


and decomposition level, to be managed concurrently with the ma-turing baselines. In fact, the current trend is to embrace require-ments changes to keep abreast of both the moving business case andemerging technologies. Figure 9.3 illustrates the real world ofchanging requirements. Failure to respond to the changing environ-ment can cause project failure—a situation often experienced intoday’s project environment.

REQUIREMENTS MANAGEMENT COMPLEXITY

Requirements management encompasses the transfer of business andtechnical details among the domain specific participants. In the in-formation transfer, voids and conf licts will emerge if the communica-tion is imprecise or misunderstood. Much like in the parlor game ofpassing a story from one person to another among the attendees, thereis a danger that the end result is not what the originator intended. Re-quirements management and requirements management artifactsmust be configured to ensure undistorted communication. Figure 9.4illustrates the challenge to be addressed.

FROM REQUIREMENTS TO SYSTEM SOLUTIONS

The sequential facet of requirements development is represented bythe core of the Vee Model (Figure 9.5), as described in Chapter 7. Asimple three-level hierarchy is shown here, with the system at the

Be prepared to manage withinthis environment to facilitatechanges, not to prevent them.

Figure 9.3 Requirements change environment.

cott_c09.qxd 6/30/05 3:47 PM Page 143


PMBOK ® GuideThe PMBOK® Guide Sec 5.4Scope Verification presentsverification as stakeholder for-mal acceptance of deliver-ables.

INCOSEThe INCOSE Handbook andthis book define the stake-holder formal acceptanceactivity as Validation. Verifica-tion is proof of specificationcompliance.

top level. At the lowest level, there can be many configuration items(CIs), and so the Vee is shown thicker at its base. On the left leg ofthe Vee, requirements are identified and concepts are created. Onthe right leg, the completed configuration items are verified and in-tegrated into subsystems, which in turn are verified and integratedto make the system.

System development is described by the process called Decom-position Analysis and Resolution (DAR; Figure 9.6). The DAR pro-cess guides the systems engineering activities that f low down anddefine the requirements for each entity and how they should be sat-isfied or resolved. Systems engineering typically manages the DARprocess.

The Verification Analysis and Resolution (VAR) process (Fig-ure 9.7) defines the tasks spanning from assembling of parts andprocesses and the coding of software through integration, verifica-tion, and validation. As integration and verification activities areconducted, verification anomalies that occur must be resolved to asatisfactory conclusion or the project will stall. The VAR process il-lustrates the activities required to resolve anomalies to the satis-

Figure 9.4 Requirements management complexity.

cott_c09.qxd 6/30/05 3:47 PM Page 144


faction of the customer. Systems engineering typically oversees theVAR process.

For a given decomposition level of the Architecture Vee, say asubsystem, the DAR represents the development of the solution andthe elaboration detail required for that subsystem. For Commercial-Off-The-Shelf entities (COTS), the build-to detail is not requiredbecause it already exists. The DAR process is repeated for every ar-chitecture entity from the system, down to the lowest-configurationitems, such as computer software units. Likewise, the VAR processis applied to each entity on the right leg of the Architecture Vee.Figure 9.8 illustrates the DAR and VAR processes applied in a planeorthogonal to the Architecture Vee. DAR and VAR processes are ap-plied separately to each entity when there are multiple entities at a

Figure 9.5 The basic Architecture Vee model.

Architecture Vee

System RealizationSystem Realization

Cu

sto

me

r C

on

firm

atio

n

Arc

hite

ctu

re I

ssu

es

Inve

stig

atio

n

An

om

aly

Inve

stig

atio

nC

ust

om

er

Co

nfir

ma

tion

Evolv

ing B

aseli

ne

Evolving Baseline

SystemRequirements, Concept, Architecture, Design-to, Build-to, and Verification

and Validation Plans



Subsystem Requirements, Concept, Architecture, Design-to, Build-to, and Verification








Component Requirements, Concept, Architecture, Design-to, Build-to, and Verification








Lowest CI Requirements, Concept, Architecture, Design-to, Build-to, and Verification


Lowest CI Requirements, Concept, Architecture, Design-to, Build-to, and Verification


SubsystemVerification and

Preparation for System Integration and

Verification



Verification

SystemVerification and

Validation


Validation

ComponentVerification and Preparation for

Subsystem Integration



IV&V

SubsystemVerification/Validation and Preparation for System Integration

SubsystemVerification/Validation and Preparation for System Integration





Lowest CIVerification/Validation and Preparation for


Lowest CIVerification/Validation and Preparation for


Evolving Baseline

Evol

ving

Base

line

Architecture Decom

position

& Definition

Architecture Decom

position

& Definition

Arch

itect

ure

Inte

grat

ion

& V

erifi

catio

n

Arch

itect

ure

Inte

grat

ion

& V

erifi

catio

n

Verification and Validation Planning(all levels)

cott_c09.qxd 6/30/05 3:47 PM Page 145


given level in the architecture hierarchy (e.g., in Figure 9.8 two sub-systems are shown).

To understand the complete sequence—one that represents bestpractices—requires the more detailed view of the intersecting Veesprovided in Chapter 19.

THE DECOMPOSITION ANALYSIS ANDRESOLUTION PROCESS ENSURES THE DESIGN

SATISFIES USERS AND STAKEHOLDERS

The DAR is the essence of systems engineering in which trade stud-ies ensure the best value concept and architecture at every decom-position level. This section addresses each of the activities in theDAR process illustrated in Figure 9.6.

To illustrate the DAR process, this section uses one author ’s ex-perience in remodeling his home. Further, the example demonstrates

Figure 9.6 Decomposition Analysis and Resolution Process (DAR).

INCOSEINCOSE Handbook Sec 4.4Architectural Design Processtreats both concept and archi-tecture determination withinthe Architectural DesignProcess.

cott_c09.qxd 6/30/05 3:47 PM Page 146


Figure 9.7 Verification Analysis and Resolution Process (VAR).

the benefits of using this process—even for simple or familiar proj-ects. In this case, the process is applied to selecting a home-heatingsystem. For this heating system, the “higher-level requirements andconstraints” include personal comfort zones, aesthetics, and the ex-isting house structure. The margin notes relate this example to theDAR steps that follow.

The Sources and Techniques for Determining Requirements

For each entity, the DAR process is initiated and driven byhigher-level requirements and constraints. These come from al-ready approved baselines such as the service utilities provided to astructure and the inf luences of users and stakeholders at the sys-tem level and at succeeding levels of decomposition down to thelevel under analysis.

To ensure all requirements have been elicited from users andstakeholders, a check-and-balance system should be implemented,usually consisting of multiple techniques. Some examples follow:

The sources for remodelingrequirements include buildingcodes, and most important,the users’ comfort. The Con-text of Implementation is thehistorical climate of the area,the expected energy loss ofthe structure, the constraintsof the existing structure, andthe available utilities.

What did you like and dislikeabout heating systems withwhich you have hadexperience?

cott_c09.qxd 6/30/05 3:47 PM Page 147


Technique • Comments and suggestions.Documentation • Review best available data and records beforereview interviewing stakeholders.Interviews • Face-to-face stakeholder discussions.

• Best conducted using a checklist.• Document and prioritize requirements and

constraints as they are identified.Focus groups • Ask open-ended questions.

• Used to identify issues and establish realisticexpectations.

Surveys • Questionnaire to sample users.• Quantitative type questions.• May require statistical analysis.• Must be comprehensive and unambiguous.

Comment cards • Provides feedback on an existing product orservice.

Observation and • Verify that users really do what they say theyconfirmation do.

Figure 9.8 The DAR and VAR processes applied to the Architecture Vee.

PMBOK ® GuideThe PMBOK® Guide Sec 2.2Project Stakeholders covers thesignificance of stakeholders toproject success and Sec 10.4Manage Stakeholders coversstakeholder management.

The PMBOK® Guide does not address stakeholder manage-ment as critical to Require-ments Management.

cott_c09.qxd 6/30/05 3:47 PM Page 148


The problem to be solved ismaintaining a comfortablehome temperature under allconditions. The evaluation cri-teria include a fast reactiontime, economical fuel, clean(low dust), low noise, fullyautomatic operation, and lowinitial cost.

Prioritization is perhaps the most significant technique forproactively managing project requirements and avoiding overspeci-fied and biased solutions. The extent to which management disci-pline can be exercised by putting first things first obviously dependson knowing and understanding priorities. If they are not explicitlystated in contracts, and they usually are not, they must be under-stood by the time the user requirements and system requirementsartifacts are baselined and placed under change control. Require-ments prioritization is essential to the implementation of design-tocost, cost as an independent variable (CAIV), and in pursuing value-driven solutions.

Prioritization is usually done in two forms: weighted criteria fortrade-off analysis and independent priority levels (at least three lev-els: must, want, and nice to have).

Understand the Context of Implementation

The context of the implementation describes the environmentwithin which the project solution must operate. To understand thecontext, you need to define the system boundaries and include all in-terface and operational factors such as reliability, maintainability,availability, human factors, and security. In addition, brainstormingsessions can help to verify your understanding. Ask probing ques-tions and listen. It’s often helpful to verify the understanding with acustomer approved behavioral model.

The contractor in Figure 9.9 had a clear understanding of therequirements, but was a little short on understanding the context.

Define the Problem to Be Solved and Establish Weighted

Evaluation Criteria

At each level of decomposition, the problem is defined by the higher-level baseline (e.g., user requirements, entity requirements, concept,and specification at each level). Each requirement should includeweighted evaluation criteria, together with applicable scoring meth-ods to represent how well any candidate solution satisfies the criteria.Concept selection criteria can become unwieldy if dozens of criteriaare used in evaluating candidate concepts. A more practical approachis to select the most challenging, high-priority factors to drive the se-lection. To illustrate the point, consider the selection criteria for anew family car. Critical safety and performance factors may be diffi-cult to achieve and should be included. However, a black color and anautomatic transmission, while absolute “musts,” are easy to achieveand should not complicate the evaluation.

For example:San Francisco Bay area—mildweather; no freezing, but rapidchanges of up to 25˚F with fogpatterns; maximum outsidetemp of about 90˚F (32˚C) andminimum of about 32˚F (0˚C).

In our heating system exam-ple, fast temperatureresponse, low noise level,minimum dust, and “set it andforget it” operation rankedmuch higher than cost.

cott_c09.qxd 6/30/05 3:47 PM Page 149


You also need to decide the risk philosophy because risk toler-ance drives risk management. Answers to the following typical ques-tions will help establish the risk philosophy for your project:

• What are the consequences of system failure?Loss of life, mission failure, enterprise embarrassment, cost,schedule, technical, or safety.

• What is the technology maturity? Can “off-the-shelf ” enti-ties be used?Consequence of delivering a new, but obsolete, system versus astate-of-the-art system with no logistics.

• What are the opportunities of and for the system? How willthey be managed?

• What are the future growth expectations?

Figure 9.9 The Far Side © 1996 Farworks, Inc., distributed by Universal Press

Syndicate. Reprinted with permission. All rights reserved.

cott_c09.qxd 6/30/05 3:47 PM Page 150


• What are the risks to, in, and from the system? How will theybe managed?

Risk philosophy (tolerance) is often expressed in terms such as“single thread design,” or “no single point failure modes in missioncritical functions” or in a reliability rating such as 0.03 percent fail-ure probability.

The risk philosophy will drive these risk adjustment decisions:

Risk Decision Decision Range

Design for growth Planned or noneNew technology High use to no useExpendable margins High margins to no marginReliability High to lowPart derating Substantial to noneRedundancy Full to noneInspection 100 percent to noneQualification Required high margins to noneVerification 100 percent unit verification to noneCertification Full pedigree proof to no proofSparing Full to noneCost Mandatory constraint to desirable targetSchedule Mandatory constraint to desirable targetOther market Planned to noneapplications

Define the Required Behavior and Performance.

The objective is to describe the behavior of the essential system func-tions. This can be done in narrative form, but the trend is towardgraphical techniques such as the functional f low diagrams shownhere, which are usually more effective. When characterizing behav-ior, use action verbs such as detect, trigger, initiate, deliver, and can-cel. For example, the accompanying margin note is the narrativedescription of the behavior for the house heating system.

The two methods for f lowing requirements to lower-level entitiesare derivation (analysis) and allocation (past experience and judg-ment). In the derivation method, the requirements for each succeedingarchitecture level are established on the basis of quantitative analysis.Allocated requirements are based on past experiences and rules of

The required behavior is thatthe heating system detect thedifference between the temper-ature setting and the currentambient temperature. The sys-tem then introduces heat untilthat difference is close to zero.

The performance require-ments are:

1. Detection of temperaturedifferences of two degrees.

2. Maximum of five-minuteheater response to bringthe temperature back tothe set point.

cott_c09.qxd 6/30/05 3:47 PM Page 151


thumb, and, therefore, their validity and applicability must be con-firmed as the design evolves. Incorporating COTS or existing ob-jects into the solution also contributes to defining allocatedrequirements.

Develop the Candidate Logical or Physical Solutions

Identify potential solutions that satisfy the functional and perfor-mance requirements, using past experience, analytical approaches,brainstorming candidate concepts, or other means. Assess thecandidates and develop system discriminators for each viable one.Discriminators may be technical, cost, schedule, or risk. Avoid re-jecting “obvious misfits” prematurely until they have had fair con-sideration.

• Develop the top-level architectures to understand each candi-date’s relative complexity.

• Flowdown functional and performance requirements. (Lower-level requirements will usually be concept and architecturespecific.)

• Identify critical issues (may require investigating down to hard-ware part or software unit level).

• Use available performance history or hardware and softwarefeasibility models to determine and confirm achievable perfor-mance values.

Select the Best Solution

By using the weighted concept selection criteria previously defined,make an informed selection of the best solution (Figure 9.10). Scoreeach candidate solution against the criteria. This ultimately leads toa comparison of weighted scores and the basis for rational designchoices that meet the highest priority requirements.

The techniques for weighting criteria include: weighting against afixed standard, weighting relative to the most important criterion orbest alternative, and pair-wise comparison (e.g., Analytical HierarchyProcess10). The decision criteria may need to include subjective crite-ria obtained from many individuals. These weighted criteria can bedecided by consensus, voting (permitting multiple votes per individ-ual), or the geometric mean of individual scores. If at all possible,the customer or user should confirm that the decision criteria andweights are appropriate for concept selection. This helps avoid deci-sions that are based on incorrect assumptions.

For this example, the heatingcandidates are electrical andhydronic baseboard, electricalradiant ceiling, hydronic-in-slab, and forced-air heating.

In our example, none of thestandard conventional solu-tions meet all of the criteria.Radiant solutions are tooslow; forced air is too noisyand dirty.

The hydronic-in-slab solutionprovides the opportunity forquiet, dust-free heating. Therisk: Glycol pipes in slab floorsare difficult to repair.

cott_c09.qxd 6/30/05 3:47 PM Page 152


INCOSEINCOSE Handbook Sec. 6.4Trade Study and SensitivityAnalysis provides additionaltrade study information.

A Heating Debate

The heating system selection process had to be repeated with new candidate solutions. Radiantsystems were analyzed to try to improve response times and no practical solutions were found.Forced air was analyzed for ways to reduce noise and dust. One creative contractor suggestedsuspending a forced-hot-air system in the thermal- and sound-insulated attic on shock- andvibration-isolated rods hung from the rafters to minimize noise and to ground residual vibration tothe outside walls and foundation. By achieving further isolation with flexible fabric ducting andclean air with an electronic air filter, all criteria could be met with a modified forced air system.This was the system selected for implementation.

Figure 9.10 Selection flow chart.

cott_c09.qxd 6/30/05 3:47 PM Page 153


It is a good practice to perform a sensitivity analysis of theweighted criteria to ensure that the criteria weightings are not dis-torted. For instance, if more than half of the decision criteriaweightings are concerned with vehicle appearance factors such ascolor, shape, and upholstery, then a vehicle selection decision maybe inappropriately driven by aesthetics rather than performance,safety, and reliability features. Figure 9.11 illustrates the weightingcriteria before and after sensitivity analysis revealed a skeweddistribution.

One of the most powerful ways to compare alternatives is touse the decision analysis process developed by Kepner and Tre-goe.11 The weighted comparison matrix shown in Figure 9.12 illus-trates the process.

The selection process is not complete until “other factors” havebeen considered. The highest scoring candidate may not be the bestchoice if other factors, not in the evaluation criteria, significantlyimpact the decision. The final step in the decision process is to eval-uate the other factors in the following five steps:

1. Assess other factors of the most promising alternatives:• Consider both business and technical issues.• Determine the consequences.• Estimate probability and impact.• Identify possible actions to take advantage of opportunities or

mitigate risks.

Figure 9.11 Sensitivity analysis (example).

cott_c09.qxd 6/30/05 3:47 PM Page 154


2. Evaluate failure modes and effects of the promising candidates:• Determine impact on the system.• Determine approach to mitigate effects (e.g., requirements

for increased reliability, fault tolerance, or fail safe operation).• Incorporate in the solution.

3. Adopt other factor actions identified in step one.4. Rescore candidates with actions incorporated.5. Reconsider the effect of residual factors.

Quality Function Deployment—House of Quality

A second method for comparing the relative value of concepts isthe application of QFD (also known as the House of Quality sincethe graphic representation is in the shape of a house with a pointed

Figure 9.12 The Study Process, based on Kepner-Tregoe Decision Analysis Methodology.

DecisionStatement:

Select the best vehicle to meet the needs of the Patrick family.(Mom, dad, and three kids, ages 5 to 16)

EvaluationCriteria:

Alternative 1 Alternative 2 Alternative 3 Alternative 4

Mid-Size Domestic Car

Musts (Go/No-Go):

Japanese Sports Car Domestic Mini-Van Italian Sports Car

• Under $25,000

• Transport 5 people

Wants:• 25 mpg (10.6 kpl)*

• Carry garden supplies

• Crash safety

• Use on dates (16 yo.)

Weight CommentsScore

Raw(R) R*W

CommentsScore

R*WComments

Score

R*WComments

Score

R*W

8

10

9

4

10

2

10

10

80

20

90

40

7

10

7

5

56

100

63

20

Max Score (10xW): 310

Total Score: 230 239

Raw(R)

Raw(R)

Raw(R)

26.2 mpg avg. (11.2 kpl)

Trunk only

Rated high ontests

Considered“Cool” by peers

25.1 mpg avg. (10.7 kpl)

Good capacity

Meets min.reqmts

“Parents” typecar

* 1 mpg (miles per gallon) = 0.426 kpl (kilometers per liter)Note: Scores that are within 10%

are essentially equal

Selecting Candidates for Further Consideration

cott_c09.qxd 6/30/05 3:47 PM Page 155


roof ). The purpose of QFD is to map prioritized requirementsagainst solution (concept) features to determine unsatisfied re-quirements and requirements overkill. Figure 9.13 is a completedexample for the heating system used in this chapter. Note the firstand second columns contain rows of prioritized requirements andtheir weights. The remaining columns are the concept features withcolumn and row intersections revealing degrees of coincidence. Theroof structure reveals intersections of correlation and conf lict.

Architecture Selection

Once the concept is chosen, the “best” of alternate architecturesmust also be selected. There are usually multiple ways in which a

Figure 9.13 Quality Function Deployment example.

Prio

rit

y

1

1

1

2

1

2

2

3

Fast

Quiet

Clean

Easy to use

Transparent

Comfortable

Reliable

Low Maintenance

Wh

at’s

Wa

nte

dW

hat’s

Wa

nte

d

Fu

rn

ac

e L

oc

ati

on

Re

mo

te

Pe

rim

ete

r R

eg

iste

rs

Kic

k P

late

Re

gis

ters

Air

Re

turn

in

Sk

yli

gh

t C

hu

te

Ele

ctr

os

tati

c F

ilte

rs

Tim

er T

he

rm

os

tat

Fa

bric

Du

cts

Tw

o F

urn

ac

es

Tw

o Z

on

es

Hig

h Q

ua

lity

Sil

en

t F

urn

ac

e

How – Design Characteristics

+

+

++

+

+ Positive Contribution Correlation

- Counter Productive Correlation

+

++

Strong Contribution

Mild Contribution

Negative Contribution

Strong Contribution

Mild Contribution


Strong Contribution

Mild Contribution


Forced Hot Air

Heating System

Example

cott_c09.qxd 6/30/05 3:47 PM Page 156


system or solution architecture can be decomposed. Ease of integra-tion, ease of upgrading, simplicity of management accountability, orease of development, among others, usually drives the selection.The product breakdown structure represents the architecture and isdriven by the integration approach. Figure 9.14 illustrates four inte-gration approaches to a single concept and architecture.

The following are two dramatic examples of how innovative ar-chitecture selection at the second level of the product breakdownstructure resulted in huge leaps in schedule performance.

The first involved the ship building industry, which typicallybuilt ships by laying the keel on the launching ways (the ramp usedfor launching the completed ship) and then expanding the struc-ture, followed by each trade, in its turn, installing the plumbing,electrical, propulsion, and so on. This architecture made it impos-sible to work multiple trades in parallel as many had to wait theirturn to participate. Additionally, only one ship could be con-structed at a time on the launching ways, thereby seriously con-straining the total throughput. The launching ways literally werethe critical path.

Bath Iron Works in Maine had incentive contracts with bonusesfor early delivery. They envisioned the ship as a series of fully inte-grated modular slices allowing simultaneous participation of all

Figure 9.14 The Product Breakdown Structure provides a road map for

integration.

cott_c09.qxd 6/30/05 3:47 PM Page 157


trades on multiple modular slices of the ship. Additionally, time onthe critical-path launching ways was greatly reduced, thus providingincreased throughput. Ship delivery was so rapid that the U.S. Navyhad difficulty finding parking places for the ships.

The home building industry achieved similar breakthrough re-sults in terms of construction time. The city of San Diego, California,held a home construction contest to determine just how fast a three-bedroom house could be constructed, starting with bare ground andusing no prefabricated modules. Like the shipyard, the building indus-try also was hampered by the serial trades sequence. Two contractorsexcelled by changing the second level of their product breakdownstructure (PBS) from the usual trades-defined PBS elements such asframing and plumbing. They defined instead fully integrated PBSmodules, such as north wall and roof assembly. This allowed a crew of300 to work in parallel. Two houses were built on bare lots, which hadto be fully landscaped and ready for occupancy in less than threehours each. Since the focus was on speed of construction, and notlow-cost replication, this new approach did not “sweep the industry.”However, it is an amazing example of creativity.

These two illustrations highlight the importance of selecting theproper architecture. Today, antivirus software companies structuretheir software architecture to facilitate easy updating and we rou-tinely download new versions of one or more of the architecture in-crements to combat new viruses.

The specification for the selected concept and architecture pre-pares the team for elaboration of the details at each level of decompo-sition. The creation of the design-to and build-to artifacts completesthe DAR process at each level. The approved baseline now includesthe concept, architecture, design-to specifications, and the decision-support artifacts such as trade-off analyses. Each concept specifica-tion must answer the following:

• What is the problem to be solved, and in what context?• What is the proposed concept?• What must the solution do? (Functional Performance)• How well must the solution do it? (Quantitative Performance)• Within what context and interfaces?• Is there a preferred architecture?• What is the risk tolerance (risk philosophy)?• How will customer satisfaction be determined (verification and

validation planning)?

This results in the approved higher-level baseline for the next lowerarchitecture decomposition level.

In our example, “forced hotair” becomes the requirementfor lower level decisions suchas furnace and filter selection,furnace room, ducting design,foundation design, walldesign, and service locations.

cott_c09.qxd 6/30/05 3:47 PM Page 158


The DAR process is repeated until all architecture entities,down to the lowest configuration item, have been baselined. Thebaselining of any one entity at a level requires collaborative develop-ment with interfacing entities to ensure mutual compatibility.

THE VERIFICATION ANALYSIS ANDRESOLUTION PROCESS

The companion to the DAR process is the VAR, a process re-peated through the integration and verification sequences as newgroups of entities are combined to ultimately form the system (Fig-ure 9.7).

The VAR process is an integral part of requirements manage-ment. It provides the framework for verifying each level of integra-tion according to the verification criteria embodied in the entityspecifications. Conventional wisdom is that tests are more percep-tive than analysis because tests encompass the “real-world” issuesthat are very hard to model analytically. But beware—tests can in-troduce complications of their own and can mask the actual condi-tion or behavior. In the spring of 1999, an expensive system was inits final system test. The system incorporated explosive bolts. Thebolts were to fire only on operator command. Analysis predictedthat voltage transients at system start-up could cause the explosivesto fire prematurely, but laboratory tests repeatedly indicated noanomalies.

The first time the system was put into operational use, the ex-plosive bolts fired on system start-up, just as the analysis predicted.The lab tests had, in fact, experienced a high voltage transient thefirst time the system was turned on, but it was never repeated onmany subsequent trials that day, even after sitting idle for severalhours. So the test director concluded there were no transients andthe system was safe. In fact, it took a day of idle time for the tran-sient to reoccur—but in the press of time, that test was never rerun.The test omission allowed a defective solution to be installed, result-ing in a multimillion-dollar loss.

The improper setup of a test device allowed the f law in theHubble mirror to go undetected for six years, until the telescope wasin orbit and the problem was there for all to see. The unfortunatefact is that the f law was detected six years prior to launch. Thosetroubling data were ignored until it was too late. In college, we oftenran lab experiments until we got the right answer, then we quit andignored the prior failures. Such habits have carried over to the

INCOSEINCOSE Handbook Sec 4.7Integration Process, 4.8 Verifi-cation Process, and 4.9 Valida-tion Process provideadditional information.

The success of the VAR pro-cess is rooted in left Vee plan-ning for right Vee execution.

cott_c09.qxd 6/30/05 3:47 PM Page 159


workplace with serious consequences. In a project, all anomaliesmust be fully resolved or you risk finding bad news when its impactis devastating.

Verification may be done by analysis, inspection, demonstration,or test. With the previous cautions in mind, testing is the preferredapproach in most situations, supplemented by the other techniquesas necessary. Depending on the objectives, various types of testsare performed:

Engineering: Prove feasibility and demonstrate performance tosupport the design process.

Informal: Demonstrate readiness for formal testing (cus-tomer acceptance).

Formal: Produce acceptance of verification data. Verifica-tions are witnessed by the customer.

Qualification: Demonstrate that the design will perform in itsintended environment with margin (temperature,vibration, shock, humidity, transaction overload,unexpected power shutdown and recovery, etc.).

Acceptance: Demonstrate that the deliverable item is builtwith sufficient quality that it replicates the qual-ification item performance and that it will per-form as intended in the operational environment.

Environmental: Simulate the operating environment by subject-ing the test article to temperature, vibration, hu-midity, acoustic, shocks, salt spray, radiation, andso on. Can also be used to stress parts to findweaknesses.

Life: Demonstrate system life and failure modes in theexpected environment. Accelerated life tests maybe used to shorten test duration if accelerated ex-posure does not distort the expected results.

Reliability: Demonstrate system failure rates and failuremodes.

First Article: Demonstrate quality of first manufactured article.Nth Article: Demonstrate that the quality of any selected unit

has not degraded from the first article. Samplingplans may be used when sufficient data have beengathered to provide a reliable statistical basis.

cott_c09.qxd 6/30/05 3:47 PM Page 160


PROJECT REQUIREMENTS TRACEABILITYAND ACCOUNTABILITY

The identification and management of the proper “parentage”(parent-child relationships) from the highest-level system require-ments to the lowest-level configuration item requirement and to ver-ification requirements and methods is referred to as RequirementsTraceability—a requirements management responsibility.

Requirements development, analysis, and management are suf-ficiently complex to require computer-based tools to facilitate theinteractive mapping and change management. A comparison of manyof the commercial requirements traceability tools available can befound on www.incose.org.

The purpose of requirements accountability is to ensure thatall requirements have been responded to and have been verified bytest, inspection, demonstration, and, where the foregoing are notpossible, simulation and analysis. Systems engineering is responsi-ble for auditing the verification results and certifying that the evi-dence demonstrates conclusively that the requirements have beenachieved. A compliance matrix, called Requirements Traceabilityand Verification Matrix (RTVM), presents the verification results,and is often used as the certified evidence for customer acceptance.

MANAGING TO BE DETERMINED AND TO BERESOLVED REQUIREMENTS

Unresolved requirements should be viewed as liens against the base-line and must be resolved as early as possible to reduce program-matic risk. Undefined requirements are referred to as To BeDetermined (TBD). TBDs are a risk to the project since their im-pacts cannot be priced or scheduled. When the TBD is defined, itmay have an impact that leads to contractual actions, such as an en-gineering change proposal, to adjust the contract baseline or a re-quest for equitable adjustment.

Requirements whose definition is approximately but not exactlyknown are called To Be Resolved (TBR). Usually, rough estimates ofa TBR’s impact can be made and accommodated in the contractbaseline. However, there is always a risk that the resolution of aTBR may be beyond the schedule or cost baseline, resulting in acontract action to adjust the baseline.

Formal work-off plans must be developed for both TBDs andTBRs, including “must have” delivery dates (Figure 9.15). Failure of

INCOSEINCOSE Handbook Sec 4.2Stakeholder RequirementsDefinition Process initiates therequirements managementprocess.

It’s naive to believe that TBDsand TBRs can be resolved withno impact to cost or schedule.

In traceability, a child mayhave many parents.

cott_c09.qxd 6/30/05 3:47 PM Page 161


the customer to deliver on these negotiated delivery dates may begrounds for contract-based constructive change claims, includingcompensation.

THE POTENTIAL FOR LOW-RISK HARDWAREAND SOFTWARE SOLUTIONS

Previously Developed Products consist of COTS, Government-Off-The-Shelf (GOTS), and Nondevelopment-Item (NDI) hard-ware and software products. Because others have alreadyaccomplished the development, these products offer potential low-risk solutions to those who can benefit from their reuse. However,they are not risk free because interface, performance, and techni-cal support problems may override whatever advantages they mayappear to have. Thorough investigation is required to examine boththe opportunities and risks of the intended reuse. The push forbetter, faster, and cheaper products in both the commercial andgovernment environments has created added pressure to useCOTS and NDI entities. In most cases, this is exactly the rightthing to do. However, the pressures to shorten the schedule, aswell as reduce costs, have caused use of existing entities withoutfully understanding their limitations. Avoiding these problems willbe discussed in Part Four.

Figure 9.15 Resolve TBDs and TBRs early.

TBDs and TBRs

create LIENS

AGAINST THE

BASELINE

Leads to ProductConsistent With

System Specification

Waiveror

DeviationRequired to

Proceed

Late Resolutionor

Resolution NOTConsistent With

System Spec

Leads toProduct

That MightMeet User

NeedsMay ImpactSchedule

Deviation

Waiver

Temporary spec.relaxation beforethe factAcceptance of non-conformance afterthe fact

TimelyResolution

To Be DeterminedTo Be Resolved - or -To Be Reviewed

TBD –TBR –

–

–

cott_c09.qxd 6/30/05 3:47 PM Page 162


In today’s office automation systems and business informationsystems, there are high percentages of COTS in use. In commandand control systems, the percentages are markedly lower. This is un-derstandable, recognizing the proliferation of high-quality and reli-able business applications and the comparative nonexistence ofcommercial multipurpose interactive command systems.

Users of COTS products seek to realize reduced developmenttime and costs and to achieve known and predictable perfor-mance. Users also expect to rely on long-term technical support.While these advantages are attractive, the user may actually expe-rience substandard performance, difficulty in producing integra-tion code, rights to data issues, and no technical support due tomodification of the product or later version releases supersedingthe chosen product.

In evaluating COTS products, requirements should be priori-tized to facilitate selection between candidate COTS products, noneof which may satisfy all requirements. Therefore, a best availablechoice may have to suffice.

The following twelve lessons learned regarding the use ofCOTS or other previously developed products is an alert to poten-tial problems:

1. COTS may be more or less capable than needed.2. Required features may be dropped by the vendor in later up-

grades.3. Bugs in present versions may never be fixed.4. Upward compatibility may not be assured.5. Interface hardware and software is often required.6. COTS may be difficult to integrate with other parts of the solution

and once integrated its performance may not be easy to predict.7. Source code may be required but difficult to get. The source

code may have to be held in an escrow account.8. Capability certifications are difficult to achieve.9. Altering the COTS item voids its warranty.

10. Vendors abandon products at their convenience.11. Training may not be available.12. Life-cycle costs depend on supplier commitment to the prod-

uct line.

REQUIREMENTS MANAGEMENT TOOLS

From an information systems viewpoint, the handling of require-ments data is similar to inventory control. Both involve complex,

cott_c09.qxd 6/30/05 3:47 PM Page 163


interrelated tables; cross-references; and “where-used” indices. Man-ual tools such as card files and index tables are readily available.

General-purpose database applications, many of them inexpen-sive desktop products, can be further customized to address a spe-cific project or even an organization’s tailored project template.

Currently, there are a number of specialty requirements manage-ment tools available, some with extended capabilities such as systemsimulation, behavior analysis, and trade-off analysis. Most of thesetools are found in the systems engineering domain and at systems en-gineering conferences rather than in the project management domain.

The International Council on Systems Engineering (INCOSE)maintains a web site (www.incose.org) with a compilation of about1,500 systems engineering tools.

Several popular graphical tools, such as SmartDraw and Mi-crosoft Visio, incorporate templates for behavior diagrams and pro-cess f lowcharts using the Unified Modeling Language™ (UML).

A REQUIREMENTS MODELING LANGUAGE—THE EMERGING ROLE OF SYSML

Appendix A contains an overview of the emerging role of UML andSysML in systems engineering. Large, complex systems must bestructured in a way that enables scalability, security, and robust exe-cution under stressful conditions, and their architecture must beclearly enough defined so that they can be built and maintained. Awell-designed architecture benefits any program, not just the largestones. Large applications are mentioned first because structure is away of dealing with complexity. The benefits of structure (and ofmodeling and design) compound as application size grows large. TheObject Management Group’s Unified Modeling Language (UML)helps specify, visualize, and document models of software systems,including their structure and design, in a way that meets all of theserequirements.12 Fortunately, these same benefits can be extended tosystems engineering.

To develop any complex system requires a team of engineersworking at the system level to analyze the needs of the stakeholders,define all the requirements, devise the best concept from several al-ternatives, and define the system architecture. The system team mustalso provide the designers with all of the models and visualizationsthat describe the architecture down to the lowest decomposed level.David Oliver in his book Engineering Complex Systems with Modelsand Objects states, “These descriptions must be provided in the rep-resentations, terminology, and notations used by the different design

cott_c09.qxd 6/30/05 3:47 PM Page 164


disciplines. They must be unambiguous, complete, and mutually con-sistent such that the entities will integrate to provide the desiredemergent behavior of the system.”13 So how does the systems engi-neer benefit from UML, designed primarily for software personnel?

First, there are many systems being developed that use object-oriented software development. As such, the current structuredapproach to systems engineering poses a communication barrier be-tween the systems engineer and the software developers due to dif-fering visual representations. Basically, there is the lack of a commonnotation, semantics, and terminology as well as a definite tool incom-patibility. This gap needs to be bridged to take full advantage of ob-ject-oriented design and full use of UML. To be effective, inaddition to the structure language (UML), one needs a systems-engineering method consistent with that language and additionalsystems-engineering notation.

In November 2000, the INCOSE Object Oriented Systems En-gineering Methodology (OOSEM) Working Group was establishedto help further evolve the methodology.

The OOSEM working group goals are to:

• Evolve the object-oriented systems engineering methodology.• Establish requirements and proposed solutions for extending

UML to support-systems engineering modeling.• Develop education materials to train systems engineers in the

OOSEM systems-engineering method.

OOSEM includes the following development activities:

• Analyze needs.• Define system requirements.• Define logical architecture.• Synthesize candidate allocated architectures.• Optimize and evaluate alternatives.• Validate and verify the system.

These activities are consistent with the systems engineering Veemodel and process that is applied at each level of the system hierar-chy. Fundamental tenets of systems engineering, such as disciplinedmanagement processes (i.e., risk, configuration management, plan-ning, measurement), and the use of multidisciplinary teams, must beapplied to support each of these activities to be effective.

SysML is to be a customized version of UML 2 to support thespecification, analysis, design, verification, and validation of com-plex systems that may include hardware, software, data, personnel,procedures, and facilities. The customization effort began on Sep-tember 13, 2001, with a meeting of an OMG chartered group called

INCOSEINCOSE Handbook Sec 6.2Object Oriented Systems Engi-neering Method provides addi-tional information.

cott_c09.qxd 6/30/05 3:47 PM Page 165


the Systems Engineering Domain Special Interest Group (SEDESIG).“The goals of that group were to:

• Provide a standard SE modeling language to specify, design, andverify complex systems.

• Facilitate integration of systems, software, and other engineer-ing disciplines.

• Promote rigor in the transfer of information between disciplinesand tools.”14

It is expected that SysML will be formally adopted by OMG in 2005.

REQUIREMENTS ELEMENT EXERCISE

The objective of this exercise is to provide experience in developing andstating requirements using a method of musts, wants, and priorities.

You have decided to purchase a new vehicle. You have not yet de-cided on the model or brand and want to make certain that you selectthe best solution for your needs. Make a list of your “musts” (will notbuy without them), “wants” (not mandatory, but desirable), andweight the “wants” according to their importance.

The “musts” need to be strictly quantitative, such as, “must costless than $35,000” or, “must have four or more doors.” Qualitative state-ments such as “must be low maintenance” do not qualify as a “must.” Itis acceptable to have an evaluation factor in both categories. For in-stance, “must stop from 70 mph in 170 feet (110 kph in 52 meters)” canbe a “must” and “short braking distance” can be a “want” to give creditto those that pass the “must” and are better than others at braking.

Once you have identified the “musts” and “wants,” prioritize the“wants” by selecting the most important “want” and assign it aweight of 10. Determine the relative importance of the other“wants” and weight them accordingly. If two or more “wants” are ofequal importance, they will have equal weights. The final list withweights provides the evaluation criteria against which alternativescan be scored. Now, conduct a sensitivity analysis to ensure that theweights are properly apportioned to your selection objectives so thatthe many entertainment and convenience features are not unbalanc-ing the selection.

Rate the vehicle that best satisfies a “want” with a score of tenfor that “want.” Score the other alternatives relative to that “want.”Equal scores are acceptable. Multiply the criteria weight by the al-ternative score results to arrive at a weighted score for each “want”factor. Sum the scores to determine the overall ranking.

cott_c09.qxd 6/30/05 3:47 PM Page 166

167

10ORGANIZATIONOPTIONS

“Confusion is a word we haveinvented for an order which isnot understood.”

Henry Miller1

PMBOK ® GuideThis chapter is consistent withthe PMBOK® Guide Sec 2.3Organizational Influences andCh 9 Project Human ResourcesManagement.

Lockheed’s wide-body L1011 was heralded by both pilots andpassengers as an excellent aircraft. However, Lockheed’screditors and stockholders were not complementary, sincethe L1011 was a financial albatross, taking the corporation tothe brink of bankruptcy. How is it that this technical winner,superior in many ways to its DC-10 competitor, was such afinancial loser? A significant contributor was the conflict builtinto the organization. Functional departments reporting to thegeneral manager were expected to respond to a staff projectmanager. The general manager allocated resources directlyto the functional departments, such as marketing,engineering, manufacturing, quality, and product test. Theproject manager was then expected to manage thesestovepipes without resource control or other authority. L1011team members reported that the engineering manageractually barred the project manager from attending changecontrol meetings. This ineffective structure resulted in futileturnstile changing of the project manager and, at the sametime, ongoing change of the aircraft baseline withoutcommensurate sales-price adjustments. The general managershould have assumed the role of the project manager orchartered the project manager with the financial resourcesand the authority to buy necessary services from the bestsource. In the latter case, the project manager would havebeen the functional organizations’ customer.

INCOSERelated areas are the INCOSEHandbook Sec 5.3 OrganizingProcess and Sec 5.11 Concur-rent Engineering.

ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

Control

Pro

ject

Sta

tus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadership

ProjectVisibility

ManagementElement 2

cott_c10.qxd 6/30/05 3:37 PM Page 167


As Peter Drucker puts it, “At best an organizational structurewill not cause trouble.”2 As the previous situation illustrates,

the wrong organizational structure will not only cause trouble, it candestroy the project.

In the case of the L1011, the only person with the authority tomaintain consistency between the business goals and the technicalsolution was actually the general manager, not the project manager.While this organization is not ideal, it could work if the project wereproperly chartered and stakeholder roles and responsibilities weredefined and properly executed (e.g., if the general manager activelyresolved emerging conf licts).

A great deal has been written about organizational theory—afavorite topic of industrial psychologists. The variations on form andorder are limitless, as are the behavioral implications. Experiencereveals that the point of confusion usually occurs when the order,though rationally structured by management, is not adequately ex-plained to those who must operate by it—team members and otherswho participate in the project. This confusion is largely eliminatedwhen individual, as well as organizational, roles and relationships aredetermined by a defined process. Preferably, the structure itself im-plies much of this order; for example, the logical path to problemsolving, conf lict resolution, and information. But even so, these needto be explicitly defined in the organization charter and reinforced bythe project manager.

This chapter addresses organization options independent fromthe physical or geographical location. The growing trend towardtelecommuting and “virtual” teams may have little effect on the or-ganization structure but it may significantly impact communicationsand teamwork, so those trends are addressed in Chapters 5 and 6.

Each project manager faces the task of changing the organiza-tion structure to suit the changing phases of the project cycle.

The project manager must also ensure that supplying organiza-tions, including subcontractors, also have effective organizationstructures. One of the authors had a major subcontract where theproject manager did not have resource control and was essentiallyimpotent to manage. To fix the problem, a contract change was madeto ensure that the subcontractor ’s project manager was given re-source control by his management. Improved performance was a di-rect result of the directed change.

While effective management, leadership, and teamwork aremore important success factors than structural details, the optimalorganization can contribute significantly to project performanceand efficiency. In most organizations, the project manager does not

Organization: A reportingstructure in which individualsfunction as a unit to conductbusiness or perform a function.

cott_c10.qxd 6/30/05 3:37 PM Page 168

ORGANIZATION OPTIONS 169

have freedom to reshape the external reporting relationships of theproject unless the project is the major part of the corporation or theproject is a major customer of a subcontractor. For instance, youusually do not have the freedom to choose a functional structure ina matrix-oriented corporation. If you are in a well-established, tra-ditional hierarchical organization, then trying to convert to a matrixor trying to introduce cross-functional project teams can be a majorand distracting challenge.3 However, understanding the organizationstrengths and weaknesses of various options will allow you to workmore effectively within your constraints and to push for changewhen there is a high return in doing so. Chapter 11 covers the proj-ect team, the associated management element focused on building aworking organization.

The organization’s design should promote the team’s dominantinterfaces and preferred communication channels. Its purpose is toensure that project requirements are met, hence, the importanceof designing the organization after the requirements of the projectare established and understood. As a practical matter, the coreteam (initially consisting of the project manager, systems engineer-ing manager, and other lead positions) is probably involved duringthe study period.

Most projects are best served by some form of matrix organiza-tion combined with elements from pure functional organizations andothers from pure project form, each addressing a specific subprojector support function. We address the primary reasons for selectingeach form after reviewing their relative strengths and weaknesses.

FUNCTIONAL ORGANIZATIONS

The functional organization is the traditional business structure. Ithas prevailed throughout the manufacturing-driven, industrial era.With a few exceptions, the functional organization has proved its ef-fectiveness for single-technology companies having one high-volumeproduct line serving a common market with a common manufactur-ing process and /or a business segment with relatively slow or pre-dictable technical changes. One notable exception is a companyserving a broad common market, but also having one large customerwith special requirements that requires the focused attention of aproject manager. A semiconductor company, for example, supplyingstandard parts might benefit from a separate product or project or-ganization to serve customers requiring “ruggedized” versions ofthe same products.

The organization designshould respond to what it willtake to satisfy the require-ments.

cott_c10.qxd 6/30/05 3:37 PM Page 169


Figure 10.1 Pure support skill centers.

The following sections explain the strengths and weaknesses ofcommon organizational structures. It is beneficial to understandhow to deal with the weaknesses of your configuration.

Pure Support (Functional)

Skill Centers

Strengths Weaknesses

+ Skill development. −Customer interface unclear.+ Technology development. −Project priority unclear.+ Technology transfer. −Confused status communications.+ Low talent duplication. −Project schedule/cost controls+ High personnel loyalty. are difficult.

As organizations grow to multiple projects/products with multi-ple markets/customers, the pure functional organization (Figure 10.1)often proves ineffective. For example, one of our clients was trying tomanage approximately 50 project /product lines through a traditionalfunctional organization. When a customer called the salesman to findout how their project was doing, the following scenario often oc-curred. The salesman would refer the customer to one of the func-tional departments, such as engineering or production. The functionalmanagers would either pass the inquirer along to others or respond in-appropriately, being aware only of the status of their portion of thework. For projects that were in the design or production phase, thecustomer might end up talking to an engineering manager or to pro-duction control, who would either give partial or misleading informa-tion or avoid blame by disclosing the internal problems of otherdepartments. This resulted in the frustrated customer calling thepresident for better service. The president would raise that cus-

cott_c10.qxd 6/30/05 3:37 PM Page 170


Figure 10.2 Pure support product centers.

tomer’s priority to the top, causing all the other projects to sufferas the priorities in design or on the shop f loor shifted. Prioritieswould change daily as the top position was given to the most recentsqueaky wheel. This confusion in managing priorities and determin-ing status usually leads to setting up product centers or divisions (Fig-ure 10.2).

Pure Support (Functional)

Product Centers


+ Product development. −Customer interface unclear.+ Technology development. −Technology transfer difficult.+ High personnel loyalty. −Project priorities unclear.

−Communications confused.−Schedule/cost controls are difficult.

THE PURE PROJECT ORGANIZATION

The pure project organization, shown in Figure 10.3, is composed ofseparate autonomous units, each being one project. They oftenevolve from functional or support organizations with the success ofa high-priority task force as a model. Because the project managerhas full line (hire and fire) authority over the team for the project’sduration, this structure maximizes the project manager ’s controland the clarity of the customer interface. However, the project man-ager may become consumed by human-resource issues. Unfortu-nately, the dramatic success of a single, high-priority task force isnot easily replicated when multiple projects are competing for keycompany resources and priority.

cott_c10.qxd 6/30/05 3:37 PM Page 171


Figure 10.3 Pure support organization.

PMBOK ® GuideThe PMBOK® Guide Sec 2.3.4The Role of the PMO in Orga-nizational Structures cites thevalue of a Project Manage-ment Office (PMO) for all orga-nizational structures butparticularly for projectized andmatrix organizations to over-see project management andwork prioritization.

Pure Project Organization


+ Accountability clear. −Talent duplication.+ Customer interface clear. −Technology awareness.+ Controls strong. −Technical sharing.+ Communications strong. −Career development.+ Balances technical, cost, −Hire/fire.

and schedule. −Staffing irregular workloads.

Project organizations are relatively costly because of the inabil-ity to share part-time resources and they may also cause isolation ofpersonnel from the company’s strategy and technology focus. Thereis also a natural tendency for team members to be kept on the proj-ect well beyond the date that is justified. Team members are typi-cally dedicated full time—another contributor to the inefficiency ofthis organization. This is one of the reasons that some functionssuch as personnel (human resources) and finance are often main-tained as central support organizations, with talent assigned to proj-ects as required.

THE CONVENTIONAL MATRIX ORGANIZATION

Most organizations are a blend of functional and project structuresin the form of a matrix with solid (hire/fire management) vertical

The strengths of a matrixorganization can usually beincreased by effectiveleadership.

cott_c10.qxd 6/30/05 3:37 PM Page 172


Figure 10.4 The conventional matrix.

GeneralManager

ManufacturingEngineeringProgramManagement TestSystem

Effectiveness

ProjectManager A

ProjectManager B

PMBOK ® GuideThe PMBOK ® Guide Sec 2.3.3Organization Structure differen-tiates three matrix structures:

1. Weak.

2. Balanced.

3. Strong.

The differentiator is the loca-tion of budget control; func-tional managers (weak) andthe project manager (strong).

lines and dotted (task assignment or borrow/return) horizontal lines.The most common form of matrix has the team members connectedto project managers by dotted lines and connected to their functionalmanagers by solid lines as shown in Figure 10.4. These structurescombine the best aspects of the pure functional and pure project or-ganization forms, as demonstrated by their relative strengths.

An effective matrix structure is perhaps the strongest of allproject management organizational options. The key word is “effec-tive.” To succeed, all participants have to understand their roles andresponsibilities. The project team member has two bosses, but thisshould not cause conf lict to the project team member if it is clearthat the project manager defines only what is to be done and thefunctional manager defines how to do it. All three authors workedfor decades in highly efficient matrix environments in a variety ofsituations. As consultants, we have also witnessed poorly imple-mented matrix organizations. In fact, in the large-scale mergers thathave occurred in the 1990s many organizations lost their formulaand their current matrix structures are staffed with unhappy teammembers. A well-functioning matrix organization is like a bicycle—it is dynamically stable but statically unstable.

Those readers familiar with military resource deployment haveseen a similar battlefield evolution brought about largely by technol-ogy. Traditional, vertically organized functional branches (army, airforce, and navy) are rapidly being “matrixed” into battle units ortask groups. This counterpart to the business task force consists oftightly coordinated resources under the direction of, perhaps, a tankcommander, for the period of one engagement. The infantry, armor,aircraft, and even ships form a team, coupled more by computer

The military matrix in the fieldis analogous to the conven-tional matrix on the businessbattlefield.

cott_c10.qxd 6/30/05 3:37 PM Page 173


communications than by voice. These task groups, after having car-ried out their mission, return to their permanent units available forother deployments.

Conventional Matrix Organization


+ Single point accountability. −Two boss syndrome.+ Customer interface clear. −High management skill level+ Rapid reaction. required.+ Duplication reduced. −Competition for resources.+ Technology development. −Lack of employee recognition.+ Career development. −Management cooperation required.+ Disbanded easily.

Functional organizations that have evolved to product centersmay transition to a matrix organization based on those product cen-ters. While this structure does offer some of the advantages of theconventional matrix, it combines the disadvantages of both the ma-trix and the product-centered functional organization. It tends to in-hibit both technology and career development and requires greaterintegration skills. The following discusses variations of the conven-tional matrix that have proven to be effective.

Conventional matrix organizations can operate in one of twoways. In the first, the project manager borrows people from the sup-port managers and provides daily supervision and funding. In thesecond form, the project manager “subcontracts” the work to thesupport manager, providing a task statement and funding. For exam-ple, a key technology development may require the combined talentsand synergy of a team of specialists working in close proximity. Thisneed may best be met by the specialists meeting periodically with-out disrupting their ongoing work routine.

THE COMPOUND OR COLLOCATEDMATRIX ORGANIZATION

Some environments may benefit from variants of the conventionalmatrix form. To compensate for structural and /or personnel short-comings, most large projects will introduce pure functional struc-ture and /or pure project structure sections to form a compoundmatrix. For example, critical resources (either administrative ortechnical) may report directly (solid line) to the project manager or,alternatively, be collocated with the project office. The latter,

The compound and collocatedmatrix forms offer effectivecompromises between theproject and conventionalmatrix structures.

cott_c10.qxd 6/30/05 3:37 PM Page 174


The hybrid matrix retains thefocus and most advantages ofthe pure project organizationwhile improving efficiency.

known as the collocated matrix, is shown in Figure 10.5. It providesfor maximum focus on project objectives with a corresponding dis-advantage: isolating the project team members from the company’soverall strategic operations.

The Collocated Matrix


+ Single point accountability. −Technology awareness.+ Clear customer interface. −Management support.+ Good control. −Technical sharing.+ Single location. −Staffing irregular workloads.+ High personnel loyalty. −Personnel evaluation by+ Career development. functional manager.

In some project intensive environments, such as the aerospaceindustry, and in geographically dispersed multinational companies,the relationships are sometimes reversed. In the hybrid matrix, theteam members are connected to the project manager for the dura-tion of the project by solid lines approaching a pure project organi-zation. In this case, the functional departments are small core staffsresponsible for long-term strategic technology and concept develop-ment—perhaps even common component or subsystem develop-ment. For example, the corporate engineering manager typically

Figure 10.5 The collocated matrix.

cott_c10.qxd 6/30/05 3:37 PM Page 175


looks for means to avoid duplication, share technology, and providefor professional development. He or she may have line/budget au-thority for proprietary technology development projects—some orall of which may be performed by direct reports. Another variationshares a common (typically high-tech) manufacturing operation, butassigns the production engineering function, usually part of themanufacturing function, to the project.

DESIGNING AND MAINTAININGA RELEVANT STRUCTURE

A single government agency or company will often simultaneouslyuse several organization options for project management. Further-more, each project will typically evolve through several structuresduring its life and the project manager and customer can signifi-cantly inf luence the option selected. Deciding on the initial struc-ture involves both subjective criteria, such as prior organizationalexperience, and objective criteria, such as the availability and loca-tion of resources. The guidelines that follow are for simple projectsor subprojects:

• Pure Functional organization is the best match for a single proj-ect that is relatively independent in interface or technology. Purefunctional is not preferred for management of multiple projects.

• Pure Project is a good choice for projects for which schedule, se-curity, and /or product performance is paramount and cost is rel-atively unimportant.

• Conventional Matrix works well if the project manager has au-thority to manage the funds and has business relationships withsupporting managers, including formal work commitments andparticipation in project planning. The matrix fails when theproject manager is seen only as a coordinator with the supportmanagers operating on a “best effort” basis.

• Collocated Matrix should be considered for high priority proj-ects dependent on critical resources and /or technologies andwhen ongoing involvement with company strategy and long-termbusiness goals are secondary.

INTEGRATED PROJECT TEAMS ANDINTEGRATED PRODUCT TEAMS

There are many ways to develop an organizational structure. Somemanagers begin by assuming a starting form, perhaps a conventional

All decision criteria should beprioritized.

cott_c10.qxd 6/30/05 3:37 PM Page 176


Figure 10.6 Typical project team organization.

matrix, and then they modify it to resolve staffing barriers. We pre-fer a process that matches the organization to the requirements (assegmented into major work packages by the work breakdown struc-ture). In this process, the total project is viewed as a set of simpleprojects, defined by the nature of their deliverables and /or resourcerequirements (Figure 10.6). The terminology for this approach is In-tegrated Product Teams.

Matrix refinements, such as Integrated Project Teams and Inte-grated Product Teams, have solved product responsibility issues;however, these forms bring a new set of issues regarding system in-tegration and responsibility for the perpetuation of the enterprise,such as technology development and technology sharing. The role ofsystems engineering, always important, becomes crucial when inte-grating a system developed by multiple product teams.

Integrated Project Teams andIntegrated Product Teamsinstill responsibility andaccountability.

cott_c10.qxd 6/30/05 3:37 PM Page 177


When defining the original structure, you need to plan re-sponses to the inevitable project-cycle dynamics. Without anticipat-ing changes, you may find yourself evaluating the following symptomsand thrashing through crisis-driven reorganizations. While no orga-nization is expected to be perfect, some may be f lawed to the extentthat project success is at risk. Before reorganizing, be sure it is justi-fied. The authors of Dynamic Project Management offer these symp-toms of an inappropriate organization to watch for:

Is there a [lack of] product pride and ownership among theteam members?Is too much attention typically given to one particular technicalfunction, to the neglect of other technical components?Does a great deal of finger-pointing exist across technical groups?Is slippage common, while customer responsiveness is negligible?Do project participants appear unsure of their responsibilitiesor of the mission or objective(s) of the project?Are projects experiencing considerable cost overruns as a resultof duplication of effort or unclear delegation of responsibilities?Do project participants complain of a lack of job satisfaction,rewards, or recognition for project efforts?

The authors observe that, “Unfortunately, when symptoms ofinadequate organizing appear, some companies typically respond byapplying more time, money, or resources to the already weakenedand inadequate project organization. If the problem truly is an inap-propriately structured project organization, simply addressing thesymptoms while ignoring the basic problem itself may leave the or-ganization and its people frustrated and demoralized, as projectscontinue to slip and conf lict continues to grow.” 4

On the other hand, each of the symptoms previously discussed,taken separately, could have little to do with the organization and alot to do with leadership, or the lack thereof. One has to look closelyat the combinations and patterns to conclude that reorganization isindeed needed.

The single biggest error in organization design is overcomplexityor redundancy leading to confused responsibility. We’ve definedseveral complex configurations and suggested others in an effort todefine the problem and provide choices. However, some configura-tions such as the hybrid matrix are suitable for only the very largestprojects or for an entire multidivisional corporation.

Complex projects need notlead to complex structures.

cott_c10.qxd 6/30/05 3:37 PM Page 178


WIRING IN THE SYSTEMS ENGINEER

Regardless of the organization form, the systems engineer is thetechnical leader for the project and should be prominently posi-tioned and directly connected to the project manager. In somecases, the systems engineer is staff to the project manager. Forlarger projects, the systems engineer as a direct report supervises arequirements development staff and a separate integration andverification staff. This configuration provides the checks and bal-ances to ensure the right solution is being built right. It is undesir-able for the systems engineer to report directly to the engineeringdepartment and then be loaned to the project manager. In thatstructure, the systems engineer will be biased to satisfying the en-gineering position rather than that of satisfying the client. Chapter11 suggests a structure to enhance the teamwork within the proj-ect office level.

MATRIX MANAGEMENT OPERATIONS

While matrix structures often result in turf conf lict and reducedmorale, this can be prevented by using a fairly simple technique.The technique is for the project office and the functional managersto collaborate on an operating procedure to clarify the roles, re-sponsibilities, and relationships in the potential conf lict areas of thedual-manager environment. One well-developed matrix organizationdefined its operating procedures and relationships in 26 areas. Fig-ure 10.7 is a template for this procedure. Note that the most impor-tant column is the Relationship column. This column should stress acollaborative team relationship for the good of the project and theproject’s customer.

ORGANIZATION OPTIONS EXERCISE

You’ve been appointed the project manager for a new nine-monthproject. The first three months are allocated to design, four monthsfor product development, and two months to testing and delivery. De-sign will require four skilled experts. The development will require alarge number of technicians working in four separate locations, oneof which is overseas. Test, integration, and final delivery will beperformed in your plant 30 miles from your office location. Your com-pany typically uses matrix management and all technical resources

cott_c10.qxd 6/30/05 3:37 PM Page 179


exist within the company; however, other projects frequently com-pete for the same resources. You can elect to borrow staff by name orcontract for services by department, but you must decide which modebest suits your needs. You are aware that another project of signifi-cance is about to start and will probably need similar resourcesto yours.

List the advantages and shortcomings of matrix management inthis context. Define actions you should take to minimize potentialstaffing difficulties.

Figure 10.7 Matrix management operating procedure template.

cott_c10.qxd 6/30/05 3:37 PM Page 180

181

11THE PROJECT TEAM

One of the authors had a contract with a premier tape recordersupplier for an existing flight-proven tape recorder. One daythe company announced that several of its team had quit. As itturned out, they were the finest of the engineering team. Costsbegan to accelerate and schedules began to slip as thecompany futilely staffed the project with unskilled personnel.

Before long it became apparent that there was no hopeof achieving delivery as contracted. The contract wasterminated and a new contract was awarded to the newcompany the departing engineers had formed. It was apainful decision and not without risk as the new companywas a start-up and the new recorder design had to bequalified before being certified for flight. Credibility is a majorfactor in building a team and, in this case, the contract had tofollow the technical capability of the team. There was noother viable choice.

“The meeting of two personal-ities is like the contact of twochemical substances: if thereis any reaction, both aretransformed.”

Carl Jung

PMBOK ® GuideThis chapter is consistent withthe PMBOK® Guide Ch 9 Proj-ect Human Resources Man-agement and Sec 4.1 DevelopProject Charter.

In Chapter 6, we focused on instilling teamwork, a perpetual prop-erty of projects and the third Essential to successful project man-

agement. We now look at team formation, a situational processongoing throughout the project cycle, as each phase requires a dif-ferent mix of talented individuals. As Lewis comments in his book,Team-Based Project Management, “Teams don’t just happen—theymust be built.”1 Forming the team requires six steps:

1. Defining the project manager’s roles, responsibilities, and authority.2. Selecting the project manager.

Forming the team starts withselecting the right people anddefining their roles.

ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

Control

Pro

ject

Sta

tus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project LeadershipProject

Visibility

ManagementElement 3

cott_c11.qxd 6/30/05 3:33 PM Page 181


PMBOK ® GuideThe PMBOK ® Guide Ch 9 Proj-ect Human Resources Man-agement identifies fourprocess groups:

• Human Resource Planning.

• Acquire Project Team.

• Develop Project Team.

• Manage Project Team.

3. Chartering the project and confirming the project manager ’sauthority.

4. Staffing the team.5. Selecting the right subcontractors.6. Managing the organization’s interfaces and interrelationships.

The Project Team element goes beyond the traditional staff-ing function and includes management of the interfaces with sup-porting organizations, contractors, upper management, and thecustomer (which may be the internal marketing/sales department)(Figure 11.1).

ATTRIBUTES AND COMPETENCIES

When selecting individuals to populate an organization there are twoprimary factors that should be considered. The first is the attributesof the individual and whether those attributes fit the organizationyou have or plan to have. Attributes have to do with personal conduct

Figure 11.1 The project team.

FacilitiesManufacturingLogistics Test Operations ProcurementHuman

Resources

ServicesFinance SpecialtyEngineering Quality Engineering

OtherDivisions

Legal

SystemsEngineering

ProjectPlan

ProjectManager

Vendors

Security

NewBusiness

Contracts

AssociatesManagement CustomerSub-

contractorsInformation

Systems

cott_c11.qxd 6/30/05 3:33 PM Page 182

THE PROJECT TEAM 183

PMBOK ® GuideThe PMBOK® Guide Sec9.1.3.1 Human Resource Plan-ning identifies resource plan-ning output as:

• Roles to be performed.

• Authority needed.

• Responsibilities to be carriedout.

• Competency needed.

PMBOK ® GuideThe PMBOK® Guide Sec 2.3.3Organizational Structure coversalternative matrix managementstructures and the authority ofthe project manager.

and behavior such as being prompt, honest, forthright, communica-tive, alert, self-reliant, trustworthy, and a host of others. We wouldnot want to make up our team of lazy, dishonest, or unproductive in-dividuals. Reference checks and interviews tend to focus on evalua-tion of a person’s attributes. In making reference checks, get thereferred-to person to name yet another qualified reference so thatyou base your judgment on people not directly named by the candi-date. You will be surprised and enlightened by what you learn fromthe second-generation references.

The second factor is the competencies of the individual and howskillful he or she is within the claimed competencies. An individualmay be competent enough to be certified by an authorizing bodyand at the same time have no valuable skills except being able topass evaluation tests. Many people will claim successful past projectperformance when they had little to do with it. In some cases, theyhappened to be on staff to the movers and shakers of the project andare eager to claim the credit for themselves.

Rigorous evaluation against predetermined criteria is valuableto ensure the proper mix of attributes and competencies for eachproject position. The competency model to follow is both a tech-nique and a tool to help make an informed decision. Hiring deci-sions should not be made without one.

DEFINING THE PROJECT MANAGER’S ROLES,RESPONSIBILITIES, AND AUTHORITY

The project manager ’s roles are broad—like those of general man-agers—and range from administration to technical to leadership.2

However, there is a shorter-range focus than that of a line managerwho is responsible for the long-term strength of the organization. Bycontrast, the project manager should be correctly focused on the rel-atively short-term results of the project. In many environments, theproject manager is viewed as the general manager for the projectand, although the project assignment may be for a relatively shortduration, the project manager may also be charged with eternalizingthe project through follow-on and derivative business.

Roles Complications

Manage the project through- Meet an aggressive schedule.out the project cycle.Balance technical, schedule, Managing changing requirementsand cost performance. and implementing emerging

technologies.

A major challenge is to makeboth the customer and theorganization successful byleading the project team.

cott_c11.qxd 6/30/05 3:33 PM Page 183


The project manager musthave total project responsibil-ity and accountability, yetoften has too little authority.

Roles Complications

Solve problems expeditiously Perform within the budget by using as they arise. unlimited funds and resources.Inspire and motivate the Optimize the mix of dedicated,entire team. shared, and contract personnel.

Project management challenges are often exacerbated by an imbal-ance among:

• Responsibility—the duty or obligation to complete a specific actor assignment.

• Authority—the power to exact obedience and make decisions tofulfill specific obligations.

• Accountability—being answerable for success or failure.

Broad responsibilities increase the need for information andforce the project manager to cross organizational lines, which is sim-ilar to a general manager. But without the general manager ’s formalauthority, the project manager (equipped with implied authority)must often depend on interpersonal skills and negotiating abilities toinf luence others.

While the range of the project manager ’s authority varies greatly,effective project management policy should require that:

• The project manager has financial control.• The support managers view the project manager as their customer.• A culture of “make a promise, keep a promise” exists.• Delineation of responsibilities is understood and agreed to.

Before selecting the project manager, the responsibilities needto be determined. They should include responsibility for:

• Establishing the project vocabulary;• Establishing the team and teamwork environment;• Inspiring and motivating the team;• Ensuring all project requirements are defined and that they

f low down to the lowest level;• Leading the planning and managing to the plan;• Pursuing opportunities and managing risk;• Ensuring controls are in place and effective;• Controlling the evolving baseline through a change control system;• Ensuring that visibility techniques are in place and are effective;• Determining the frequency and content of project status re-

views, and• Executing timely action to correct variances from the plan.

The project manager musthave authority for resourcecontrol and must be able tostart and stop work.

cott_c11.qxd 6/30/05 3:33 PM Page 184


PMBOK ® GuideThe PMBOK ® Guide Sec 1.5Areas of Expertise identifiesfive areas of knowledge andskills necessary on the projectteam:

• The PMBOK ® Guide.

• Application area (knowl-edge, standards, and regula-tions pertinent to the projectdomain).

• Understanding of the projectenvironment.

• General management knowl-edge and skills.

• Interpersonal skills.

SELECTING THE PROJECT MANAGER

There are many sources for ideas for a new project. When an ideaseems promising enough to pursue, a project champion is either ap-pointed or someone seizes the opportunity to aggressively evaluatethe opportunity (the user ’s needs and potential return from meet-ing them) and to estimate the resources required to pursue the op-portunity. The champion also evaluates the risks inherent insatisfying the user and other stakeholders. Even on projects that ul-timately involve billions of dollars, the project champion usuallyworks alone, with occasional input from domain experts, to createthe first estimate of the project plan. If it is decided that a studyteam is warranted, the project champion may be the appropriateone to lead the early effort or even the entire study period. At theend of the study period, the project requirements should be ade-quately understood and the project manager for the implementationperiod should be selected. It is unusual for the project champion tocontinue in this role.

Selecting the implementation-period project manager is a criticalmatchmaking task for executive management. In too many cases, theproject manager is selected before the requirements and the organi-zational form of the project are determined. This should be reversedto match the project manager skills with known challenges of the job.

The project manager should be carefully selected because theright choice is critical to project success. The project manager mustfulfill the requirements of the customer or user; must answer to se-nior management by generating a fair return on investment; andmust provide a stimulating, positive work environment for the proj-ect team, while at the same time satisfying personal family obliga-tions and goals.

Our experience reveals that strong leadership can compensatefor insufficient authority. Peters and Waterman report a high corre-lation between project success and the leadership qualities and /ordelegated authority of the project manager.3 In many types of proj-ects, leadership qualities are more important than authority. Butthis should never be taken for granted. It is essential that the projectmanager operates as a manager/leader rather than just as a coordina-tor/monitor and has effective business interrelationships with themanagers supporting the project.

When selecting any team member, it is beneficial to have anobjective basis for evaluating the most critical competency factorsfor the project. This example competency model (Table 11.1) illus-trates only a portion of a comprehensive set of management skills.

The project manager has rolesin three different arenas: thecustomer’s, executivemanagement’s, and theproject team’s.

cott_c11.qxd 6/30/05 3:33 PM Page 185


Table 11.1 Competency Model Excerpt

Rating Factor Weight Score Score ScoreBasic Advanced Expert

Projectmanagementtraining

Has had someprojectmanagementtraining

Has had thecompany's orequivalentprojectmanagementtraining

Has earned thecompany's,PMI, orequivalentcertification inprojectmanagement.*

Projectmanagementexperience

Has served as adeputy orassistant projectmanager

Has been asuccessfulproject manager

Has managedseveralsuccessfulprojects

Contractingandnegotiating

Is knowledge-able of typesand applicationsof relevantcontract types

Has participatedin developingcontractnegotiationstrategies

Has consider-able experiencein contractnegotiationstrategy andparticipating innegotiations

Sub-contracting

Is knowledge-able in thedifferencebetweenpurchasing andsubcontracting

Has participatedin the selectionand award ofsubcontracts

Has successfullymanagedsubcontractors

Decisionanalysis

Is aware of theimportance andpractice ofAnalyticalDecisionProcess†

Has beentrained inAnalyticalDecisionProcess†

Has beentrained androutinelypracticesAnalyticalDecisionProcess†

*PMI (Project Management Institute) certification as a Project Management Professional is based on a comprehensiveexamination.†Analytical Decision Process was originated by Kepner Tregoe Associates (Princeton, New Jersey).

The base structure for most projects is some form of matrix, de-signed to take advantage of critical technical demands, to accommo-date unique management strengths and weaknesses, and to balanceshort-term project priorities with the long-term priorities of thecompany and /or functional organizations. All matrix forms are char-acterized by complex interpersonal relationships requiring that theproject manager be selected more on the basis of behavioral (e.g.,

cott_c11.qxd 6/30/05 3:33 PM Page 186


negotiating and leadership) skills than on technical skills. However,the project manager should be “conversant” in the project domainand cognizant of the systems engineering process. Systems engi-neering experience is very beneficial preparation for the challengesof project management. The person selected must have the rightcombination of attributes and qualifications. “. . . the ideal projectmanager would probably have doctorates in engineering, business,and psychology, with experience at ten different companies in a va-riety of project positions, [yet] be about twenty-five years old.”4 Inaddition to the required skills, the project manager should exhibitthe following capabilities:

• Leadership and team building;• Entrepreneurial and business acumen;• Balance between technical and business capabilities (gener-

alist); and• Planning, organizing, and administration abilities.

Since balance and synergy between business and technical ca-pabilities is critical, some organizations require a program managerto have had experience as a chief systems engineer. Yet, other orga-nizations are having success by installing project managers with abusiness management background strongly supported by a qualifiedsystems engineer to manage the technical development.

CHARTERING THE PROJECT AND CONFIRMINGTHE PROJECT MANAGER’S AUTHORITY

The first step in gaining recognition for a new project and team is toformally charter the project manager and project office. High-levelauthorization of the project’s charter mitigates the historical handi-cap mentioned earlier—project management responsibility withoutcommensurate authority. Harold Kerzner offers this sage advice:“Generally speaking, a project manager should have more authoritythan his responsibility calls for, the exact amount of authority usu-ally depending upon the amount of risk that the project managermust take. The greater the risk, the greater the amount of author-ity.”5 Here again, taking risk really means pursuing opportunity. Thegreater the opportunity, the greater the required authority.

The project manager ’s authority should be documented whenthe project is chartered. The project’s charter, represented by thesample letter shown in Figure 11.2, performs several key functions:

• Identifies the project and its importance to the organization.• Appoints the project manager and other key personnel.

Document the charter and getyour management to sign it.

cott_c11.qxd 6/30/05 3:33 PM Page 187


Figure 11.2 The project team charter.

cott_c11.qxd 6/30/05 3:33 PM Page 188


PMBOK ® GuideThe PMBOK ® Guide Sec 4.1Develop Project Charter coversproject charters, starting withthe Project Statement of Work.

The organization’s cultureshould view the project man-ager as the customer.

While the proper chartering isnecessary for establishing theproject manager’s authority, itis far from sufficient.

For small projects, two orthree roles of the triad may beperformed by the projectmanager.

• Establishes top-level responsibilities and authority.• Positions the support organizations and their authority.• Places subcontractors in a service relationship.• Acknowledges the project team.• Establishes the funding and spending control.• Confirms that the cognizant executive started the project and

chose the manager.

Figure 11.2 sets the tone for teamwork by accepting personal ac-countability for the proposal made by the team. This may seem likean obvious gesture, but even though accountability, unlike authority,can never be delegated, not all senior managers publicly acknowl-edge their accountability for the team’s efforts. Publicizing suchmemoranda is effective.

The project manager ’s authority needs to be confirmed andreaffirmed daily. Authority is a way of thinking that starts by dele-gation at the top and is accepted and seized by the project manager.Continuing authority is based on the project manager earning therespect of the organization through being effective and credible. AsKerzner observes:

Authority can be delegated from one’s superiors. [Personal] power,on the other hand, is granted to an individual by his subordinatesand is a measure of their respect for him. A manager ’s authority is acombination of his power and inf luence such that subordinates,peers, and associates willingly accept his judgment.

In the traditional structure, the power spectrum is realized throughthe hierarchy, whereas in the project structure power comes fromcredibility, expertise, or being a sound decision maker.6

STAFFING THE TEAM

The stages of staffing correspond to the project phases and fundingmilestones, beginning with selection of the core team. We frequentlyrefer to just the project manager when discussing management re-sponsibilities, authority, and accountabilities, but there are threecritical roles of the project office (Figure 11.3).

The systems engineer/technical manager—second only to theproject manager in responsibility and accountability—is responsi-ble for the technical integrity of the project while meeting thecost and performance objectives of project requirements. The sys-tems engineer is a key participant in the planning process and pro-vides technical management of the systems engineering processdirected at achieving the optimum technical solution. To ensure

cott_c11.qxd 6/30/05 3:33 PM Page 189


Figure 11.3 The project office triad.

Project

Management

Business

Management

Domain Specialist Organizations

ManufacturingSystem

Integrationand Test

ProductAssurance

DesignIntegration

Engineering Management

Subsystem A

(end item)

Subsystem B

(end item)

SubsystemC

(end item)

Technical

Management

� Planning

� Cost Management

� Schedule Management

� Contracts Management

� Data Management

� Configuration Management

� Subcontractor Management

� Administrative Management

� Security

� Customer Management

� Executive Management

� Team Management

� Systems Engineering Mgt.

� Requirements Development

� Technical Baseline Mgt

� Requirements Audit

� Interface Management

� Opportunity Management

� Risk Management

� Integrity Management

the appropriate balance between technical and business factors, itis highly desirable to have a systems engineering manager or chiefsystems engineer responsible for:

• Requirements management, analysis, and audit.• Orchestrating technical players in timing and intensity.• Baseline, opportunity, risk, performance, and verification

management.• Interface control.• Design audits.• Understanding and managing to the customer’s perspective.

For small projects the project manager will typically performthe systems engineering function.

The business manager is responsible for all business aspects ofthe project including planning, scheduling, and contractual matters,as well as legal, moral, and ethics issues. The business manager also

cott_c11.qxd 6/30/05 3:33 PM Page 190


Concurrent Engineering is theconcept that all stakeholdersneed to be consideredthroughout the project cyclein order to produce the bestproduct.

assists the project manager in implementing planning, control, visi-bility, statusing, and corrective action systems.

Before personnel staffing selections occur, the required func-tions and related skills should be determined. The nature of theproject will dictate the core team functions, for which the projectmanager should prepare job descriptions. Most job descriptionsshould be based on the task descriptions developed within the WorkBreakdown Structure (WBS). These job descriptions are not onlyimportant in the selection process, but they are the basis of negotia-tions within the matrix structure.

Those who thrive in the project environment will typically beadaptable and interdependent as well as independent and resultsdriven. To paraphrase Stephen Covey, independent thinking alone isnot suited to the interdependent project reality. “Independent peo-ple who do not have the maturity to think and act interdependentlymay be good individual producers, but they won’t be good leaders orteam players.”7

While all team members are selected on the basis of both skillsand personal attributes, it is particularly important that the coreteam have previous project experience, preferably at the task andproject management levels.

As each member is added to the team, it is wise for new mem-bers to define their roles and to have these roles acknowledged bythe rest of the team, beginning with the project manager. Doing thisearly affords the opportunity to make adjustments to create synergyand minimize discord. Until the detailed planning is done, roles andresponsibilities may have to be defined in general terms with laterrefinement consistent with the planning results.

Outsourcing is an increasingly popular alternative to applyingdirect project staff. Subcontractors, vendors, and consultants can bea cost-effective way to fulfill functional capability. However, youshould be just as diligent in selecting external sources as you are inselecting employees, including reference checks, facility tours, andkey person contract clauses.

THE IMPORTANCE OFCONCURRENT ENGINEERING

The project team needs to consider, from the outset, all elements ofthe project cycle. Involving all stakeholders in the development pro-cess is known as Concurrent Engineering (Figure 11.4). For exam-ple, airline pilots should participate in the concept definition of anew plane to properly inf luence the operational aspects of the system.

cott_c11.qxd 6/30/05 3:33 PM Page 191


Figure 11.4 Concurrent engineering fosters stakeholder influence.

Process Development

Product Development

Disposers

Maintainers

Operators

End Users

Marketers/Sellers

Producers

Concepts and

Design-to

Specifications

Verification

Plans

Operating Plans

Concurrent

Requirements

Development

Build-to and

Code-to Artifacts

Production and

Deployment

Processes

Verification and

Operating

Procedures

(Drafts)

Developers

Customers

Concurrent

Product,

Production

Process, and

Deployment

Process

Development

influenced by

life cycle

stakeholders

Concurrent Engineering

Likewise, the baggage handlers should inf luence that part of the de-sign pertinent to their operations. Similarly, recent generations ofcomputer architecture have benefited greatly from having softwareengineers involved in the hardware design. Concurrent engineeringalso promotes simultaneous product and process development to en-sure that efficient producibility is designed in.

Systems engineering is responsible for involving the key person-nel (to address human factors, safety, producibility, inspectibility, re-liability, maintainability, logistics, etc.) in each phase. This does notrequire a dedicated team of specialists. However, it does require aproactive systems engineer who can ensure domain specialists are ap-propriately applied to pursue high value opportunities and their risks.

MANAGING THE MAJOR INTERFACESAND INTERRELATIONSHIPS

The authors of Dynamic Project Management have likened matrixinteractions to those of a marketplace. “Negotiations concerning as-signments, priorities, equipment, facilities, and people are constant.Matrix team members often complain of the continuous meetings,but it is through such meetings that the characteristic decentralizeddecision making occurs.”8

The complex relationships and confusing lines of authority inthe project /functional lattice demands thoughtful planning. As illus-trated in Figure 11.5, the project manager identifies what is to be

Systems engineering mustensure the timely involvementof all disciplines.

INCOSEINCOSE Handbook Sec 5.11covers Concurrent Engineering.

cott_c11.qxd 6/30/05 3:33 PM Page 192


Figure 11.5 Matrix functions chart.

FUNCTIONAL

DefinesHOW

DefinesWHAT

NegotiateWHOWHENHOW MUCH

• Customer• Requirements• Interfaces• Contractors/Subcontractors• Schedule• Cost

Managing FunctionsPROJECT

SUPPORT

Provides:Skills

orProducts

done, primarily by means of work authorizing agreements or MBOsderived from the requirements. The functional organizations are re-sponsible for defining and negotiating with the project manager howthe tasks are to be performed and then implementing them.

Both project- and support-management responsibilities are as-signed by executive management. The project manager ensuresthat project objectives are achieved on schedule and at the lowestcost compatible with user/contractual requirements. The supportmanagers ensure the performance of specific project requirementsas defined and authorized by the project manager. In addition, asthe advocate for technical excellence, each support manager is re-sponsible for:

• Performing for executive management in support of all projects.• Performing as agreed with each project manager.• Maintaining personnel expertise consistent with emerging tech-

nology and industry best practices.• Recommending creative ways to meet project objectives.• Providing function’s cost, schedule, and technical opportunity

and risk assessment.

cott_c11.qxd 6/30/05 3:33 PM Page 193


Teams rarely go wrong bythemselves—more often theysuffer from lack of directionand false assumptions.

• Assigning skilled personnel to support projects.• Actively participating in problem solving and conf lict resolution.• Correcting deficiencies in performance.

One of the most significant techniques for minimizing confu-sion and avoiding excessive interaction is to clarify roles and re-sponsibilities where conf lict in authority and function are likely totake place. The critical areas of potential conf lict that should beresolved are:

• Project direction, objectives, priorities, planning, reviews, sta-tus, and controls.

• Assuring project effectiveness and customer commitments.• Proposal preparation, contract negotiations, and contract man-

agement status.• Technical, schedule, budget, and make versus buy decisions.• Assignment of key personnel and establishment of employee

objectives.• Communications, correspondence, and data requirements.• Point of contact for customer, upper management, and support

interfaces.

A technique for managing any form of matrix organization isthe Project Work Authorizing Agreement (PWAA) or an equivalentmethod for authorizing work. The PWAA is a contract between theproject office and the supporting organizations. As illustrated inthe next chapter on planning, it contains task definition, budget,schedule, performer’s commitment, and project office authoriza-tion (Figure 11.6). Companies or organizations that have a formal,quantified, and measurable MBO program can make use of thatsystem to supplement, or in the case of simple projects, substitutefor the more definitive PWAA. These methods are addressed inChapters 12 and 16.

These are common expectations of executive management, thecustomer, and the team members:

• Timely, accurate information—for teams to work well, informa-tion and ideas have to f low smoothly.

• No surprises—for cooperation to grow, communication must becomplete and candid. There is no place on a project team for aproblem withholder.

• Credit given where credit deserved—the rewards must matchthe risks and recognition given for both individual and teamefforts.

cott_c11.qxd 6/30/05 3:33 PM Page 194


Figure 11.6 The buyer/seller viewpoints.

Contractors

Customer Executive Management

You

SupportOrganizations

Buyer wantsdelivery as promised

Seller wants fair deal


Seller wants supportas requested

Seller wants fair deal


PROJECT TEAM EXERCISE

The objective of this exercise is to provide experience in identifyingthe issues facing a project manager in staffing a project.

You are the project manager for a project your company is bid-ding and, if successful, it will position you and your company for sig-nificant growth. Unfortunately, the last similar project was poorlystaffed and the delivered product required extensive rework beforebeing acceptable to the customer. Your company’s reputation hassuffered and management is concerned about a repeat.

You have been asked to prepare a staffing plan. The project ispredicted to last 18 months, and will require the equivalent of tenfull-time people although actual head count will vary, beginningwith just a few key designers, expanding to a larger staff of develop-ment people, testers, and so on, and then tailing off to key engineer-ing staff during final testing and delivery. All staff will report to youfor the duration of the project and will be collocated in your facility.

What information should you develop to guide your staffing plan?

Matrix operations depend ontheir project manager beingviewed as a buyer of servicesprovided by the supportmanagers.

cott_c11.qxd 6/30/05 3:33 PM Page 195

196

ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

Control

Pro

ject

Sta

tus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadership

ProjectVisibility

ManagementElement 4

12PROJECT PLANNING

“It is a bad plan that admits ofno modification.”

Publilius Syrus

Planning must reflect the tactics selected to achieve theproject’s strategic objectives including the integrationsequence of the various system entities. The infamous DenverAirport construction project failed to do this and suffered hugeoverruns and schedule delays as a result. Even thoughbaggage handling is a key part of any airport, the DenverAirport state-of-the-art baggage handling system was anafterthought not factored into the concept, the architecture, orthe operating scenarios. As a result, the baggage system hadto be designed and installed within the inadequate physicalconstraints of existing designs and operations already underconstruction. Furthermore, the constraints also prohibited aneffective backup system. Unfortunately, the approved DenverAirport plan was never rebaselined to accommodate the add-on baggage handling capability as it should have been. As aresult, the costs soared from $1.7 billion to more than $4.8billion, a 200 percent overrun, and the operational readinesswas delayed 16 months.

PMBOK ® GuideThis chapter is consistent withthe PMBOK ® Guide Ch 5 Proj-ect Scope Management, Ch 6Project Time Management, Ch7 Project Cost Management

INCOSEThis chapter is consistent withINCOSE Handbook Sec 5.2Planning Process.

PLAN THE WORK AND WORK THE PLAN

We define planning as the process that determines beforehand thetasks necessary to complete the project. Planning continues andthe plan evolves as the project progresses through the phases of theproject cycle. A plan contains at least:

• What is to be done.• When it should be done.• Who is responsible for doing it.

A complete plan adds physical and financial resource profiles.

Planning is performed in eachproject-cycle phase to preparefor the subsequent phases.

Project planning is an iterativeprocess on several levels, aswell as an ongoing one.

cott_c12.qxd 7/1/05 3:53 PM Page 196

Figure 12.1 The total project plan consists of multiple plans.

PROJECT PLANNING 197

At the highest total project level, planning is performed in eachproject-cycle phase to prepare for the subsequent phases. The low-est level of iteration occurs within each activity—such as iteratingthrough network development and task schedules to determine andshorten the critical path. While the emphasis, level of detail, andopportunity and risk factors change from one phase to the next, theprocess that follows is relevant to every project phase.

Project planning and statusing are directly related to eachother and inextricably linked. You select the status methods beforeplanning, since the planning needs to support and relate to thestatusing method and its intended granularity. For example, tobenefit fully from the power of earned value, tasks need to be de-fined in sufficient detail to minimize the need to judge percentcomplete. The preferred method is to establish interim milestoneswith related percentages. For instance, a report might earn 10 per-cent for the outline, 30 percent for the first draft, 10 percent forred team review, 30 percent to incorporate improvements, and 20percent to produce the final version. We address earned value inChapter 16.

The project plan (Figure 12.1) is usually composed of a set ofspecialty plans. Some plans, such as the acquisition plan and thesource selection plan, apply only to projects that need to evaluateand select competitive suppliers. The implementation plan for solu-tion development is common to all development projects and will

Many experts see earnedvalue as a planning techniqueas well as a method to statusthe project.

cott_c12.qxd 7/1/05 3:53 PM Page 197


be used throughout this chapter to illustrate the overall planningprocess.

IMPLEMENTATION PLANNING: CONVERTING THEPROJECT REQUIREMENTS INTO ORDERLY WORK

We define implementation planning as the process of converting allproject requirements into a logically sequenced set of negotiatedwork authorizing agreements (Figure 12.2) and subcontracts.

Project Work Authorizing Agreements are internal contractscontaining:

• Task description.• Schedule for deliverables.• Time-phased budgets.• Agreement by the implementer.• Agreement by the project manager.

Figure 12.2 The project work authorizing agreement (PWAA).

cott_c12.qxd 7/1/05 3:53 PM Page 198


Subcontracts are external contracts containing all of the previ-ous items plus:

• Contract terms and conditions.• Legal authority to perform.• Conditions for default.

THE PLANNING PROCESS:SIMULATING THE PROJECT

Figure 12.3 shows an overview of the plan development objectivesand process, highlighting the role of the project manager in integrat-ing the customer’s objectives with those of the enterprise’s manage-ment. It emphasizes a major reason projects fail: insufficient teaminteraction. Productive interaction helps motivate and commit theteam. But it has to be a meaningful interactive process. The mostdifficult project objectives offer the best team brainstorming oppor-tunities. When the team members resolve strategies and tactics toachieve their objectives and develop the plan, their investment sky-rockets—they become committed to implementing “their” plan.

A significant contributor to poor planning is lack of a systematicand structured process. As emphasized in Chapter 2, to test for asensible plan it is important to be able to envision it—to be able to

Implementation planning isdriven by the project’sobjectives, the need tocommunicate, and the need to obtain agreements andcommitments.

Figure 12.3 Planning objectives, process, and drivers.

CustomerObjectives

TeamInteraction

Objectives• How to do the project – project strategy• What tasks are required• When the tasks are required• What the task inputs and outputs are• Who will do the tasks• The team/task interrelationships• What is the critical path• How the risks will be managed• What critical actions are required• What control systems will be used

Process• Define project deliverables and milestones• Define intermediate deliverables and milestones• Define the work tasks to produce all deliverables• Sequence and link the tasks into the project network• Identify the critical path• Define and evaluate the risks• Develop risk management tasks and link to network• Develop schedules and establish contingencies• Re-evaluate the critical path• Plan the physical resources• Plan the personnel resources• Calculate the required budget and establish reserves• Iterate as required• Obtain agreement and commitment• Authorize the work

ManagementObjectives

ProjectObjectives

ImplementationPlan

TeamCommitment

cott_c12.qxd 7/1/05 3:53 PM Page 199


Key Element Process Primary Technique

Products Decomposing deliverables into their hierarchical(architecture) structure—from senior most down tothe lowest level internal and external deliverables.

Project Product List and FactSheets

Developmentstrategy andtactics

Determining the development strategy and tacticssuch as fast time to market and unified, incremental,linear, and/or evolutionary development with eithersingle or multiple deliveries.

Application of the “Veemodel”

Opportunityand risktactics

Identifying opportunities and associated risks and thecustomer-compatible opportunity and risk actionswith preventive, causative, and contingent actionplans.

Lessons Learned

Tasks Defining the tasks needed to develop eachdeliverable.

Work Breakdown Structure

Network Logically arranging the interactive tasks to portraythe best value development and delivery approach.

Cards-on-the-wall network,followed by a computerizednetwork and critical pathdetermination and analysis

Commitments Committing the necessary resources and funds tocarry out the plan.

Project Work AuthorizingAgreements

Resources Defining resources (personnel, equipment, finances)needed to accomplish each task on schedule.

Spread sheets and costestimating models

Schedules Scheduling each task according to the calendar andresource availability and then refining and shorteningthe critical path where possible and meaningful.

Scheduling software

Table 12.1 The Planning Process: Major Elements and Techniques

decompose it into deliverables and then to simulate the f low ofthe work in a visual walk-through. Our planning process steps con-verge on a cards-on-the-wall (COW) networking technique thatprovides this visualization. The main process elements are listed inTable 12.1.

This approach, shown as a f lowchart in Figure 12.4, offers a sys-tematic way to transform the project activities into a baseline plansuitable for both proactive and reactive management. In the re-mainder of the planning section, we will address each f lowchart ele-ment in detail.

The goal of planning parrots the project goal: to ensure that allcommitments to the customer are met. To get there, we start the

cott_c12.qxd 7/1/05 3:53 PM Page 200

201

Figure 12.4 The planning process: From problem solving to commitment.

ProjectRequirements Lessons

Learned

Management

Cost

TechnicalProposal

Project Products List

PPL FactSheet

Organization

Standards BestPractices

Project Plans and Updates

Config. Management PlanContingency PlanDeployment PlanFacilities PlanInterface Control PlanMaintainability PlanMake or Buy PlanManpower PlanManufacturing PlanOperations PlanPiece Parts Plan

Procurement PlanProject Management PlanQuality PlanReliability PlanRisk Management PlanOpportunity Mgt. PlanSafety PlanSoftware PlanSpares PlanSystem Engineering Mgt. PlanVerification PlanMaster Schedule (High level)

Work BreakdownStructure0

1.0 2.0 3.0 4.0 5.0

1.1

3.3

3.2

3.12.1

2.21.2

WBS Dictionary

Task 1Task 2Task 3Task 4 Updated Task/

Responsibility Matrix

Task

1.1

1.2

2.1

2.2

Eng

inee

ring

Man

ufac

turi

ngS

yste

m I

nteg

ratio

nTe

st

Fina

nce

Con

trac

ts

R = ResponsibleS = Support

S S S S S R

R S S S

S R S S S

S

S

S R

Network Development - COW

• Critical Path Analysis• Computerized Project Network

• Computerized Project Network• Critical Path Determination

and AnalysisDetailed Task Planning

Detailed Schedules

SOTJEC

WP No. 1WP No. 2WP No. 3

OtherMaterial

Labor

ManagementReserve Plan

UpdatedTask

Estimates

Project Manager – Task ManagerNegotiations

Project Initiation Review (PIR)

Subcontracts

Project WorkAuthorizingAgreements

Task

Sched

Budget

Approved Accepted

J F M A M J-- -- -- -- -- --

Ready forRelease

cott_c12.qxd 7/1/05 3:53 PM Page 201


The Project Products List andFact Sheets are techniquesthat facilitate this step.

planning with the project requirements that include the Statementof Work (SOW), the milestone schedule (Master Schedule), cost tar-gets, and definition of all deliverables. The Master Schedule identi-fies the overall start and stop dates and all major milestones.

DETERMINING THE PROJECT DELIVERABLES

One of the first planning steps is to determine all of the project de-liverables and to provide a narrative description of each. The Proj-ect Products List (PPL) is derived from the decomposition anddefinition of the system and is a list of all external deliverables andinternal deliverables, in all forms produced, with the quantities re-quired. Examples of the different forms of products that could beproduced are:

• Drafts.• Simulations.• Models (user requirements understanding, technical feasibility,

physical fit, field test, preproduction, etc.).• Qualification units.• Deliverables.• Spares.

An example of a hardware PPL and a software PPL are shown inFigure 12.5. Other PPLs would include support equipment, docu-mentation, and services.

A Project Product List Fact Sheet should accompany each PPL(Figure 12.6). Its purpose is to provide a description and expecteduse for each item. It is usually written by the most knowledgeableexpert available, whether he or she is to work on the project or not.The fact sheets are used by project participants to plan and esti-mate labor and material for each deliverable to facilitate costingand pricing.

DEFINING THE WORK BREAKDOWNSTRUCTURE AND THE TASKS

The WBS for development projects is best depicted as the systemarchitecture consisting of system, subsystems, and compon-ents rather than by discipline or functional organization (such as en-gineering, manufacturing, test, etc.). The WBS is representedgraphically or in an indented list (Figure 12.7) and illustrates theway the project will be integrated, assigned, and statused. The WBS

As the keystone of the plan,the WBS depicts the projectdecomposition and the associ-ated tasks.

cott_c12.qxd 7/1/05 3:53 PM Page 202

203

Figure 12.5 Project product list (PPL) examples.

LEGENDPROJECT

PRODUCTSLIST

Software

STATUS PRODUCT LEVELDate

Revision

Page

N - NewM - ModifiedE - Existing

CSCI – Computer SoftwareConfiguration Item

CSC – Computer SoftwareComponent

WBS NO.

SUBSYSTEM

WORK PKG NO.

NOMENCLATURE MNEMONIC REMARKS

PRODUCT LEVEL VERSION IDENTIFIER STATUS(N, M, E)

CI CSC Use

r R

qmt’s

Mod

el

–01

–02

MA

KE

(M

)O

R B

UY

(B

)

SO

FT

W.

DE

SIG

N

PR

OG

R.

CO

DIN

G

ES

T. L

INE

SO

F C

OD

E

SE

CU

RIT

YC

LAS

SIF

.

June 121.3.7.1

Data Compression

RDMS

WRIT

GRAF

DICT

X

X

X

X

X M

M

B

M

M

N

N

N

N

N

N

N

Uncl

Uncl

Uncl

Uncl

125K

87K

42K

65K

Data Base Core

Report Writer

Graphics

Dictionary

Convert to Ada

Tech

nica

lF

easi

bilit

y M

dl

X

X

X

X X

X

Propulsion Module (10.01.02 .19)

Propellant Tank (10.01.02.07)

Reaction Engine Module (10.01.02.06)

Latching Solenoid Valve (11.01.02.11)

Service Valve (11.01.02.11)

PR XDucer (11.01.02.15)

Filter (11.01.02.10)

Itemno

Nomenclature andWBS Number

Drawing Number(or similar to)

8160485 - X (2P64002)

8160481 -X(2P64000 - 13)

2P60481 - 3 orequivalent

2P60483 - X

8111210 - X

8103465 - 15

1

2

3

4

5

6

7

StatusQuantity Per Contract

Category Remarks

Assemble, Install& Test

Spherical VersionOf 2P64002(cylindrical)RRC Intelsat V0.5 LBF ThrusterMounted In PairsOn An REM

Modify ToIncreaseShielding For NewRadiationEnvironment

M N N 1 2

B M N 2 1 2 4 1

B M N

B E N

B E N

B M N

B E N

2322211614

18414

1633

1 184114

1844

ProjectProducts

List

Propulsion System Dual TankConfiguration

(WBS 11.01.02)

Title:

Project Office Approval

Name:

LegendStatus “Category”

Date

Revision

Page Of1 2

Recommendation

Des Hdwe

Organ No.

TF PF TS SI FT Q DV F S

N = New

M = Modified

E = Existing

Also support equipmentAlso documentation

Also services

Make

TF – Technical Feasibility ModelPF – Physical Fit ModelTS – Thermal Simulation ModelSI – System Integration ModelFT – Field Test ModelQ – Qualification UnitDV – Development VehicleF – FlightS – Spares

Also software

or buy

1.3.7.1.0 1

1.2

cott_c12.qxd 7/1/05 3:53 PM Page 203


Figure 12.6 PPL fact sheet example.

is critical to project planning because it is the basis for work assign-ments, budgeting, scheduling, risk assessment, cost collection, andperformance statusing.

Figure 12.8 illustrates how the WBS relates the work requiredto produce the individual components (from the Product Break-down Structure) to the work required to integrate those componentsinto the system.

The WBS has been successfully employed by government agen-cies such as the Department of Defense (DoD) and NASA for manyyears and is now a standard planning technique for projects of allkinds. The Project Management Institute’s Practice Standard forWork Breakdown Structures is a guide to the development of an ap-propriate WBS. Both product and service WBS forms are coveredby the standard.1

For government projects, the Request for Proposal usually pro-vides a top-level WBS that the project’s WBS must interface with.MIL-STD-881A (former DoD WBS standard) embodies WBS re-quirements as well as examples. It accurately states that the WBSprovides a system management structure for:

Figure 12.7 The work breakdown structure (WBS).

cott_c12.qxd 7/1/05 3:53 PM Page 204

205

Fig

ure

12.8

Th

e w

ork

bre

akd

ow

n s

tru

ctu

re r

ela

ted

to

th

e s

yste

m a

nd

pro

du

ct

bre

akd

ow

n s

tru

ctu

re.

Co

mp

on

ent

CC

om

po

nen

tB

Co

m-

po

nen

tA

Co

m-

po

nen

tB

Co

m-

po

nen

tC

Co

m-

po

nen

tD

Des

ign

Fa

bA

ssem

ble

Te

st

Tra

inin

gT

es

tD

ata

Mg

mt.

Sys

tem

En

gin

eeri

ng

Pro

ject

Man

agem

ent

Co

mp

on

ent

A

Co

mp

on

ent

D

Sys

tem

Com

pone

nts

held

toge

ther

by in

tegr

atio

n

Wor

k to

pro

duce

the

indi

vidu

alsy

stem

com

pone

nts

Pro

du

ct B

reak

do

wn

Str

uct

ure

The

com

pone

nts

that

form

the

syst

em

Wo

rk B

reak

do

wn

Str

uct

ure

(W

BS

)W

ork

to p

rodu

ce t

he s

yste

m

Wor

k to

inte

grat

eth

e co

mpo

nent

sin

to a

sys

tem

cott_c12.qxd 7/1/05 3:53 PM Page 205


Figure 12.9 Hardware and software WBS examples.

MessageProcessor

Test

IntegratedMessage Set

Program

1.0

Receiver

2.0

MessageProcessorTransmitter

4.0

ProjectManagement

ProjectManagement

ProjectReviews

ConfigurationManagement

QualityAssurance

4.1

4.2

4.3

4.4

5.0

SystemEngineering

SpecificationDevelopment

InterfaceControl

Audit &Verification

5.1

5.2

5.3

SystemTest

6.0

SystemTest

6.11.1

Material

Fab

Insp

Design1.1.1

1.1.2

1.1.3

1.1.4Test1.1.5

SignalProcessor

1.2

Material

Fab

Insp

Design1.2.1

1.2.2

1.2.3

1.2.4

Test1.2.5

Antenna

1.3

Material

Fab

Insp

Design1.3.1

1.3.2

1.3.3

1.3.4Test1.3.5

FinalAmplifier

TransmitterTest

2.1

Material

Fab

Insp

Design2.1.1

2.1.2

2.1.3

2.1.4

Test2.1.5

SignalProcessor

2.2

Material

Fab

Insp

Design2.2.1

2.2.2

2.2.3

2.2.4Test2.2.5

Antenna

2.3

Material

Fab

Insp

Design2.3.1

2.3.2

2.3.3

2.3.4Test2.3.5

Low-NoiseAmplifier

ReceiverTest

3.1

Material

Fab

Insp

Design3.1.1

3.1.2

3.1.3

3.1.4Test3.1.5

DataProcessor

3.2

Material

Fab

Insp

Design3.2.1

3.2.2

3.2.3

3.2.4

Test3.2.5

VoiceProcessor

3.3

Material

Fab

Insp

Design3.3.1

3.3.2

3.3.3

3.3.4

Test3.3.5

Converter

1.4 2.4

3.0

3.4

Space TelescopeScience Support Module

1.4

Software1.4.7

Operating SystemSoftware

1.4.7.2

MissionSoftware

1.4.7.3

FlightSoftware

1.4.7.1

Navigation SW1.4.7.1.1

Motor Control SW1.4.7.1.2

Telemetry SW1.4.7.1.9

I/O System1.4.7.2.1

Logic1.4.7.2.2

ALU1.4.7.2.13

Main Mirror1.4.7.3.1

Primary I/R1.4.7.3.2

1.4.7.2.13.1 PDA1.4.7.2.13.4 Test1.4.7.2.13.5 Integration1.4.7.2.13.6 SCWP

Instrument Controller1.4.7.3.7

1.4.7.1.9.1 PDA1.4.7.1.9.2 Detailed Design1.4.7.1.9.3 Coding1.4.7.1.9.4 Test1.4.7.1.9.5 Integration

1.4.7.3.7.1 PDA1.4.7.3.7.2 Detailed Design1.4.7.3.7.3 Coding1.4.7.3.7.4 Test1.4.7.3.7.5 Integration

Key:PDA — Preliminary Design & AnalysisSCWP — Subcontract Work Package

Software WBS Example

Hardware WBS Example

System decomposition BudgetingSpecifications and drawings SchedulingConfiguration management Responsibility

The guidelines in Figure 12.9 ref lect our experience in refiningthis planning technique:

• For development projects structure the WBS by product and el-ements of the product.

• For service projects and for the study and operations periodsstructure the WBS by functional disciplines.

• Include all authorized tasks.

cott_c12.qxd 7/1/05 3:53 PM Page 206


• Cost collection is usually one level below budget performancereporting to facilitate problem cause identification.

• Identifiers for like tasksshouldbesimilar.Example: x.x.x.4Material.• All tasks for an element should be collected with the element

identifier.• WBS depth (number of levels) depends on the risk to be man-

aged and reported.• Level-of-effort tasks are usually at the second level, which may

include project management, systems engineering, system inte-gration, and system-level testing.

• The product level should consist of entity nouns and the tasklevel should apply verbs such as design, fabricate code, assem-ble, and test.

The WBS is supported by the WBS dictionary, which links theWBS elements to the task definition—work packages. As Figure 12.10shows, the WBS dictionary is a narrative description of each worktask identified in the WBS. The descriptions drive the task estimatingand are the basis of task assignments.

The work package contains a complete task description, includ-ing what, when, how, by whom, and also includes the budget andschedule allocations. It may incorporate the WBS dictionary entryor reference it. The work package represents another important linkin the planning—the connection between the WBS and the func-tional organization or contractor assigned to the task, which is ac-complished by the Work Authorization Agreement.

WBS TASKS AND THE PROJECT DASHBOARD

The establishment of WBS tasks determines the instruments of theproject’s dashboard. For each task there should be an associated bud-get and work accomplishment plan. Then, as work is accomplishedand labor charges are accumulated against the task, the expenditurescompared to the budget (fuel gauge) will become apparent as well as

A work package is preparedfor each element at its lowestlevel in the WBS.

Figure 12.10 WBS dictionary excerpt.

Component Test

This task consists of preparing test procedures, test facility, testpersonnel, and test conduct including documentation andresolution of all test discrepancies. The output from the task is asatisfactorily completed test, resolution of all test anomalies, andthe final test report.

cott_c12.qxd 7/1/05 3:53 PM Page 207


PMBOK ® GuidePMBOK ® Guide Sec 6.2.2Activity Sequencing identifiesthree types of dependencies:

1. Mandatory (those inherentin the nature of the work).

2. Discretionary (also knownas preferred logic, prefer-ential logic, or soft logicbased on best practices).

3. External (relationshipsbetween project and non-project activities).

the progress of accomplishments as compared to the milestone planfor the task (odometer). A well-managed project will have these in-struments for all significant tasks and the project manager will drivethe project in accordance with their readouts.

DEVELOPING THE PROJECTNETWORK AND SCHEDULES

There are three types of schedules to resolve: deliverable accom-plishment, personnel, and budget. This section deals primarily withdeliverable schedules, bounded by the required start and stop datesfor each task. They form the basis for the other supporting sched-ules. Personnel schedules identify the timing for required personnelinvolvement and facilitate resource planning. Cost schedules definethe allocation and spending for each task as a function of time. Theirprimary purpose is to facilitate funding management.

Scheduling usually involves more iterations than any other func-tion in the planning process. This is mainly due to the trade-offs thatmust be made among the constraints of time, cost, technical re-quirements, available personnel, and risk. Another complicating fac-tor is that all task interdependencies may not be obvious whenscheduling is developed at the task level.

The WBS tasks are the foundation for the project network andschedule as shown in Figure 12.11.

The scheduling process iterates through these steps:

• Link the tasks to form a project network.• Identify opportunities for project improvement.• Identify and evaluate risks.• Develop opportunity and risk management actions and add to

the network.• Factor in task duration times.• Determine the critical path.• Shorten the critical path.• Commit to meeting the task schedules.

Historically, there have been two principal methods for con-structing network diagrams, the Program Evaluation and ReviewTechnique (PERT) and the Critical Path Method (CPM). In theirvery basic but easy-to-use book, the Bakers characterize these meth-ods as follows:

PERT and CPM emerged in different ways in the late 1950s. PERTwas developed by Lockheed and Booz, Allen, and Hamilton for the

PMBOK ® GuidePMBOK ® Guide Sec 6.5.2.6The Critical Chain Method, dis-cusses this technique whichaccounts for the effect ofresource availability.

cott_c12.qxd 7/1/05 3:53 PM Page 208


U.S. Navy Special Projects Office. The CPM was developed atabout the same time by Morgan Walker and James Kelly for E.I. DuPont. . . . (The primary difference is in the way the two techniquestreat time estimates for tasks.) . . . [T]he networks are largely thesame in terms of sequencing possibilities. In CPM, one time esti-mate is used for creating the schedule; PERT uses a more analyticalsystem based on three time estimates that are used to determine themost probable time for completion.2

The distinction is that the PERT network allows a three-point esti-mate for the duration of each task (nominal, earliest completion, andlatest completion). With the three-point estimates you can performMonte Carlo simulations for the network and determine the nomi-nally expected completion date (the output of the CPM), the proba-bility of achieving that date, and the date for 95 percent or 99percent probability of completion. The widespread availability ofhigh-speed, high-capacity desktop computers makes this processreadily available and potentially useful to the project team. Mi-crosoft Excel can perform Monte Carlo simulations.

Figure 12.11 The WBS tasks are the foundation for the project network and schedule.

Project

Subsystem A

Assembly A1

DesignA12

BuildA12

TestA12

Assembly A2

DesignA2

BuildA2

TestA2

Subsystem B

CS Compo-nent B1

DesignB1

CodeB1

TestB1

DesignA1

BuildA1

TestA1

DesignA2

BuildA2

TestA2

DesignB1

CodeB1

TestB1

StartFinish

SubAssyA11

SubAssyA13

≈ ≈

≈ ≈

SubAssyA12

Technically, the COW tech-nique result is similar toPERT/CPM, but the process ismuch more visual and inter-active, leading to more reliableschedules.

cott_c12.qxd 7/1/05 3:53 PM Page 209


Figure 12.12 The cards-on-the-wall (COW) method.

CDR PRRPDR

Estimated Duration:

Output

Task Planning Form WBS No:

Task ID:Task Name:

Minutes Hours Days Weeks Months

Form Preparation Date:Task Manager:Form Prepared By:Constraint, Start: Finish:

Input

1.

From:

2.

From:

3.

From:

1.

To:

2.

To:

3.

To:

Task Description

Resource Requirements:

Circle one

Yarn Project Planning Forms

Computer-based PERT or CPM affords very limited opportuni-ties for team interaction during network construction. Computer-based network construction, regardless of the specific software, isusually built from work packages and input by a single person work-ing alone at the keyboard and viewing the resulting network on thecomputer screen. The problem with using a computer at this earlystage is that the team is not creating the network. We prefer a moreinteractive network diagramming technique that begins with amethod we have dubbed cards-on-the-wall (COW). In this method,the team literally hangs each work package on the wall, by projectphase, and interconnects them using markers or yarn to ref lect theinterdependencies (Figure 12.12). We prefer the wall as a workspace because it allows the team to cluster in areas of interest of theevolving network to discuss the logic. We use “wetware” (the brainsof the team) for creating the network and software for capturingthat network and computing the critical path. We’ve devised a form

cott_c12.qxd 7/1/05 3:53 PM Page 210


The critical path paces theproject schedule.

for creating the network, as shown on a section of the network wallin Figure 12.12.

Our COW technique uses:

• A 5″ × 8″ project planning form for each task,• Yarn or string for interconnecting the cards, and• Ample walls to hang and arrange the cards.

The COW technique consists of interconnecting the tasks (cards)to ref lect the optimum order of tasks and their interdependencies.Among the benefits of this interactive, visual procedure are:

• Participative decision making.• Fewer “I forgots.”• Shared risks.• Shared concessions.• Quality results.• And most important: team ownership of the plan.

In a recent planning session, someone commented that it was ashame that the walls weren’t magnetic. “But they are,” said theleader, looking at the cluster of people over at the wall discussinghow to shorten a link in a critical path, “they have animal magnet-ism.” We’ve never seen people crowd around a computer terminaltalking about how to reorder tasks, but we’ve seen lots of groupscluster around a wall draped with cards and yarn, arranging “logic”to make an impossible schedule feasible.

Schedules at the task level usually employ a linear formator bar chart such as the Gantt chart. Figure 12.13 shows the rela-tionship between the project network and the task schedules. Barcharts that include task interconnects are often called time phasednetworks. This is the most effective form for day-to-day projectmanagement.

The next step after network construction is determining thecritical path—the task sequence that paces the project. When askedto identify his project’s critical path, one rather defensive projectmanager we encountered asserted, “This project has no criticalpath, if it does, we will eliminate it.”

We define the critical path as the sequence of project activitiesfor which there is minimum or zero slack. The critical path for a va-cation preparation is shown in bold in Figure 12.14. For conve-nience, we talk of “the” critical path. In fact, there may be severalcritical paths, and there are frequently many other “near-critical”paths. The following discussion applies to all of these situations.

PMBOK ® GuidePMBOK® Guide Sec 6.2 Activ-ity Sequencing covers thePrecedence DiagrammingMethod (PDM) described hereand also the Arrow Diagram-ming Method (ADM) in whichactivities are shown on thearrows connecting activitydependency junctions.

cott_c12.qxd 7/1/05 3:53 PM Page 211


After adding contingency spans and opportunity and risk man-agement tasks, the critical path needs to be reevaluated. Analyzingresource requirements for concurrent activities and using the criti-cal path as the time scale will usually reveal suboptimal lumping ofpersonnel resources (the critical chain). At the same time these tasksare being considered for resource leveling or smoothing, the follow-ing actions to reduce the critical path should be considered:

• Eliminate or shorten tasks on the critical path.• Replan serial paths to be parallel.• Overlap sequential tasks.

Figure 12.13 Schedule development: The relationship between the project network and the task schedules.

cott_c12.qxd 7/1/05 3:53 PM Page 212


Figure 12.14 Critical path example: Vacation preparation.

• Increase the number of workdays or work hours.• Shorten tasks; the best candidates are those:

—That are long, or easy, to speed up.—For which you have available resources.—That cost the least to speed up.—That your organization controls.

Actions taken to shorten the critical path usually have other im-pacts. Using the vacation preparation example (Figure 12.14), thecritical path could be shortened by having the hitch installed whilethe car is being fixed, or you could rent a car to pick up supplieswhile the car is being repaired. In the first case, if the car is havingthe fuel injection system repaired, the mechanic may not have theskill to install the hitch, hence a risk would be added. In the secondcase, renting a car adds cost. You could also have your friends pickup the supplies (add project resources) or, as one student proposed,you could go on vacation without your friends (change require-ments). In each case you must ask yourself, “Is it worth it to shortenthe schedule?”

Sometimes risk reductions and critical path reductions are syn-ergistic. You can expect to move lower-risk tasks off the criticalpath, which can contribute needed resources to the higher-risktasks, thereby reducing the critical path and /or the risk. The opti-mum balance is achieved when both sets of tasks end up on the new,shorter critical path.

Next, resource leveling and optimization can be performed.These steps can be performed with the help of computers once the

Each action to shorten the crit-ical path should be justified.

cott_c12.qxd 7/1/05 3:53 PM Page 213


Figure 12.15 Schedule compression/expansion effects.

4

3

2

1

1.0 2.0 3.0Actual Time

Optimal Time

InefficientUse of

Resources

HighCosts toShorten

Schedule

Act

ual N

umbe

r of

Peo

ple

Opt

imal

Num

ber

of P

eopl

e

network is constructed. However, resource restrictions or problemsare usually localized, and good judgment and common sense willproduce meaningful results. Reducing the critical path and optimiz-ing resource allocation can significantly affect a task’s cost as illus-trated graphically. Shortening a task schedule below the optimumpoint can lead to an increase in its cost (Figure 12.15). On the otherhand, optimization at the network level may consist of offsetting arelatively small increase in task cost with a significant savings at theproject level. For example, the incremental cost associated withcompressing one task may result in equivalent burn rate savings forthe total project.

PLANNING THE RESOURCES

While this section focuses on the two limiting resources in mostprojects, personnel and funds, a unique physical resource can alsoimpact the schedule. Take nothing for granted. Just when you need aspecial piece of test equipment that hasn’t been used for six months,you can be sure Murphy will need it too. And Murphy’s team re-served the equipment when they planned their project much earlier.Another property issue to plan for in government projects is the use

PMBOK ® GuidePMBOK® Guide Sec 6.3 Activ-ity Resource Estimating andCh 7 Project Cost Managementprovide additional informationon estimating and costing theplanned work.

cott_c12.qxd 7/1/05 3:53 PM Page 214


of Government Furnished Equipment, Services, and Material (gen-erally called GFE). First, contractual commitments must be negoti-ated for the GFE delivery dates. Second, permission must begranted by the government agency that owns the equipment (or ser-vices or material) that authorizes use of the material on your proj-ect. In one instance, one of the authors won a contract that involvedmanufacturing of components on special equipment owned by theU.S. Army. Unfortunately, prior permission for the use of the equip-ment had not been obtained. When asked for permission to use themachinery, the Army project office said, “Of course. What is theArmy project number?” Answer: “It is a U.S. Air Force contract.”Response: “Air Force? What Air Force? We don’t have an Air Force.Permission denied.” Incomplete planning and preparation almost al-ways lead to a bad outcome.

To illustrate the time-phased resource requirements at the task,personnel category, and total project levels, Gantt charts are useful.They are derived from the PERT/CPM network, but use a conven-tional time scale, which may be more easily understood by the team.Having already adjusted tasks to smooth resource requirements, en-hance opportunities, or reduce risks and /or the critical path, thenext step is to return to the task level and define the personnel as-signments and schedules.

The WBS is the basis for identifying task responsibilities (Fig-ure 12.16). As a checklist, the Task Responsibility Matrix (Figure12.17) is useful in summarizing which personnel and organizationshave been assigned primary and support responsibilities for eachtask, and who will participate in the COW process. Figure 12.18 isan example of a planning form that extracts the monthly personnelneeds from the task Gantt chart at the functional organization leveland combines them with other resource requirements.

ESTIMATING, COSTING, AND PRICING

An essential part of planning is calculating the most probable cost tocomplete the project and then determining the market price. Thisprocess is often called cost estimating, but is more accurately de-scribed as estimating, costing, and pricing because each is a distinctprocess and is usually performed by domain specialists.

Estimating is usually performed by the task managers most fa-miliar with the work to be done. Estimates are made regarding per-son hours, pounds and feet of material, number of lines of code, andso on. As much as possible, estimates are based on sound information

cott_c12.qxd 7/1/05 3:53 PM Page 215


such as build-to drawings or direct past experience, but in mostcases the estimates are extrapolations, some of which depart signif-icantly from the extrapolation baseline.

Costing is the conversion of the estimates into currency. Costanalysts are trained experts in making this conversion. While mak-ing the conversion they take into account the current hour or mate-rial to currency conversion, expected inf lation or def lation over theperiod of the project, and all relevant burdens such as overhead andgeneral and administrative charges. When the hours and all otherresources have been costed with their appropriate burdens, thenthe cost of the project has been estimated. There are several toolsin the marketplace to aid in costing hardware and software basedon attributes such as weight, lines of code, or function points. Manycompanies also maintain a past-history database to substantiate es-timating and costing.

Figure 12.16 Relationship between WBS and organization.

CostAccount

CostAccount

CostAccount

CostAccount

RadarSystem

TransponderSubsystem

RadarSubsystem

ReceiverAssembly

TransmitterAssembly

AntennaAssembly

FeedSubassy

ReflectorSubassy

GimbalSubassy

≈

≈

≈

DesignAnalysisTech Data

≈

≈PhysicalDesign

AnalyticalDesign

Drafting &Checking

Test

Eng

inee

ring

Man

ufac

turin

g

Des

ign

≈

≈ ≈

≈

≈

SupportOrganization

Level 1

Level 2

Level 3

Level 4

Work Breakdown Structure

ProjectSummary

WBS

ContractWBS

MountSubassy

Work Package 1

Work Package 2

Work Package 3

Task Manager _________________________

WBS _________ Budget ______________

Start __________ Complete ___________

Task Description: _____________________________________________________________________________________________________________________________________

Approvals: Task Mgr __________

Support Mgr __________ Proj Mgr _______

Org

aniz

atio

n

cott_c12.qxd 7/1/05 3:53 PM Page 216

217

Figure 12.17 Individual task responsibility matrix.

Task

1

2

3

4

Eng

inee

ring

Man

ufac

turi

ngS

yste

mIn

tegr

atio

n

Test

Fina

nce

Con

trac

ts

R = ResponsibleS = Support

S S S S S R

R S S S

S R S S S

S

S

S R

Figure 12.18 Resource planning form.

cott_c12.qxd 7/1/05 3:53 PM Page 217


Pricing is a strategic decision made by management. It consistsof adding or subtracting profit from the cost number. Negativeprofit is applicable when the project desires to capture a new marketand is willing to invest to do so. Some companies have bid a totalfixed price of zero to ensure capturing a high-value market. As theprofit is increased, the probability of winning in a competitive envi-ronment decreases. Hence, this decision is one of marketplace strat-egy and risk tolerance. Figure 12.19 illustrates the estimating,costing, and pricing process.

The payoff of the detailed planning and scheduling is in secur-ing support and commitment on the part of the team, functional or-ganizations, subcontractors, general management, and the customeror user. The key negotiations, made easier by detailed scheduling,are those with the functional and task managers. The resultingagreement, the heart of the project’s controlled work release sys-tem, should be documented in the form of a Project Work Authoriz-ing Agreement (PWAA) shown earlier. The PWAA contains taskdefinition, budget, schedule, performer’s commitment, and project

Figure 12.19 Estimating, costing, and pricing process.

Authorization agreements andsubcontracts authorize theproject work and, collectively,represent and authorize theimplementation plan.

cott_c12.qxd 7/1/05 3:53 PM Page 218


office authorization. Subcontracts add terms and conditions clauses.The approved PWAA results from having:

Open and direct negotiations Budgets acceptedTasks understood Contingencies identifiedMilestones agreed Caveats documented

Our project cycle template includes a Project Initiation Reviewdecision gate. The objectives are to secure executive managementapproval of the implementation plan and to obtain management com-mitment of resources. The items to review include: contractual state-ment of work or memorandum of agreement for internal projects,deliverables, incentives; project strategy and tactics; implementationplan; opportunities, risks, and actions; functional organization com-mitments; and resources required.

KEEPING THE PLAN CURRENT

The project manager is responsible for:

• Assuring that all plans are consistent with current strategy, con-straints, and the project’s environment.

• Establishing the methods, techniques, and tools used in planning.• Using the techniques and tools to update the plan.

The techniques and tools, especially software applications thatsupport these responsibilities, are constantly improving. Before com-mitting to a new software tool that may come up short as the projectgrows, you may do well to heed the following precautions:

• Beware of nonstandard data input and output formats.• Some products are conceived and promoted as a full-manage-

ment tool, but may only provide a scheduling algorithm.• Test run the software.• Use implementation tools. There are many computer-based tools

available to mechanize the planning process and capture theproject’s data. These tools facilitate the planning process all theway from product decomposition through network development,critical path analysis, and schedule definition. They also providefor cost estimation, budget development, personnel planning,and resource leveling. Most tools will facilitate status reportingand associated rebaselining, if necessary.

• Talk to users who manage projects similar to yours.• Set up operating procedures and standards.• Insist that the standards be used.

The harder it is to plan, themore you need to.

cott_c12.qxd 7/1/05 3:53 PM Page 219


PLANNING ELEMENT EXERCISE

The objective of this exercise is to provide experience in developinga project network and in identifying and calculating the critical pathfor a simple but relevant project.

Scenario: Develop a logic network and the critical path for theturnaround of a commercial 140-passenger airliner from final land-ing approach to takeoff clearance. A sample WBS for the airplaneturnaround is provided.

WBS for the Aircraft Turnaround Project

1.0 Passengers and crew.1.1 Passengers.

1.1.1 Unload arriving passengers.1.1.2 Load “Pre-board” passengers.1.1.3 Load terminal-area passengers.1.1.4 Obtain head count.

1.2 Flight crew.1.2.1 Unload arriving crew (if required).1.2.2 Load departing crew.

2.0 Baggage.2.1 Unload arriving baggage.2.2 Load baggage from terminal.

3.0 Cabin service.3.1 Food.

3.1.1 Unload empty food carts.3.1.2 Load new meals and beverages.

3.2 Cleaning.3.2.1 Pick up trash.3.2.2 Vacuum or sweep cabin.

3.3 Sanitation.3.3.1 Clean lavatories.3.3.2 Empty toilet sump tanks.

4.0 Fuel.4.1 Determine fuel load required.4.2 Load fuel.4.3 Verify fuel onboard.

5.0 Operations Integration.5.1 Landing control.

5.1.1 Obtain permission to land.5.1.2 Land aircraft.

cott_c12.qxd 7/1/05 3:53 PM Page 220


5.2 Takeoff control.5.2.1 Obtain permission to takeoff.5.2.2 Takeoff.

5.3 Taxi control.5.3.1 Obtain permission to taxi after landing.5.3.2 Taxi to gate.5.3.3 Obtain permission to taxi prior to takeoff.5.3.4 Taxi to takeoff holding point.

5.4 Gate control.5.4.1 Obtain permission to open door.

Ensures that the exit ramp is in place before openingthe door.

5.4.2 Open cabin door.5.4.3 Obtain permission to close door.

Ensures that all ticketed passengers in gate area areon board, and that all maintenance and service per-sonnel have completed their tasks and have left theplane. The pilot and ticket agent must both concurplane is ready.

5.4.4 Close cabin door.5.5 Deicing application if required.

The deicing operation is done after all passengers areon board and the cabin door is closed. Deicing can bedone at the gate or on the taxiway near the terminal. Itmust be completed within 15 minutes prior to actualtakeoff.5.5.1 Apply deicing if required.5.5.2 Verify deicing application is within time limit.

6.0 Project management.6.1 Data management.

6.1.1 Gather turnaround time statistics.6.1.2 Report performance.

6.2 Manage “Turnaround Improvement Project.”

The following functions should be provided for:

Air Traffic Control.Ground Control.Passenger and Crew Management.Food Management.

All operational tasks in the WBS are linked into the serial /paral-lel relationships and then timed (example: Clean airplane—12 min-utes) that will satisfy a turnaround time of 40 minutes. Plan events

cott_c12.qxd 7/1/05 3:53 PM Page 221


from aircraft touchdown to aircraft liftoff. You must budget threeminutes from touchdown to gate arrival and three minutes for de-parture from gate to liftoff, and allow two minutes additional for de-icing in winter.

The results should be (1) determination of the critical path ac-tivities and (2) what tasks should be addressed to further shortenturnaround time.

cott_c12.qxd 7/1/05 3:53 PM Page 222

223

13OPPORTUNITIESAND THEIR RISKS

California is a great place to live, complete with excellentclimate, ethnic diversity, vibrant economy, and unlimitedrecreational possibilities. The opportunity of enjoying thesebenefits comes at the risk of earthquake devastation. Over theyears, homeowners mitigated this risk by carrying earthquakeinsurance at modest rates. They had little need to call on thebenefits until October 17, 1989, when California was hit bythe magnitude 7.1 Loma Prieta earthquake causing hugeinsured losses with deductibles as low as $1,000. The claimsimpact to insurance companies was profound and theinsurance industry began canceling homeowner policies anddeclining earthquake insurance. The California EarthquakeAssociation was formed to provide homeowners withearthquake insurance with a deductible of 15 percent of thereplacement value. But an important provision changed theinsurance value proposition: In the event of a large quakewithout enough money to go around, benefits are to beprorated. While California is still a place of opportunity, therisk is considerably higher than pre–Loma Prieta.

PMBOK ® GuideThis chapter is consistent withthe content of PMBOK ® GuideCh 11 Project Risk Manage-ment although there are defi-nition differences that will benoted.

INCOSEThis chapter is consistent withINCOSE Handbook Sec 5.8Risk Management Process.

THE OPPORTUNITY—RISK RELATIONSHIP

Over the past three decades, there has been a gradual paradigm shiftin risk management. The 1960s and 1970s introduced the concept ofrisk management and the idea that project teams should anticipaterisks and plan to reduce their impacts. This led to risk identification,top ten risk lists, and even risk management plans, although uniform

tcejorP

stnemeriuqeR

seiti nutr oppO

sksi R dna

evit

cerr

oCno

itcA

noitazinagrOsnoitpO

tcejorP

maeT

t cej orP

gni nnalP

t cej or Pl ort noC

tcej

orP

sut

atS

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadershiptc

ejor

P

ytili

bisi

V

ManagementElement 5

“A ship in a harbor is safe, butthat’s not what ships are builtfor.”

William Shedd

Ships are built to pursueopportunities, as are projects.

Risks are born of opportuni-ties. Without opportunitiesthere are no risks.

cott_c13.qxd 7/5/05 1:43 PM Page 223


When you’re encouraged totake risk, make sure to keepthe driving opportunity in per-spective.

PMBOK ® GuideThe PMBOK ® Guide Ch 11Project Risk Managementstates that risks can have apositive or negative outcome.Our approach recognizes thatopportunities seek a positiveoutcome and their associatedrisks diminish that opportunity.

adoption and implementation were slow. Then in the 1980s and1990s, opportunities began to be addressed along with risks.

A review of current texts on risk management reveals that bookswritten in 2000 and 2001 may mention opportunity and may evendevote a paragraph to it. Then in 2002 and 2003, the emphasisclimbs to a page or two, but opportunities are treated as things thathappen with good results as opposed to being the very thrust ofproject management. A prominent risk management text defines op-portunity, “as a possible occurrence that will have a positive effecton the project.” It goes on to say that, “opportunities should be iden-tified to balance out the negative occurrences (risks) as well as totake advantage of additional benefits of the project.” We take issuewith this perspective.

Project management is all about pursuing an opportunity tosolve a problem or fulfill a need. Opportunities enable creativity inresolving concepts, architectures, designs, strategic and tactical ap-proaches, as well as the many administrative issues within the proj-ect. It is the selection and pursuit of these strategic and tacticalopportunities that determine just how successful the project will be.Of course, opportunities usually carry risks. Each will have its ownset of risks that must be intelligently judged and properly managedto achieve the full value of each opportunity.

This chapter is not about risk management, but rather aboutmanaging opportunities and their risks to enhance ultimate projectvalue. We see problems and risks much as Henry Kaiser did, as justopportunities in work clothes.

In project management, opportunities represent the potentialfor improving the value of the project results. The project champi-ons (the creators, designers, integrators, and implementers) applytheir “best-in-class” practices in pursuit of opportunities. After all,the fun of working on projects is doing something new and innova-tive. It is these opportunities that create the project’s value. Risksare defined as chances of injury, damage, or loss. In project manage-ment, risks are the chances of not achieving the results as planned.Each of the strategic and tactical opportunities pursued have asso-ciated risks that undermine and detract from the opportunity’svalue. These are the risks that must be managed to enhance the op-portunity value and the overall value of the project.

Opportunity and risk management are essential to—and per-formed concurrently with—the planning process, but require theapplication of separate and unique techniques that justify this dis-tinct project management element.

When we pursue the opportunity to arrive at a destination earlyby speeding down the highway, we accept the risk of incurring an

The value of the opportunitymust justify the incurred risks.

cott_c13.qxd 7/5/05 1:43 PM Page 224

OPPORTUNITIES AND THEIR RISKS 225

expensive traffic fine and higher insurance rates. To speed, our ac-celerator foot instinctively stabilizes at the exact position where weperceive the probability and benefit of arriving early is exactlyequal to the probability and consequences of getting caught. Wenaturally and regularly make this trade and balance the expectedoutcomes with our accelerator foot for this combination of opportu-nity and risk.

The power of this concept is in the ability to adjust the opportu-nity to reduce or eliminate an undesired risk. One of the authorswanted a multiuse vehicle with all-wheel drive to get to the skislopes. The opportunity was to purchase a sports utility vehicle(SUV), but the local newspaper and television vividly portrayed therisk of rollover. Risk was significantly reduced by simply adjustingthe opportunity from an SUV to a minivan with all-wheel drive anda lower center of gravity that significantly reduces the rollover po-tential. Many project situations can be addressed by adjusting theopportunity to fit the risk tolerance of the project.

It is sometimes difficult to identify the opportunity that causesthe risk (the “causing opportunity”). For instance, inhabitants of thesoutheastern United States are subjected to hurricanes almost everyyear. The causing opportunity, of course, is enjoying the benefits ofliving within the hurricane zone. Many people knowingly make thatdecision and consider the risk worthwhile. Similarly, other peopleprefer San Francisco as a place of residence in spite of the well-known risk of earthquakes.

If you have difficulty identifying or evaluating the causing op-portunity, the risk just might not be important enough to accept andmanage. In this case, consider eliminating the item or circumstancescreating the risk.

LEVELS OF OPPORTUNITY AND RISK

In project management there are two levels of opportunities andrisks. Because a project is the pursuit of an opportunity, the firstcategory, the macro opportunity, is the project opportunity itself.The approach to achieving the project opportunity and the mitiga-tion of associated project-level risks are structured into the strategyand tactics of the project cycle, the selected decision gates, theteaming arrangements, key personnel selected, and so on.

The second level encompasses the tactical opportunities andrisks within the project that become apparent at lower levels of de-composition and as project cycle phases are planned and executed.This can include emerging, unproven technology; incremental and

When we pursue opportunity,we normally incur risk. Theopportunity to experience thethrill of an exciting sport likehang gliding or scuba divingbrings with it the attendantrisks. Many people instinc-tively make the trade that thethrill is worth the risks. Othersdecline.

Opportunities and risks areendemic to the project envi-ronment. However wellplanned a project may be,there will always be residualproject risk.

cott_c13.qxd 7/5/05 1:43 PM Page 225


There is no simple way toprevent disasters. Nothingshort of a systematic, detailedprocess will work.

If you don’t actively attackrisks, the risks will activelyattack you.

If you don’t identify opportuni-ties, they won’t be in your fieldof view.

evolutionary methods that promise high returns; and the tempta-tion to circumvent proven practices in order to deliver better,faster, and cheaper.

In the heat of project battle, it is easy for opportunities and risksto slip by or to slip in inadvertently. It is the project manager ’s re-sponsibility to maintain a high level of awareness among all projectparticipants, especially during various activities, such as:

• Project definition,• Concept definition,• Architecture definition,• Strategic and tactical planning,• Artifact selection and development,• Hardware and software development,• Manufacturing and coding,• Supplier selection,• Verification,• Shipping and handling,• Deployment, and• Change evaluation.

Regarding the career-limiting effect of underestimating futurerisks, March and Shapira have articulated this management di-chotomy: “Society values risk taking but not gambling, and what ismeant by gambling is risk taking that turns out badly. . . . Thus,risky choices that turn out badly are seen, after the fact, to havebeen mistakes. The warning signs that were ignored seem clearerthan they were; the courses that were followed seem unambiguouslymisguided.”1

The rest of this chapter is about maximizing opportunities anddealing directly with the inevitability of their risks—the foresee-able ones as well as the “unknown unknowns” that occur throughoutthe project.

PROJECT-VALUE-DRIVEN OPPORTUNITY ANDRISK MANAGEMENT

Project value can be expressed as benefit divided by cost. Opportu-nities and their risks should be managed jointly to enhance projectvalue. This is based on the relative merits of exploiting each oppor-tunity and mitigating each risk. In the context of the opportunityand the resultant project value, you make that kind of evaluation in

cott_c13.qxd 7/5/05 1:43 PM Page 226


PMBOK ® GuideThe PMBOK ® Guide Ch 11Project Risk Managementidentifies six processes:

1. Risk ManagementPlanning.

2. Risk Identification.

3. Qualitative Risk Analysis.

4. Quantitative Risk Analysis.

5. Risk Response Planning.

6. Risk Monitoring andControl.

your personal life every time you estimate how much you will driveper year (your opportunity) to decide how much insurance youshould carry and with what level of deductible, which is the amountof residual risk you are willing to accept (your risk tolerance).

We carry a spare tire to mitigate the risk of a f lat tire by re-ducing the probability and impact of having a delayed trip. Thehigh value we place on getting where we want to go far exceeds thesmall expense of a spare. When deciding to pursue the opportunityof a long automobile trip, we may take extra risk management pre-cautions, such as preventive maintenance and spares for hard-to-find parts.

The assessment of opportunity and risk balance is situational.For instance, few of us today have a car with more than one sparetire (multiple spares were a common practice in the early 1900s).However, a friend of one of the authors decided to spend a fullmonth driving across the Australian Outback in late spring. He waslooking for solitude in the wilderness (the opportunity). On advicefrom experienced friends, he took four spare tires and wheels. Theyalso advised him that the risk of mechanical breakdown was veryhigh on a 30-day trip, and the consequence would almost certainlybe fatal. However, the risk of two vehicles breaking down at thesame time was acceptably low. So he adjusted the opportunity forabsolute solitude by joining two other adventurers. They set out inthree cars. Everyone survived in good health, but only two cars re-turned, and two of his “spare” tires were shredded by the rough ter-rain. The mitigation approach proved effective.

We define opportunity and risk management as the process toenhance the opportunities and reduce their risks by:

• Identifying potential opportunities and their risks.• Assessing associated probabilities of occurrence and the impact

(benefit or consequence) of the occurrence to the project’s value.• Deciding to:

Do nothing OR Take causative OR Take contingentaction for action in responseopportunity, to a predefinedpreventive trigger.action for risk.

Opportunity management is driven by the desire to excel andrisk management is driven by the desire not to fail or fall short ofthe objectives. The major driving forces for each are shown in Fig-ures 13.1 and 13.2.

INCOSEINCOSE Handbook Sec 5.8Risk Management Processdefines risk management as:

• Risk Identification.

• Risk Planning.

• Risk Assessment.

• Risk Prioritization.

• Risk Handling andMitigation.

• Risk Monitoring.

cott_c13.qxd 7/5/05 1:43 PM Page 227


Since many opportunities andrisks are discovered in thedecomposition process, it isimpossible to identify allopportunities and their risks atthe outset.

Opportunity and risk management depends on a solid founda-tion of planning and proactive management of the plan. Good plan-ning practices are:

• Develop (and use) an implementation plan that is:—Developed—and committed to—by the project team.—Kept current.

• Use proven processes tailored to your project.—Systems engineering methodology.—Software development methodology.—Hardware development methodology.—Reliability and quality methodology.

• Manage the business and technical baselines.—Keep participants informed of the evolving baseline.

The project team may feel they have already “managed” therisks by creating the initial opportunity/risk management plan. Butopportunity and risk management is ongoing—it evolves as the proj-

Figure 13.1 Opportunity management objectives—driven by the desire to excel.

Benefit - B

sseccu

S fo ytili

bab

orP

-P

s

0

1.0

Low High

Manage to achieve high benefit and high probability• Seek opportunities to support the strategic objectives• Foster creativity to achieve best-in-class performance• Keep the team energized to excel• Proactively manage success

cott_c13.qxd 7/5/05 1:43 PM Page 228


Each opportunity and its riskshould be evaluated as awhole, taking into account relative probabilities and offsetting benefits and consequences.

ect proceeds. Plans must be updated as new opportunities and risksare identified and the impacts are evaluated.

Opportunities and risks are interrelated and the risks must bejustified by the opportunity pursued. The following eight-step op-portunity and risk management process justifies decisions based onexpected value analysis:

1. Identify the opportunities and risks.• What opportunities are available? What benefits?• What are their risks? What consequences?• Describe with “If . . . , then . . .” statements.• Group by like categories, such as funding, safety, sched-

ule, and so on.2. Assess both probability and impact. Forecast the expected value.3. Prioritize according to expected project value.4. Develop candidate management actions to enhance opportuni-

ties and mitigate risks.5. Estimate the cost of both immediate and contingent actions.

Figure 13.2 Risk management objectives—driven by the desire not to fail.

Adverse Consequence - Cƒ

erulia

F fo ytili

bab

orP

-P

ƒ

0

1.0

Low High

Manage to reduce probability and consequence toward zero• Adjust driving opportunity to reduce or eliminate the risk• Reduce probability by removing failure causes (drive safely)• Reduce impact by anticipating the result and preparing for it

(wear seat belts)• Hold management reserve for reactively handling risk

cott_c13.qxd 7/5/05 1:43 PM Page 229


6. Compare changes to expected value against action costs (Miti-gation Leverage).

7. Decide on actions required and obtain concurrence.8. Document and incorporate decisions in all planning.

Some project managers and executives make a distinction be-tween eliminating risks versus insuring against them (such as liabil-ity insurance) or deciding on an action versus planning a contingency.In our view, these are simply alternative cases of opportunity andrisk management and need to be evaluated as such. For example, weconsider insurance as one possible mitigating action for product lia-bility risks. The examples that follow demonstrate techniques thatare unique to opportunity and risk management. Opportunity andrisk management actions fall into four categories:

1. Accept the opportunity and its risks with no exceptional action.We use this approach when we cross a street at a crosswalkwith no exceptional actions to enhance the experience or re-duce the risk.

2. Avoid the risk, which can often be accomplished by adjustingthe opportunity to eliminate the risk cause. Driving carefullywithin the speed limit with seat belts fastened is an example ofrisk avoidance.

3. Retain the opportunity and transfer the unacceptable portionof the risk to a third party usually with only a small effect onthe expected value of the opportunity. This is commonlyachieved by insurance such as collision insurance and home-owners insurance.

4. Mitigate the risk and retain the opportunity. Reduce the proba-bility or consequences of the risk to an acceptable level by oneor more actions. In technical projects, redundant circuits andhigh reliability parts are possible mitigation actions.

IDENTIFYING OPPORTUNITIES AND THEIR RISKS

A major challenge of the project manager is team motivation. The“risk list” is a demoralizing force as the team engages in ongoing dis-cussions to identify all the things that could go wrong. As Rita Mul-cahy phrased it in her book Risk Management, “opportunities shouldbe identified to balance out the negative occurrences (risks) as wellas to take advantage of additional benefits of the project.”2 Mulcahyrecognizes the negative morale that can result from incessant riskmanagement viewed exclusive of the creating opportunities.

cott_c13.qxd 7/5/05 1:43 PM Page 230


The “managing opportunities and their risks” approach main-tains harmony and balances the evaluations. A risk that key person-nel may not be available when required sounds serious. If the realsituation is that the best supplier in the country has agreed to do thework (opportunity), but their best personnel may not be available(risk), then a key personnel clause in the contract may be sufficientto mitigate the risk. Having the opportunity and risk tied togetherputs the problem in context and balance.

On the Boeing 777 development, Boeing engineers wanted toseize the opportunity of using aluminum-lithium to save weight,gain payload capacity, and maximize fuel economy (opportunity).However, machining the material caused cosmetic cracks that wouldhave to be explained in their maintenance manuals (risk). Discus-sions were held at the highest levels of management to evaluate thevalue trade-offs and impact to the 777 program. Aluminum-lithiumwas rejected as too risky to the market image of Boeing. It was a sig-nificant project-value-based judgment, as well as a vivid case of sys-tems thinking.

A simple approach is to reward those who identify opportunitiesand risks. A cost-effective technique is a prominent posting (perhapsoutside a manager ’s door) of all the opportunities and their risks ina manager ’s domain. A brief statement of what actions will be taken(or if no action is to be taken, why not) and who has the actionshould be included in the listing. The listing has powerful effects. It:

• Shows that the manager is serious about pursuing and managingcreativity.

• Rewards participants (printed recognition is an effective, inex-pensive reward).

• Stimulates others to think of opportunities.• Precludes redundant efforts.• Prompts others to offer suggestions for how to mitigate identi-

fied risks.

It can be helpful to subdivide the myriad of possible opportuni-ties and risks into categories. Opportunity categories are strategicand tactical, like deciding what business to be in (strategic) and thenpursuing the business (tactical). Figure 13.3 illustrates examples ineach category. Using emerging technology or new development toolsare examples of tactical opportunities that bring with them the riskof unsuccessful implementation.

Risk categories include risks to project implementation and risksto, of, and by the product, such as lack of sufficient funding (imple-mentation) and incorporating dangerous toxins (product). Figure 13.4

To evaluate risk without regardto the driving opportunity isalmost meaningless and couldbe irresponsible.

cott_c13.qxd 7/5/05 1:43 PM Page 231


illustrates examples in each category. This is only a representativelist—all relevant areas must be considered. Each of these areasshould be evaluated in the context of the causing opportunity.

Identify the opportunities and risks for each project-cycle phaseby systematically applying the appropriate techniques based onanalysis, planning, and history. Techniques based on analysis include:

• Opportunity and risk checklists (the categories and lists in Fig-ures 13.3 and 13.4 offer a beginning checklist).

• Rules of thumb and standards of performance.

• System decomposition and critical items (Vee off-core analysis).

• Hazard analysis.

• Failure modes analysis.

• Interviews with experts.

There is a wide variety of texts available that provide insight andchecklists on identifying risks having to do with project administra-tion, that is, risks associated with schedule, critical path, funding, re-sources, personnel, and so on. Tom Kendrick’s book, Identifying and

Figure 13.3 The two categories of opportunities and risks.

cott_c13.qxd 7/5/05 1:43 PM Page 232


Managing Project Risk,3 and Rita Mulcahy’s book, Risk Manage-ment,4 are excellent references.

Figure 13.5 illustrates three areas of risks relative to the oppor-tunity of product solution creation on development projects.

The first are “risks to the solution,” such as shipping and han-dling. We are all very familiar with the use of foam popcorn andbubble wrap to mitigate the handling risk when shipping a fragileproduct. This category also includes the need for contamination con-trol in semiconductor manufacturing, in pharmaceutical develop-ment and production, and in spacecraft development. In secureprojects, security risks are critical and risk management must en-sure the project’s opportunity is not compromised by inadvertentdisclosure. A recent mishap, when the NOAA N Prime $200 millionsatellite fell off of its tilt stand and crashed to the f loor, is an excel-lent example of the handling risks not being properly managed. Inthis case, operators bypassed good workmanship practices and didnot follow established procedures.

The second category is “risks of the solution,” which becomeimbedded within the product only to surface later and cause projectfailure. There are many famous illustrations of this type of poorly

Figure 13.4 The two categories of tactical opportunities and risks.

TacticalOpportunities and Risks

These can seriously influence the ability to deliver

SystemsEngineering

Issues

SystemsEngineering

Issues

ProductAbility to satisfy the

needs

ProductAbility to satisfy

the needs

• Feasibility

• Design

• Producibility

• Development

• Failure modes

• Hazards

• Stakeholder support

• Funding

• Cost/budget

• Schedule

• Resources

• Suppliers

ProgrammaticAbility to deliver as

planned

ProgrammaticAbility to deliver

as planned

ProjectManagement

Issues

ProjectManagement

Issues

cott_c13.qxd 7/5/05 1:43 PM Page 233


managed risk. The Hubble telescope, the space shuttle Challenger,the Ford Pinto, the submarine Scorpion, and all the vehicles andother products that are the subject of product recalls were deployedwith f laws built in to their products. Good design and verificationpractices should have caught and fixed every one of these f laws be-fore first deployment. However, other stakeholders may have over-riding priorities. A tragic case of this opportunity/risk relationshipoccurred in the 1970s. Lee Iacocca, head of the new Ford Pinto cardevelopment, was committed to pursuing the opportunity to enter anew market segment in competition with Japan and Germany for alow-cost car. He mandated 2,000 pounds and $2,000 as the valuecriteria that had to be met with no exceptions. It was soon discov-ered that the car would explode on rear impact because of gas tanklocation and design. To address that risk, the company could havemade an $11 per car modification. However, they elected to acceptthe risk and pay for injury and deaths because the liability costwould be less than the tank modification cost. This unfortunate de-cision was based solely on a cost of the opportunity versus the costof the consequences and resulted in several hundred lost lives.

The third product category is “risks by the solution” where thesolution contains risks that can cause injury to the product or tothose using the product. Nuclear power plants, radiation benches,weapons, and hospitals are all solutions that can cause injury to theinnocent. Hospitals now shorten rehabilitation time to quickly exitpatients from the potentially infectious environment of the hospital.

All of these areas must be considered in opportunity and riskplanning in order to achieve a high probability of success.

Figure 13.5 Areas of product risk.

Risks

Product Risk AreasRisks to, of, and by the solution

Risks Risks

cott_c13.qxd 7/5/05 1:43 PM Page 234


Hazard analysis is a risk identification technique used to ensureall system hazards have been identified and anticipated in plans.Once identified, all hazards to personnel and to the system areeither accepted, reduced by design, or contained by practice. Forexample, a high-pressure gas hazard can be reduced by designingthe equipment with a large safety factor. Alternatively, the risk ofexplosion can be contained by placing sand bags or other protectionbetween the hazard and personnel.

Failure Modes and Effects (and Criticality) Analysis (FMEAand FMECA) are risk identification techniques used to ensure allsignificant failure modes have been identified and anticipated.These techniques employ the following:

• Selection of a ranking or prioritizing scheme for project failuremodes concern and attention.

• Identification of all single-point failure modes and ranking ofthem.

• Analysis of additional failure modes and the resultant opera-tional effects.

• Determination of those failure modes requiring elimination, re-dundancy, and /or increased reliability.

• Implementation of the corrective action.

When ranking FMEA risks, it is helpful to have clear categories.Consider the following category examples:

Category #1—Loss of life.Category #1R—Loss of life but the mode has redundancy.Category #2—Mission fails.Category #2R—Mission fails but mode has redundancy.Category #3—Mission is compromised.Category #3R—Mission is compromised but failure mode hasredundancy.

Other effective risk identification techniques are usually basedon planning and on past lessons learned. Scenario planning is a “low-tech” technique for “visualizing” opportunities and risks, and is use-ful in project planning judgment. It consists of querying:

• “What if . . . ?” followed by “. . . then what?”• What opportunities might be pursued?• What could go wrong?

This technique can also be used to build a decision tree based onbroad market and economic trends: “If the economy does this, I’ll do

cott_c13.qxd 7/5/05 1:43 PM Page 235


that.” These scenarios can often identify important assumptions thattraditional forecasting tends to miss. It represents another systematicway to consider future possibilities. Planning techniques also include:

• Project network interaction analysis.• Critical path content and near critical path analysis.• Schedule slack adequacy and position.

The techniques based on history are the most natural to apply.They include:

• Similar efforts and their lessons learned,• Expert interviews,• Technical surveys, and• Development test results.

Generalized historical templates can work well in some industries.For example, construction projects are highly repetitive comparedwith research and development. Because the work patterns of oneproject may be similar to selected ones from the past, the same typesof risks are likely to occur and lessons learned are especially relevant.

Alternatively, misperceptions or misinterpretations about priorprojects will sometimes lead project teams to overestimate their abil-ity to control future risks or to exploit future opportunities. It hasoften been left up to project leaders to identify risk based on theirown experiences and perception of the situation. Such projects wereat the mercy of whatever their experiences and perceptions were. Asone engineer put it, “The alligator that was the closest to you was theone you worried about the most. You didn’t look at the other ’gators inthe swamp, even though they were bigger and meaner.” A commonmisperception is that successful experiences with simpler projectsscale to complex ones. Every new project has to be analyzed in detailto understand those unique properties that distinguish it from its pre-decessors. This needs to be an ongoing team effort, and it relies heav-ily on lessons learned.

ASSESSING PROBABILITY AND IMPACT

A goal of identifying and anticipating all opportunities and riskswould be overwhelming. The result of anticipating every possibleopportunity and risk could bury the team in questionable informa-tion and turn the project into a hand-wringing exercise. This drama-tizes the importance of prioritization.

There are a number of sophisticated and powerful tools availablefor opportunity and risk analysis, such as decision trees and Monte

Not only is each projectunique, but the uniqueness isoften the source of its risk.

cott_c13.qxd 7/5/05 1:43 PM Page 236


Carlo simulations. These tools and others are described in texts suchas Clemen’s book, Making Hard Decisions,5 and Tom Kendrick’sbook, Identifying and Managing Risk.6

However, for most decisions we face in a project environment amuch simpler technique (called expected value) can be used, and itis described as follows.

The expected value (EV), sometimes called weighted value, ex-pected outcome, or risk factor, is a technique for quantitatively com-paring both opportunities and risks. It provides the project managerwith a measure for sizing management reserves for investment andprotection. The EV of opportunity and risk is equal to the probabil-ity of occurrence multiplied by the impact. For example:

Probability of occurrence of an opportunity = 0.6Benefit of the opportunity = $720,000 if it does

occurTherefore, expected value = (0.6) × ($720,000)

= $432,000

Expected value provides a method for quantitatively comparingboth opportunities and risks. The primary use of EV is to prioritizepotential actions. When applying EV, be sure to use consistent units.For the purposes of prioritizing, “burn rate” (usually expressed as adaily expense rate) may be used to measure schedule impact in dol-lars. The following is an example of prioritizing two risks involvingpotential schedule slip and burn rate.

Risk 1 Expected Value Risk 2 Expected Value

(0.8) × ($100,000) = $80,000 (0.4) × ($60,000) + (0.4) × (45-dayslip) = $24,000 (cost) plus 18-days(schedule)Assuming a $2,000/day burn rate, a45-day slip would cost $90,000Expected value, on a cost basis,= $24,000 + (0.4) × ($90,000)= $60,000

On the basis of this analysis, Risk 1 should be of higher prioritythan Risk 2. The risk can be managed by inf luencing the probabilityof occurrence and /or the impact of the outcome.

A complete listing of the possible inf luencing activities withtheir associated costs should be developed (Figure 13.6). From this,you can decide on the appropriate actions. There are basically twotypes of actions to consider: causative or preventive, and contingent.

When applying expectedvalue, common sense andgood judgment are requiredbecause the calculations, usu-ally based on subjective infor-mation, will have lowaccuracy.

PMBOK ® GuideThe PMBOK ® Guide Sec 11.3Qualitative Risk Analysis and11.4 Quantitative Risk Analysisdifferentiate qualitative riskanalysis from quantitative riskanalysis. Qualitative prioritizesrisks and quantitative isnumerical analysis of the riskeffect on the project.

cott_c13.qxd 7/5/05 1:43 PM Page 237


Causative actions enhance opportunity expected value and pre-ventive actions reduce risk expected value. Contingent actions arethe same as causative or preventive actions, except that no actionother than preparation is taken until a predetermined trigger initi-ates the action.

Causative and

Preventive Actions

Adjusting the opportunity toreduce the risk.

Redundancy to eliminate single-point failure modes.

Higher quality to increasereliability.

Increased margins to improvesafety.

Enforced use of commonsoftware languages and

Contingent Actions

Red-line limits in test procedures(terminate test if exceeded).

Establish thresholds for vari-ance analysis and corrective ac-tion (triggers a focused review).

Planned tactical changescontingent on a competitor ’sperformance.

Unsolicited proposal based oncompetitor ’s poor performance.

Figure 13.6 Management of opportunity and risk actions.

Risks ExpectedOutcomes

High

Medium

Low

PossibleMitigating and

EnhancingActivities

AssociatedCost ofEach

Activity

PossibleMitigating and

Enhancing Activities

AssociatedCost ofEach

Activity

Opportunities

Do nothing —accept risk andignore opportunity

Take action now

Plan action to beimplemented at trigger

cott_c13.qxd 7/5/05 1:43 PM Page 238


The cost effectiveness of candidate actions can be evaluatedusing mitigation leverage or enhancement leverage factors definedas follows. The leverage values can be used for comparison and as anaid in action selection.

DECIDING ON REQUIRED ACTIONS ANDINCORPORATING THEM INTO THE PLAN

It is often impractical to accurately estimate the probabilities ofoccurrence and impacts of potential events. In these cases, decisionsmay be based on a qualitative assessment for both the probability ofoccurrence and the benefit or consequence. In the sample risk deci-sion matrix in Table 13.1, based on qualitative assessments, carryinga spare car ignition key in your wallet or purse is a high-impact, low-probability instance (for some, a high-probability instance).

All opportunity and risk management actions must be incorpo-rated into the project plan and kept current (Figure 13.7). Carrying aspare key for the car you sold two years ago is an example of an ex-cellent risk management decision turned bad through neglect (what’sworse, you are confidant that you’re secure until you discover thewrong key in a crisis).

On cost-reimbursable contracts, it is wise to obtain customerconcurrence with opportunity and risk management actions becausethe customer will likely be paying for them.

EV after – EV beforeBenefit enhancement costEV before – EV afterRisk mitigation cost

Mitigation Leverage =

Enhancement Leverage =

Causative and

Preventive Actions

standards across subcontractorand prime team.Expert review to ensure bestapproach.Overtime to shorten criticalpath.Overdesign for possible futuregrowth (preplanned productimprovement).

Contingent Actions

Red-line limit triggered changeof test conditions.Technical performance mea-surement triggered weightreduction.Circuit breaker interruption ofpower overload.

PMBOK ® GuideThe PMBOK ® Guide Sec 11.5.2Risk Response Planning identi-fies three strategies for nega-tive risks:

1. Avoid.

2. Transfer.

3. Mitigate.

and three strategies forpositive risks:

1. Exploit.

2. Share.

3. Enhance.

cott_c13.qxd 7/5/05 1:43 PM Page 239


To be effective, this opportunity and risk management processshould occur throughout the project cycle and at all levels of archi-tecture decomposition. The resultant management actions must be:

• Overt, conscious decisions;• Supported by justifiable rationale;• Incorporated in the plan; and• Implemented through work authorizations and subcontracts.

RELATING OPPORTUNITIES AND THEIR RISKS TOTHE PROJECT CYCLE

As we emphasized earlier, opportunity and risk management is ongo-ing—it evolves as the project evolves. Perhaps one of the greatestproject risks is not following the project plan (updated, as neces-sary). Not following the plan for the final ascent is the direct cause

Table 13.1 Sample Risk Decision Matrix

High

Medium

Low

Low Medium High

Adverse Consequence

Establish

contingency

plans

Status regularly

Establish

contingency

plans

Act immediately if cost effective

Unacceptable

Take immediateaction

Acceptable,

Do Nothing

Status regularly

Establish

contingency

plans

Status frequently

Establish

contingency

plans

Act immediatelyif cost effective

Acceptable,

Do Nothing

Statusoccasionally

Establish

contingency

plans

Status regularly

Establish

contingency

plans

Act immediatelyif cost effective

Pro

bab

ilit

y o

f Failu

re

cott_c13.qxd 7/5/05 1:43 PM Page 240


of the fatal, tragic end of Rob Hall’s Mt. Everest expedition in 1996causing the death of 11 men and women.7

The sources and nature of opportunities and risks vary from pe-riod to period and from phase to phase. For example, the major risksduring the study period may be the instability of the requirements,lack of understanding of the user problem, and funding, whereastraining, logistics, and supplier quality may loom as the largest risksduring the implementation period.

The Vee model provides a visual basis for identifying and manag-ing opportunities and risks during both architecture and entity de-velopment. Figures 7.11 and 7.12 in Chapter 7 introduced the ideaof using off-core activities for opportunity and risk investigation andmanagement. Figure 13.8 lists critical issues to be studied off coreduring the user requirements understanding phase—an acknowl-edgement that users (or the organization representing the users)often do not have a clear understanding of their needs. Figure 13.8also details the early portion of the core of the Vee, starting with thestatement of user need. The diagram highlights the off-core studiesthat provide user requirements clarification and understanding.

Opportunities to be pursued may include innovations that ex-tend the product’s useful life through planned technology upgradesor value enhancements that reduce the cost or broaden the market.

Our personal insurancepolicies and the spare tires wecarry in our cars are everydayexamples of risk management.

Figure 13.7 Opportunity and risk decision records.

cott_c13.qxd 7/5/05 1:43 PM Page 241


An example of the latter occurred several years ago on a client’sproject to develop a new calculator for the U.S. financial commu-nity. As part of the off-core user requirements clarification, a meet-ing was held with a group of financial analysts. The users requestedadding a button to the keyboard for dividing the displayed result by365, the U.S. standard for interest-bearing days. This feature was anopportunity for a competitive edge and was adopted. Still anotheropportunity occurred soon thereafter that more than doubled theavailable market. A development team member suggested reconfig-uring the keyboard to also accommodate the 360-day Europeanstandard. The change was easily accomplished at this early stage,but would have had a major impact after coding or manufacturinghad started.

Figure 13.8 Critical issues of the user requirements definition phase.

User

System

Segments

MissionOperations

Hardware Configuration Item

Software Configuration Item

ConceptFormulation, Trades,

and Selection

System Specification

Design Concept Formulation &

Selection

Des. Concept Documents

Mission Ops

HWCI Concept

CSCI Concept

Statement of User Need

User RequirementAnalysis & Agreement

Critical Issues

Critical Issues

Critical Issues

Critical Issues

Critical Issues

Critical Issues to be Studied:

•

•••

•

Performed at the Level Necessary to Identify and

Manage Risks and Opportunities

User Requirements ClarificationOperations ConceptsDriving TechnologySoftware "Functional Requirements Prototyping"Hardware and Software Constraints

cott_c13.qxd 7/5/05 1:43 PM Page 242


Off-core studies usually begin early in the project cycle and maybe very simple investigations requiring only a few hours to exploreopportunities and to ensure that risks are acceptable. However, ifthe solution is challenging the state of art, the studies themselvescan be very involved projects requiring years of effort (the Reaganera “Star Wars” space defense initiative project is an opportunity ex-ploration example).

Studies may be analytical or they may require development of asoftware or hardware model to resolve system capabilities, con-straints, and technology or integration issues. These models mayneed to go to the lowest level of detail in selected areas. One exam-ple is creating a software algorithm to prove that a data search of alarge, distributed database can be performed within a specified pe-riod. The authors were involved in developing a database manage-ment system that could perform a complex search of six millionentries in three seconds. The off-core feasibility studies focused onfunctionality rather than performance, resulting in an algorithmthat was successfully tested on 100,000 entries. Unfortunately, theproject failed when the fully implemented system required up toone minute to perform a complete search (even though the typicalsearch met the three-second limit).

After completion of early project phases, it is often necessary torevisit the decisions as external events change or as new insights arediscovered through off-core studies in lower level detail. Calendartime and solution maturity move from left to right, so the revisitingprocess does not occur by going back up the core of the Vee butrather by moving vertically to the system specification update, con-cept update, or user requirements update.

The functionality that the user expects must be f lowed down to,and responded to, by entities of the system. Piece parts and lines ofcode must be provided in order to complete those entities. At eachof the subtier levels, there may be critical issues that should be ex-plored to minimize the risk that, when these details are finally de-signed and verified, they fall short of the expected functionality orperformance. Other critical issues include the expansion of oppor-tunity and risk evaluation to include affordability assessment, envi-ronmental impact, system risk, failure modes, and hazard analysis.

The upward and downward opportunity and risk iterations con-tinue through the design-to (PDR) and build-to (CDR) gates. Dur-ing the decomposition and definition process, major areas of riskare identified and approaches are developed to manage them. Asshown in Figure 13.9, it is not necessary that the same solution to agiven problem be followed throughout. As the project moves from

Projects that fall short of userexpectations, even thoughthey surpass the state of theart, are not likely to succeed.

Off-core studies do not seek afinal solution, but rather ademonstration that at leastone solution is feasible.

cott_c13.qxd 7/5/05 1:43 PM Page 243


phase to phase, a new and better approach may be conceived. Con-sider the detailed view of the off-core studies illustrated in Figure13.9. The following five steps correspond to the numbers in ovalson the diagram:

1. During the User Requirements Definition Phase, it may be nec-essary to descend to the subsystem level to verify that there isat least one way to meet the requirements, and a hardware solu-tion is found.

2. As concepts are evaluated during the Concept Definition Phase,off-core studies reveal an opportunity to perform the function(in number one) using software, rather than hardware, yieldinga more f lexible design approach.

Figure 13.9 Off-core alternatives.

cott_c13.qxd 7/5/05 1:43 PM Page 244


3. During segment concept definition studies, concern is raisedabout the risk of inadequate software performance, so the rou-tine must be modeled to provide confidence.

4. When the software unit performance is proven acceptable, thesoftware subsystem is modeled and opportunities to shape thedesign for future product enhancements are explored.

5. In the next phase, the software concept is defined in appropri-ate detail to create the design-to documentation and to put itunder baseline control.

Figure 13.10 The Spiral model annotated.

RA Proto-type1

Prototype2

Risk Analysis

Risk Analysis

Risk Analysis

Prototype3

OperationalPrototype

SimulationsModels

BenchmarksConcept ofOperation Software

Reqmts.

SoftwareProductDesign

DetailedDesign

UnitTest

Code

Integrationand Test

AcceptanceTestImplemen-

tation

DetermineProcessObjectives,Alternatives,Constraints

Evaluate ProcessAlternatives; Identify,Resolve Process Risks

RequirementsValidation

Design Validation andVerification

Integrationand Test

Plan

Develop-ment Plan

Reqmts.Plan

Develop, VerifyNext-LevelProcess Plans

CommitmentReview

Progress Through Steps

Life Cycle Plan

Cumulative Cost

Evaluate Alternatives;Identify, Resolve Risks

Develop, VerifyNext-Level Product

Plan Next Phases

Determine Objectives,Alternatives, Constraints

Circled numbers are added tothe Spiral Model for directcomparison to the TechnicalAspect of the Project Cycle

1

2

7

22

23

24

25

26

27

19

18

17

16

159

10

11

3

4

5

6

20

21

12

8

Partition

13

14

28

cott_c13.qxd 7/5/05 1:43 PM Page 245


There is no requirement for the concept at step 2 to mature intothe baseline at step 5. On the other hand, there could be an iterativeevolutionary development of a concept from step 2 to elaboration atstep 4 to a baseline at step 5.

The Spiral Model

The two Vee models provide abstract views of both the architectureand entity development of complex solutions. Another popular viewof entity software development is the Spiral model discussed inChapter 7. While the spiral is basically a sound model, it tends to ob-scure the need for continuous attention to opportunity and risk man-agement all the way through solution development (rather than justprior to concept definition). In fact, the Spiral and the Vee models

Figure 13.11 Spiral model overlaid on the Vee.

User

System

Segments

UserOperations

HardwareConfig Item

SoftwareConfig Item

UserOperations

HardwareAssemblies

SoftwareComponents

Hardware Parts& Processes

ComputerSoftware Units

,

Statement ofUser Need

Design ConceptFormulation &

Selection

Des. ConceptDocuments

Mission Ops ConceptFormulation, Select, & Doc

HWCI Concept Formulation,Select, & Doc

CSCI Concept FormulationCOTS & NDI Select, & Doc,

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

Concept Formulation,Including COTS, NDITrades, and Selection

SystemSpec

Integrationand Test

User RequirementUpdate

CriticalIssues

CriticalIssues


System SpecificationUpdate



Design ConceptUpdate

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

User RequirementAnalysis & Agree.

CriticalIssues

CriticalIssues

FunctionalAllocation




CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

Mission Ops ConceptPrelim & Detail Design

HW Assembly Prelim &Detailed Design

SW Component Prelim &Detailed Design

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues




HWCI ConceptFormulation, Select, & Doc.

CSCI ConceptFormulation, Select, & Doc.

Integrationand Test

Integrationand Test

PDR CDR

1 2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

cott_c13.qxd 7/5/05 1:43 PM Page 246


are two perspectives of the same process. Figure 7.8 shows the Spi-ral as Boehm created it. Figure 13.10 adds numbers along the spiralfor reference. Figure 13.11 shows the spiral overlaid on the EntityVee, illustrating their similarity. Note that the Spiral provides almostno detail in the integration, verification, and validation sequence.

APPROACH TO THE USE OF COTS AND NDI

When a project solution incorporates Commercial-Off-The-Shelf(COTS) products or Nondevelopment Items (NDI) precluding theneed for an engineering design, the Vee for COTS used in the sys-tem would descend only to the COTS or NDI component level (Fig-ure 13.12). However, off-core critical issue studies below thecomponent level are required to investigate capability, to ensure in-terface compatibility, and to determine required modifications toachieve desired performance (remember modified COTS is nolonger COTS).

In one example, a project team relied on traditional high-reliabilitypiece part and component procurement to achieve the necessary reli-ability levels. According to the project manager, “commercial diodes,transistors, and integrated circuits were prescreened prior to selec-tion (approximately 4% of all diodes, 3% of all transistors, and 1% of

Figure 13.12 The full-depth Vee is not required for a COTS entity.

cott_c13.qxd 7/5/05 1:43 PM Page 247


all integrated circuits failed the screening test). . . . Sensor reliabilityanalysis was conducted using (traditional) reliability standards toidentify potentially weak elements for replacement.”8 These risk man-agement activities are the off-core critical issue studies shown in Fig-ure 13.13.

COTS and NDI—Proper Use Leads to Success

When asked to describe the top success factors contributing to proj-ect success, three successful project managers replied with the fol-lowing factors:

Figure 13.13 Critical issues to be studied for commercial off-the-shelf (COTS) and nondevelopment items (NDI).

User

System

Segments

UserOperations

HardwareConfig Item

SoftwareConfig Item

UserOperations

HardwareAssemblies

SoftwareComponents

Hardware Parts& Processes

ComputerSoftware Units

,

Technical Aspectof the Project Cycle for

COTS and NDIComponents

User RequirementAnalysis & Agree.

Statement ofUser Need

Design ConceptFormulation &

Selection

Des. ConceptDocuments

Mission Ops ConceptFormulation, Select, & Doc

HWCI Concept Formulation,Select, & Doc

CSCI Concept FormulationCOTS & NDI Select, & Doc,

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

Concept Update

Performed at theLevel Necessary to

Identify andManage Opportunities

and Risks


CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

CriticalIssues

Concept Formulation,Including COTS, NDITrades, and Selection

SystemSpec

CapabilityDemonstration



Integrationand Test

Integrationand Test

Integrationand Test

COTS & NDIGrouping/Selection;

New Component DesignsUsed Only if

No Alternative

Detail BelowConfig Item Level*

Continues ONLY FOR:• System Integration

• New Designs

Modified User RequirementsBased on COTS Constraints


CriticalIssues

CriticalIssues

* This chart uses the Configuration Item level for illustration; COTS & NDI can be used at any level.

Critical Issues to Be Studied:• User Requirements Clarification• Operations Feasibility• Driving Technology and COTS Proven Availability• Software System Architecture “Feasibility Prototyping”• Hardware System Architecture Feasibility Models• Qualification of COTS & NDI Components in Target Environ• System Risk Analyses Including COTS & NDI• Failure Modes Analyses Including COTS & NDI• Hazards Analyses Including COTS & NDI• Completeness of COTS & NDI Solutions• Robustness of COTS & NDI Components• Supportability of COTS & NDI• Affordability Assessment• Environmental Impact

cott_c13.qxd 7/5/05 1:43 PM Page 248


1. Empowerment, where the project manager has full authorityand control (executive management didn’t meddle). The projectmanager should control the procurement process, as well; thecontracting officer or contracts administrator should be respon-sible to the project manager.

2. Leadership.3. Full willingness to seize opportunities, such as making effective

use of COTS and NDI, but insistent on understanding the case-by-case risks involved in doing so.

4. Managerial, technical, and financial skills and motivation.5. Burning desire to succeed, coupled with a passion for quality.6. Collocated team (including all the engineers and technicians)

for all essential functions.7. An environment that rewards open and direct communications.8. Preference for testing rather than analysis during development.

Build and test an engineering model.9. Reduced formal controls (on component traceability, quality,

and documentation) to the minimum acceptable—based on risk.10. A small team with clear responsibilities.

A comparison of these points with the operating procedures forthe skunk works, a highly efficient aircraft development organiza-tion, shows a significant commonality.9 The operating rules are con-sistent with the essence of good, traditional project management.The reason they succeeded is not that they abandoned obsoleteprocesses, but rather that they tailored and streamlined the projectmanagement and systems engineering processes to their needs.

In addition, one team had a well-defined quantitative risk analy-sis process. They used Monte Carlo analyses to provide data for riskmanagement decisions. Although the team did not express it thisway, the details of Figures 13.12 and 13.13 apply here.

The BUYER Project

The multimillion-dollar BUYER project is a COTS software systemto provide procurement support throughout a medium-sized com-mercial organization.

After attempting unsuccessfully to build a homegrown system inthe 1980s, a decision was made to purchase a COTS product and tai-lor it to the organization’s needs. Three unsuccessful COTS at-tempts over a decade led to project termination in 1997. Had theproject team used the concepts in Figures 13.12 and 13.13, problems

cott_c13.qxd 7/5/05 1:43 PM Page 249


would have been revealed earlier and more systematically instead ofbeing a continuous string of surprises. A list of lessons learned wascompiled, from which the following points have been extracted:

• Poor requirements lead to poor plans.• ForCOTSsoftwareprojects,use incremental,phaseddevelopment.• For COTS software, pick the product, and then pick a contrac-

tor based on its experience with that COTS product.• Use of COTS products may require performance compromise.• A COTS product is not really COTS if the vendor is modifying it.• COTS software is not really COTS if it doesn’t run on your tar-

get hardware and system software.• Involve the user in the development process.

In the first two attempts, the BUYER project failed becausethe selected COTS packages did not meet user requirements; in anenvironment of continuously changing user requirements, however,no development approach could have succeeded. In the third at-tempt to produce a system, the team finally got the necessary man-agement support to baseline a stable set of solution-independentuser requirements.

The last iteration of the BUYER project failed because, un-known to the team, key software that ran successfully in a commer-cial UNIX environment was only available in an alpha version for thenew target environment (Windows NT). The problem was not theuse of COTS, but rather the incomplete implementation of systemsengineering. The project team jumped on an attractive COTS solu-tion without performing off-core studies (Figure 13.13) to identifyand mitigate the risks associated with the Windows NT opportunity.

Intelligent, hard-working people devoted years to make theBUYER project a success to no avail. They certainly displayed aburning desire to succeed (the fifth success factor). In fact, theBUYER team did most things right, and they got close to meeting alloperational requirements. But, as the saying goes, “close only countsin hand grenades and horseshoes.” The BUYER team simply failedto implement proven systems engineering and project managementprinciples.

The Therac-25 Project

Therac-25 is a computerized radiation therapy machine used to treatcancer patients. It was first used in commercial hospitals in 1982.The goal of the manufacturer was to replace two older models with

cott_c13.qxd 7/5/05 1:43 PM Page 250


a new design that was more useful to the hospital because it com-bined both low- and high-energy modes of operation into a singleunit. It was also designed to be cheaper to produce and operate. TheTherac-25 project used Nondevelopment Item (NDI) software in itsdesign. This project is particularly relevant in considering the bal-ance of opportunities and risks, because the risks in using NDI areso often overlooked.

An excellent study of the cause of the Therac-25 failures re-ported, “between June 1985 and January 1987, six known accidentsinvolved massive overdoses by the Therac-25—with resultantdeaths and serious injuries. They have been described as the worstseries of radiation accidents in the 35-year history of medical accel-erators.”10 This 24-page article should be mandatory reading for anysystems engineer involved in reuse of hardware or software for newapplications.

The Therac-25 development used software from two earliermodels (Therac-6 and Therac-20). Both earlier systems used thePDP-11 computers (as did the Therac-25), and both older systemshad been in use for a decade without problems. Selected softwarewas used without modification in the new machine. The developerdid not recognize that this “previously developed product” was notbeing used in exactly the same way, however. Both the Therac-6 andTherac-20 models had software and hardware safety interlocks. Thenew Therac-25 had only software safety interlocks to save cost.After the Therac-25 accident investigation was completed, a reex-amination of the Therac-20 showed that the old software had exactlythe same failure mode but the hardware interlock intervened to pre-vent the hazard.

Leveson and her coauthor highlighted important lessons aboutsoftware reuse: “A naïve assumption is often made that reusing soft-ware (NDI) or using commercial off-the-shelf (COTS) software in-creases safety because the software has been exercised extensively.Reusing software modules does not guarantee safety in the new sys-tem . . . and sometimes leads to awkward and dangerous designs. . . Rewriting the entire software to get a clean and simple designmay be safer in many cases.”11 In addition, they found that, alongwith other problems, good systems engineering was lacking in theTherac-25 design and development, and proven software engineer-ing practices and processes were not followed. There was no effec-tive peer review during the Therac-25 system development phase.

The Therac development team used previously developed soft-ware to save development cost, to save development time, and tocreate a better product (the same goals sought by advocates of

cott_c13.qxd 7/5/05 1:43 PM Page 251


“better, faster, cheaper”). In this case, faster and cheaper did notlead to better.

Product Reliability

How good does the COTS product have to be? A score of 96 percent(success rate for high reliability diodes screened from a commercialline) is an excellent test score in school, but is it satisfactory for yourproject? Consider Mikel Harry’s assessment of the consequences ofan even tighter 99 percent successful performance requirement:

• 20,000 lost articles of mail per hour.• Unsafe drinking water almost 15 minutes each day.• 5,000 incorrect surgical operations per week.• Two short or long landings at most major airports each day.• 200,000 wrong drug prescriptions each year.• No electricity for almost 7 hours each month.12

Most consumer COTS products fail to some degree, whether wetalk about new cars or new Microsoft Office applications. The issuefor systems engineers to resolve is whether or not the failures are ofimportance to their project. Most people would refuse medical treat-ment from a device or medical system that had a reliability levelequivalent to current commercial software products sold for use ondesktop computers.

The COTS product being reviewed for a specific applicationmay not be suitable for its new use as it comes off the shelf. Systemsengineering has the obligation to evaluate the risks and to decide onthe appropriate actions. As the Therac-25 accidents revealed, as-sessing the suitability of a COTS or NDI solution is nontrivial.

OPPORTUNITY AND RISK ELEMENT EXERCISE

Make a list of all the risk mitigation actions that you personally prac-tice in the normal conduct of your life. Categories for considerationare: insurance (life, homeowners, liability, collision, comprehensive,umbrella, etc.), insurance deductible provisions, security (alarm sys-tems, motion detector lights, alertness, etc.), personal safety (lifevests, seat belts, roll bars, hard hats, etc.), and many others. For eachof these mitigation actions, identify the opportunity that you em-braced that forced you to incur the risk, the risk mitigation, and theresidual risk following your selected mitigation.

cott_c13.qxd 7/5/05 1:43 PM Page 252


People who prefer to live in potential disaster areas, such asf lood, forest fire, earthquake, tornado, and hurricane zones acceptthe risks and the associated costs of storm shelters and insurance.Other risks are associated with lifestyles, such as smoking or com-muting in areas with high accident rates.

An interesting exercise is to calculate the mitigation leverage forall of your insurance policy provisions, such as automobile (collision,liability, and comprehensive coverages), household (hazard provi-sions), and life insurance (smoking and other lifestyle factors).

Action Opportunity Residual

Wear seat belts Use car as Injurytransportation

Dental insurance Healthy teeth Exposure abovecoverage limits

cott_c13.qxd 7/5/05 1:43 PM Page 253

254

14PROJECT CONTROL

When launched, Intelsat 6 rocketed to its parking orbit asplanned. When signaled to separate from its booster and tofurther rocket up to synchronous orbit, nothing happened.The signal was sent, but the wire receiving the signal was notthe correct one and the correct wire did not get the signal.The failure review board concluded that, “The hardware guysmade a change and thought they had communicated thatchange to the software side of the house.” But thecommunication breakdown occurred because an establishedchange procedure was not used, the official said.1

To correct this situation, a space shuttle complete with anastronaut space walk was sent to retrieve the satellite andbring it back to Earth. Then a new Titan booster, with updatedsoftware, was used to put Intelsat 6 into the correct orbit. Thecost of skipping the change procedure (about 30 minutes ofmeeting time) was over one billion dollars. This is but onedramatic case of high-tech systems failing for low-techreasons. Unfortunately, over the years there have been anunacceptably large number of high-tech failures for low-techreasons and the rate does not seem to be decreasing.Technical project control is about eliminating these types oferrors and doing the job right the first time.

PMBOK ® GuideThis chapter is consistent withPMBOK ® Guide Sec 3.2 Moni-toring and Controlling ProcessGroup, Sec 4.5 Monitor andControl Project Work, and Sec4.6 Integrated Change Control.

INCOSEThis chapter is consistent withINCOSE Handbook Sec 5.7Control Process, Sec 5.9 Con-figuration Management Pro-cess, Sec 6.3 Technical ProjectControl, and Sec 7.6 QualityManagement Process.

There is a fear among scientists and engineers that project con-trols such as standards and process will inhibit their right to

creativity, which is their main purpose in life. Their fears are wellfounded as spurious and random creativity frequently causes proj-ects to overrun and miss important deadlines. Successful develop-

You can’t manage cost andschedule without managingthe technical content. It’swhere the time and money go.

ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

Control

Pro

ject

Sta

tus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadership

ProjectVisibility

ManagementElement 6

cott_c14.qxd 7/5/05 8:20 AM Page 254

PROJECT CONTROL 255

A tracking function is not acontrol function and can leadto project failure by giving thefalse impression that projectcontrols are in place.

ment projects are rooted in efficient solution realization from userrequirements development through deployment and operations.Project controls are designed to manage the ongoing creativitysuch that it contributes to what is needed and at the same timedoes not undermine what has already been baselined. This chapteris about focusing creativity such that it contributes to the successof the project by developing the right solution right the first timeand does so with maximum efficiency thereby conserving cost andschedule.

In 1916, Henri Fayol recognized that project control is bothproactive and reactive. “Control activities provide an opportunityfor people to take the initiative in planning against deviations[proactive], to head off forces that might cause a deviation, to makecorrections very quickly [reactive] when a deviation does occur, andfinally, to redirect the firm to capitalize on a deviation when correc-tion is less feasible.”3 Fayol referred to the final alternative as “mak-ing lemonade.”

PROJECT CONTROL IS PROCESS CONTROL

Most project management texts describe project control as compar-ing actuals to plan (status). While monitoring and tracking of costand schedule data is one step toward reactive control, it is hardlyproject control without designing and implementing the proper con-trol systems in the first place and responding with appropriate cor-rective action to significant variances.

We define project control as both proactive and reactive processcontrol, a dual system designed and implemented to reduce risk:

• Proactive baseline control.• Reactive performance control.• Proactive control of the project plan and changes to the plan.• Reactive control of variances in performance to the project plan.• Management techniques that help ensure that results happen as

planned, and that results not planned do not happen.• Corrective action taken when unplanned results do happen.

This section deals with the functions of defining and establish-ing the five essential elements common to all control systems (Fig-ure 14.1). They are:

1. Things to be controlled. The function that must be controlled toa standard of performance.

2. Control standard. The approved standard of performance.

Project control needs to beproactive and reactive and sel-dom inactive. Contrary to pop-ular opinion, reactivemanagement is essential inmanaging projects.

“A good system of controlhelps prevent undesirable sur-prises; it provides for turningthe ‘lemon’ into lemonade.”

Henri Fayol2

cott_c14.qxd 7/5/05 8:20 AM Page 255


Project baselines, business, cost,and technical.Environment, physical andbusiness.Funding, amount and timing.Hardware development process.Manufacturing process.Materials.Parts.Personnel conduct.Quality.

Control systems are designed to control achievement of the proj-ect plan. Of high importance are those controls required to managesignificant risk and process-sensitive methods such as bonding agentsand other processes where the environment and contamination can af-

PMBOK ® GuideThe PMBOK ® Guide placesproject control within theMonitoring and ControllingProcess Group. The processesof reactively controlling totheir plans are covered in:

• Ch 4 Monitor and ControlProject Work

• Sec 4.6 Integrated ChangeControl

• Sec 5.4 Scope Verification

• Sec 5.5 Scope Control

• Sec 6.6 Schedule Control

• Sec 7.3 Cost Control

• Sec 8.3 Quality Control

• Sec 9.4 Manage ProjectTeam

• Sec 10.3 PerformanceReporting

• Sec 10.4 Manage Stakehold-ers

• Sec 11.6 Risk Monitoringand Control

• Sec 12.5 Contract Adminis-tration

The proactive design of con-trol systems is not addressed.

Figure 14.1 Project control is process control.

IdentifyThings to beControlled

DevelopControl

Standard

EstablishControl

Authority

ImplementControl

Mechanism

PerformWork

Within theStandardResults

Outside theStandardResults

Detect Variance

• Visibility• Status• Corrective Action

Issues – Metrics – Tolerance

Reliability.Safety, both product andpersonnel.Security.Software developmentenvironment.Software development process.Test.Time recording.Work standards.

3. Control authority. The person or organization authorized to im-pose the standard and grant exceptions.

4. Control mechanism. The forum or technique that measurescompliance to the standard.

5. Variance indication. The identification of f laws in the controlprocess or violations of the standard.

Typical factors to be controlled:

cott_c14.qxd 7/5/05 8:20 AM Page 256

PROJECT CONTROL 257

fect the quality of the result. Mature, well-established processesshould be continually improved to achieve even higher consistency ofresults. New processes may require frequent audits to verify that theresults are as expected. As the processes mature and are proven to beconsistently reliable, the audits can be reduced and possibly elimi-nated. Examples of control functions are shown in Table 14.1.

Variance control (Figure 14.2) is designed to detect practices orperformance considered substandard. Variances can result fromf lawed implementation of standards or deviations from the stan-dards. This corrective action system relies on the management ele-ments of Visibility, Status, and Corrective Action to close thereactive process control loop. All three are required for reactivecontrol. We address each of these elements in separate chapters.

Control examples within the business baseline include sched-ule, funding, changes, personnel quality, headcount level, key per-sonnel, work practices, and ethical conduct. Personnel safetycontrol examples include high pressure, radiation, toxins, high volt-age, slippery surfaces, sharp edges, overhead clearance, stair risers,and air quality.

Process controls are needed to manage important project func-tions and to control risk. Without appropriate process controls, de-tails may get lost or overlooked. Smaller projects are oftenvulnerable due to overconfidence that the details can be informally“kept in mind.”

Lessons learned relative to controls include:

• Large projects have complex communication paths;Details get lost, misinterpreted, or overlooked.

• Geographically dispersed projects often have informal commu-nication paths;Details get lost, misinterpreted, or overlooked.

PMBOK ® GuideThe PMBOK ® Guide Sec 3.2.4Monitoring and ControllingProcess Group combines themonitoring and controlling ofproject work. Since the tech-niques and tools for determin-ing status (monitoring) areconsiderably different fromcontrolling and taking correc-tive action, we deliberatelytreat them as unique elementsbut essential for reactiveproject control.

Table 14.1 Example Control Functions

Function to Control Control Control Variance Be Controlled Standard Authority Technique Indication

Wiring Electrical code Building department Inspection Not to code— deficiency notice

Project work Contract Contract Work Out of scope administrator authorizations work

Schedule Master schedule Business manager Work Off planauthorization

Security Need to know list Security manager Guard Unauthorized access

cott_c14.qxd 7/5/05 8:20 AM Page 257


• High reliability projects must be built to exacting standards;Details get lost, misinterpreted, or overlooked.

• Long duration projects have personnel turnover;Details get lost, misinterpreted, or overlooked.

• Projects with subcontractors have communications and legalcomplexities;Details get lost, misinterpreted, or overlooked.

It follows that large, long, high-reliability projects using sub-contractors need comprehensive and effective process control.Analysis of failed projects often reveals the cause of failure tobe lack of sufficient controls or circumvention of existing controls.In short, projects with inadequate process controls usually fail.Projects having the appropriate process controls have a goodchance for success. But what is the “appropriate” level of control—the “sweet spot” where control is achieved without needlessbureaucracy?

Figure 14.2 Reactive control of variances.

ReactiveProjectControl

CorrectiveActionStatus

ProjectPlanVisibilityActivity

Case 1:No Visibility

Case 2:No Plan

Case 3:No Corrective

Action

Case 4:Desired

Approach

+ ==+

NoNo No? No?

+

No No No NoYes Yes

No NoYes Yes YesYes

Yes Yes Yes Yes Yes Yes

cott_c14.qxd 7/5/05 8:20 AM Page 258

PROJECT CONTROL 259

ACHIEVING THE APPROPRIATE LEVEL OF CONTROL

The appropriate level of control is achieved by pursuing the optimalbalance between rigidity and discretionary freedom. It ref lects andaccommodates the need for agility and baseline change by managingthose changes with a nonbureaucratic change control system. How-ever, whatever system is used must be effective and binding on allaffected parties. Configuration management, discussed in the fol-lowing section, is perhaps the best example of an optimally designedcontrol procedure.

“Ultimately, the success of a control system is determined by itseffectiveness in getting people to make the necessary modifications intheir own performance. Although the classical approach to control sys-tems assumes that people will automatically act to correct their ownbehavior when directed to do so, this does not necessarily happen.”4

Individuals may resist control systems for a variety of reasons,some of which are:

• Controls disrupt a person’s self-image (they highlight things aperson may have done poorly).

• People tend to avoid unpleasant involvement (such as behav-ioral changes).

• Goals of the control system may not have been universallyaccepted.

• Standards of expected performance may be too high.• The controls seem irrelevant, bureaucratic, or lack completeness.• An incompetent staff is administering the controls.• Team norms may conf lict with or violate company norms or

standards.

One of the most pervasive reasons for resistance to controls isthe equating of project controls with a lack of freedom. Controls,therefore, should never be arbitrary—they should make sense. Buteven the most logical controls may encounter resistance. We are in-creasingly scripted in a “zero sum” concept of personal freedom andcontrol—the more we’re controlled, the less we believe we are free.Enlightened managers know, however, that appropriate controls en-hance and focus creativity rather than inhibit it. Such controls freethe project team to be creative in finding the required solutions tothe problems at hand, rather than being distracted by the day-to-dayconfusion of deciding what the project activity should be or howthings should be done. Since this may not be the initial perception,particularly for inexperienced team members, it is the responsibility

cott_c14.qxd 7/5/05 8:20 AM Page 259


of the senior team members to gain general acceptance for the pro-cess control systems. To accomplish this, the team needs to be inti-mately involved in: process control definition and implementation;the reasons for the controls, the control activities and decisions; andaccess to relevant information at all organizational levels.

Some team members may still have to be sold on the potentialbenefits to gain their acceptance and to maintain a high level ofteamwork. In this regard, the productivity and quality improve-ments that accrue from designing, selecting, and tuning the controlsthrough team consensus can be particularly convincing.

Peter Drucker stresses the importance of congruency:

Meaningful control systems . . . are discernible and appropriate forthe complexity of the tasks being assessed and the size of the projecteffort. They are timely, simple to employ, and congruent with theevents being measured.5

Insummary,bothproactiveandreactiveprocesscontrols shouldbe:

• Relevant. Controls should never be arbitrary. Their purpose, ra-tionale, and benefits should be clear. The controls should be de-signed and selected to manage the risks of the project. Ingeneral, the more visible and larger the commitment of projectresources and the greater the human risk caused by the project,the greater the requirement for controls.

• Efficient. While designing the controls, determine the mini-mum required to assure performance. Avoid the tendency tomeasure and report information just because it’s available (suchdata tend to mask and divert attention from more importantitems). Tailor the information to the needs of the team memberswho require the data to take action. Summarize and use graph-ics wherever possible.

• Simple. Keep the controls as simple as possible while maintain-ing their effectiveness.

• Timely. Controls need to be in place and tested before they’reactually needed. The process should produce timely informationto facilitate corrective action. This means determining theproper “sampling rate” to avoid obscured visibility at one ex-treme and information overload at the other.

To be effective, project control systems must be tailored to thenature, complexity, and risk of the situation and must be in place bythe time the control is needed. There are many powerful controlssuch as configuration management or technical performance mea-

PMBOK ® GuideThe PMBOK ® Guide Sec 4.5.2Monitoring and ControllingProject Work lists the follow-ing as tools and techniques.

• Project ManagementMethodology.

• Project Management Infor-mation System.

• Earned Value Technique.

• Expert Judgment.

The outputs of the process arelisted as:

• Recommended CorrectiveAction.

• Recommended PreventiveActions.

• Forecasts.

• Recommended DefectRepair.

• Requested Changes.

Note that the project manage-ment information system andthe earned value system pro-vide visibility and status ofpast performance facilitatingreactive but not proactive con-trol as suggested by some ofthe outputs.

cott_c14.qxd 7/5/05 8:20 AM Page 260

PROJECT CONTROL 261

surement that can be very effective if implemented at the appropri-ate time. It is also important to recognize that there are situationswhen these tools are not appropriate. There are low-risk projects forwhich simple tools are adequate. In driving a car down a steep in-cline, it is appropriate to use a low gear as the primary control, buteven the most ardent controls enthusiast would not advocate drivingall the way across the United States using a low gear.

GENERAL CONTROL TECHNIQUES

General Guidelines• One person should be placed in charge of specific areas, for

example:—Project Manager: Overall project requirements.—Chief Systems Engineer: Technical requirements and techni-

cal baseline.—Business Manager: Contracts and business baseline.

• Approved artifacts must be readily accessible. This is best ac-complished by establishing a project information center or on-line repository with a responsible information manager. Thissubject is addressed in Chapter 15.

Technical Guidelines• One person must control each task.• There must be a controlled work release system.• There must be an audit for compliance with project requirements.• Variances must be negotiated with the project manager.

Cost Guidelines• Team leaders must control to their budget.• Variances must be negotiated with the project manager.

Schedule Guidelines• All team leaders must sign off on the integrated schedule and

Project Work Authorizing Agreements and control to them.• Variances must be negotiated with the project manager.

Contract Control

The buyer controls sellers to standards set by contract types and in-centives as summarized in Table 14.2.

cott_c14.qxd 7/5/05 8:20 AM Page 261


Data Control

A data manager should control contract data and approved baselineartifacts. Typical tools include a project library and a computer-based document management system.

Self-Control

Self-control operates at the most personal level. This kind of controlis infectious.

“Setting a good example” includes:

• Being on time to work and to meetings.• Demonstrating high personal standards.• Remaining centered in times of stress.• Delivering to all promises.

and controlling the pen by:

• Authoring straw-man documents.• Proposing agendas.• Recording action items.• Reviewing and signing letters.

Management by Objectives

Management by Objectives (MBOs) can supplement, or in some casessubstitute for, the Project Work Authorizing Agreements (PWAA) in-

Table 14.2 Summary of Contract Types

Type Application Control Provided

Fixed price Reliable prior cost experience Firm technical, cost, andschedule

Cost reimbursement Research or development with advancing Flexible objectivestechnology

Cost sharing Seller shares cost in return for use Result ownershipof technology

Time and material Not possible to estimate the task beforehand Labor and material rates

Labor hour Like time and material, but labor only Labor rates

Indefinite quantity Establishes price when quantity and schedule Item priceare uncertain

Letter Limited project start without completed Initial spending rate and negotiations amount

cott_c14.qxd 7/5/05 8:20 AM Page 262

PROJECT CONTROL 263

troduced earlier as the planning technique to control work authoriza-tion and release. Conversely, managing with definitive PWAAs can bethought of as MBO in its most effective form. In either approach, thecorporate accounting system should provide cost accounting down tothe task level in order to measure cost performance against thePWAA /MBO commitment and to provide early, in-process warning ofvariances and unfavorable trends.

In the absence of a WBS/PWAA system, a rigorous MBO systemcan accomplish many of their control functions. MBO is also a usefulsupplement to WBS/PWAA at a more detailed and shorter range as-sociated with short time schedules and /or the first and second levelsof the organization.

Many companies and government organizations have developedcomprehensive MBO systems. Among their primary benefits, MBOsalign individual contributions with the broadening objectives ateach level of the organizational hierarchy, starting with the topstrategic objectives. In that environment, project teams can benefitsubstantially by applying the same MBO structure to align projectteam goals down to functional unit goals and further to individualteam member goals as well.

For an MBO system to be effective and self-motivating for theuser, objectives need to be documented (typically on a quarterlyschedule) and reviewed /revised regularly (usually weekly) and indetail. An effective system is characterized by objectives that are:

• Specific, clear, and unambiguous,• Realistic, measurable, and verifiable,• Consistent with available resources, and• Consistent with company policies.

The best results are usually obtained by starting at the top lev-els. Every manager and all individual contributors draft their ownobjectives to fit with the level above while adding more detail andassumptions to represent their specific contributions. Each objec-tive needs to include assumptions, measurement means, and verifi-cation methods. Joint commitments should be negotiated amongthe parties to arrive at identical objective statements. Team objec-tives are best negotiated with the team leader in a consensus drivensession.

Embracing Micromanagement

Our Management Methods Survey reveals that micromanagement isuniversally scorned in all industries, workplaces, and in the press.Micromanagement is widely perceived as an incompetent manager

“Set a good example. It willplease some people andamaze the rest.”

Mark Twain

A loosely managed MBO sys-tem is worse than none at all.

cott_c14.qxd 7/5/05 8:20 AM Page 263


nit-picking the work of a qualified subordinate who knows better.We characterize this scenario as “Nit Management” in that the per-ceived content and the consequences of the content to the projectoutcome appear miniscule.

One of the authors was on a senior manager ’s staff when ournew boss arrived. The new boss spent two hours describing how tofill out a time card (pencil, not ink; block letters; each letter in thebox, not overlapping the edges; etc.). Since none of us had to fill outtime cards, nor had we for 20 years, this was an exercise in Nit Man-agement at its finest.

However, “the devil is in the details,” “no change is a smallchange,” and, “people must not mess up” suggest that supervisoryattention to detail may often be appropriate. TQM, Six Sigma,CMMI, and the learning organization are all about honing detailedprocesses to where results are efficient and repeatable with no“messing up.” Intel has a philosophy of “getting it exactly right andreplicating exactly.” These are all examples of “positive” microman-agement in action.

The appropriate use of micromanagement is when the risk offailure is so high that you will not be satisfied until you are person-ally confidant that it has been managed properly. Experienced air-line pilots go through a detailed checklist each time they arepreparing to take off. Hopefully, this is not because they cannot re-member how to f ly the airplane, but rather the catastrophic conse-quences of omitting a step. A few years ago one airline reexaminedtheir pref light procedures with a competitive goal to shorten theturnaround time from 45 minutes to 20 minutes. They deleted asunnecessary the step that required the pilot to initial the me-chanic’s worksheet showing the amount of fuel loaded onto theplane. This saved about five minutes in turnaround. The FAA re-ported that in the first two years after the change was made the air-line had 12 f lights that had taken off without enough fuel to reachtheir destination, forcing an emergency “unscheduled” landing at anintermediate airport. Maybe the pilot’s micromanagement of thefuel log wasn’t such a bad thing after all.

The following blunder cost the European Commission (EC)over $100 million:

A lawyer ’s failure to operate a fax machine correctly has been blamedfor the EC losing a multimillion-euro court case. The European Courtof First Instance ruled in favor of five German banks that had beenfined a total of $100 million by the EC.

In 2001, they had been found guilty of running a cartel to fix for-eign currency rates ahead of the introduction of the euro. The com-

cott_c14.qxd 7/5/05 8:20 AM Page 264

PROJECT CONTROL 265

Configuration management isoften a key project successfactor, making it one of themost important proactive con-trol processes.

panies—Dresdner Bank, Commerzbank, HVB, Beursche Verkehrs-bank, and Vereignsund Westbank—appealed this decision, and theircase was concluded yesterday.

According to the Financial Times, the European Court of FirstInstance overturned the fine because an EC lawyer who attempted tofax a 100-page document outlining the Commission’s case had acci-dentally placed it face upward in the fax machine.

This error meant the court received 100 blank pages, and the ac-tual document was not received in time. With no other legal argu-ment from the EC, the court had to rule in favor of the five banks.

With something this significant do you think micromanagementmight have been appropriate? There are many process steps thatshould have been taken. Why didn’t they make a phone call to con-firm that the fax was received properly? With something this impor-tant, why wasn’t there a second person there to assist and verify thatthe fax was being sent properly? The f lawed process was the signifi-cance, not just putting the paper in upside down in the fax machine(which many of us have done at one time or another).

Another example is the multihundred-million-dollar satellite thatfell off the test stand because tie-down bolts were missing. The issueis not that the bolts were missing, but rather that no one checked be-fore moving the satellite. This is another instance where appropriatemicromanagement would have saved the project.

Defining and following a correct process is vital to any project.Verifying that critical steps have been taken is equally important.

CONFIGURATION MANAGEMENT ANDCHANGE CONTROL

Change happens. Requirements are almost always added, deleted, orchanged. There are two ways to deal with these changes:

1. Prohibit them—not client responsive.2. Control them proactively—client responsive.

Configuration management (Figure 14.3) is the process for con-trolling the evolving project baselines in a climate of change. Itspurposes are to:

• Keep evolving baselines up to date and communicated.• Keep the business, budget, and technical baselines congruent

(Chapter 7, Table 7.1).

If the task at hand is criticallyimportant, then micromanage-ment is a technique worthconsidering.

cott_c14.qxd 7/5/05 8:20 AM Page 265


• Ensure that the evolving solutions are consistent with the base-lines.

• Manage the physical and functional characteristics of the solu-tion and its entities.

Configuration management recognizes the inevitability of changesin the business case, funding, technical requirements, and configura-tion of hardware, software, and operations. It provides the techniquesand tools to identify, control, and communicate those changes. It ac-counts for changes as they reverberate through the baselines, impact-ing technical performance, budgets, and schedules. Each time theproject successfully passes a decision gate—a point of consensus be-tween seller and buyer—the approved baselines that result are for-mally managed and subject to change management.

Common project management practice and industry standardsfocus on technical baseline management, just one critical aspect ofconfiguration management and system integrity. As defined in themargin note, system integrity encompasses the business and budgetaspects.

System Integrity: the congruency of the business, budget, and techni-cal baselines. A developing system has integrity when its baselines arein agreement or congruent, which results from establishing a balanceamong the three aspects (business, budget, and technical) at the out-set of the project and maintaining that balance as changes occur toany baseline.

The business, budget, and technical baselines in Table 7.1 are sointerdependent that project success depends on keeping them inlock step. In this context, integrity exists only when the:

Figure 14.3 Configuration management.

PMBOK ® GuideThe PMBOK ® Guide Sec4.3.2.2 Project ManagementInformation System coversconfiguration managementand change control within the Project Integration Management.

Change control is intended tomanage changes—not to pre-vent them.

cott_c14.qxd 7/5/05 8:20 AM Page 266

PROJECT CONTROL 267

PMBOK ® GuideThe PMBOK ® Guide Sec 4.6Integrated Change Controlidentifies three configurationmanagement activities:

1. ConfigurationIdentification.

2. Configuration StatusAccounting.

3. Configuration Verificationand Auditing.

• Technical baseline is managed to satisfy the business baseline(strategic and tactical objectives), and

• Budget baseline is structured to allocate resources as needed toaccomplish both the technical and business objectives.

If congruence does not exist, it means that one or more of thetriple constraints will not be satisfied and the project may bedeemed a failure.

Configuration management is based on controlling artifacts thatrange from oral statements to physical objects. The simplest forms ofwritten artifacts are dated and signed handwritten notes or white-board representations (also dated and signed). More common exam-ples are version-controlled electronic and paper specifications.Artifacts include hardware and software products with version iden-tification and certifications attesting to their “configuration.”

By definition baselines are under change control. Baselines ap-pear at the top of the architecture and then descend, consistentwith the solution decomposition, to the detailed parts, code, andprocesses used to produce the solution. The project managementchallenge is parallel elaboration of the many baselines such thatthey are:

• Consistent with, and responsive to, their parent baselines, and• Congruent with their peer baselines.

Business/Mission Baselines

The project cycle discussion in Chapter 7 explained the concept ofthe business baseline and how it represents the business approach.In considering the configuration management of the business base-line, the following artifacts may require configuration management:

Contract. Memorandum of Agreement.Business case. Schedule.Marketing plan. Schedule contingency.Mission case. Milestones.Project charter. Subcontracts.

While it’s commonplace to control these project-level artifacts, itshould also be recognized that candidates exist at every level of ar-chitecture decomposition and for every deliverable entity of theproject. Hence, parent-child traceability is required to ensureproper f lowdown, baseline integrity, and change evaluation at everylevel of the solution architecture.

The key for all project teams isto establish sound and achiev-able initial baselines and thento keep them congruent as theinevitable changes occur dur-ing project execution.

cott_c14.qxd 7/5/05 8:20 AM Page 267


Requirements definition.Concept definition.Architecture definition.Validation plan.Deployment plan.Concept specification.Verification plan.Verification procedures.

Design-to specification.Build-to documentation.Code-to documentation.Logistics support plan.Operations plan.Maintenance plan.Deactivation plan.Other necessary procedures.

Budget Baseline

The budget baseline addresses the required resources—obtainingand deploying them as needed to execute the project. It must beconsistent with, and supportive of, both the business and technicalbaselines. Like the business baseline, it too must exist at everylevel of decomposition and must be responsive to parent and peerbaselines.

In considering the configuration management of the budget base-line, the following artifacts may require configuration management:

Funding schedule. Budgets.Funding availability. Burn rate.Funding contingency. Skill mix.

Technical Baseline

The technical baseline addresses the evolution and elaboration ofthe technical solution at all levels of architecture decomposition. Thetechnical baseline is responsive to the business baseline and tends todrive the budget baseline, since that is where most of the resourcesare consumed. While it is common to manage the technical baselinereasonably well at all levels of decomposition, it is not universal tof low down the associated business and budget baselines to all ele-ments of the solution architecture.

In considering the configuration management of the technicalbaselines, the following artifacts may require disciplined management:

The major goal of a configuration management process, as dia-grammed in Figure 14.4, is to ensure that approved baselines andchanges to those baselines are in the best interest of the project.

Effective configuration man-agement—an ounce ofprevention.

INCOSEINCOSE Handbook Sec 5.9Configuration ManagementProcess and Sec 6.3 BaselineManagement provide addi-tional information on manage-ment of baselines.

cott_c14.qxd 7/5/05 8:20 AM Page 268

PROJECT CONTROL 269

Change Control

A vital element of configuration management provides the means toevaluate and approve changes to the baselines. The change controlprocess can be as simple as a phone call between two programmerswith a follow-up e-mail (part of the project documentation) orstructured as a Change Control Board (CCB). An ad hoc meeting ofthe impacted stakeholders with documented minutes lies some-where between. In any case, there needs to be an agreed to processthat ensures:

• That all impacted parties agree to the process.• That change agreements are documented and communicated.• Compliance.

It may be impractical to have a single control board for a largecomplex project, as it could easily become a bottleneck on the proj-ect’s critical path. The practical solution is to have a layered controlboard aligned with the project’s architecture. The board at eachlevel should have the appropriate stakeholders, including a systemsengineer to represent the overall and customer/user perspective.

In their chapter on managing configurations in The Wiley Guideto Managing Projects, Callium Kidd and Thomas Burgess trace themotivation for industry practices and related standards, such as EIA649 and ISO 10007, to project failures and serious deficiencies. The

Figure 14.4 Key elements of configuration management.

Configuration Management

Process

Baseline Approval

Create baselines

Change Control Evaluate &

approve changes

Baseline Management Status & verify

Communicate History & impact Business, Budget, Technical

Baseline Compliance

Audit

Augustine’s Law—No changeis a small change—drives theneed for change control.

Adjust your process to yourproject’s size, risk, complexity,and your company/customerguidelines.

cott_c14.qxd 7/5/05 8:20 AM Page 269


authors acknowledge that, while change controls are widely recog-nized as the best way to stay out of trouble, the appropriate level ofrigor is controversial. “There needs to be a documented process forchange, through which all changes must progress. The processing ofchanges through a single change board activity is where most organi-zations see unnecessary bureaucracy in the configuration manage-ment process. For this reason, it is important that clear rules existwhereby change classifications can help streamline the approval /im-plementation process, and changes that are considered minor, or lowimpact changes, can be directed to those empowered to do so.”6

The change process usually begins with a change request thatdocuments the change including the technical, budget, and scheduleimpact. The request precipitates a CCB review (Figure 14.5). Theparticipants include the managers of each affected organization. Theproject manager chairs the CCB and is responsible for ensuring that:

• The decision is informed and objective.• Each change is logged for traceability to the work package level

of the WBS.• All affected parties are notified of baseline changes.• Upper management and the customer are officially informed of

all baseline changes.• Changes requiring customer approval are forwarded to the cus-

tomer change board.

The CCB Agenda should include the following issues, whichmust be thoroughly understood for informed decision making:

• The details of the change and the need for it.• The impact of the change on the performance, design, cost,

schedule, support equipment, spares, contract, customer, andproject team.

• The impact of making the change versus not making the change.• Effectivity (e.g., date, versions, and specific units affected).

Figure 14.5 The change control board.

Usually the impact on peopleis the trickiest to assessobjectively. For this reason,the customer impact andcustomer position are twodifferent issues.

PMBOK ® GuideThe PMBOK ® Guide Sec 4.6Integrated Change Control dis-cusses the role of the changecontrol board as part of Proj-ect Integration Management.

cott_c14.qxd 7/5/05 8:20 AM Page 270

PROJECT CONTROL 271

• Documentation affected by the change.• Customer position (i.e., Is the customer supportive of the

change?)

The project manager needs to factor the customer’s situationinto the decision process. Likewise, secondary impacts on the proj-ect team need to be accounted for in schedules. For example, thedisruption resulting from redesigns are often underestimated. Con-versely, a substitution or alternative approach could eliminate asource of conf lict or risk.

Affected work authorizations must be revised to effect a change.Recognizing that a large project requires many PWAAs, rapid actionis required to avoid having people working to an obsolete baseline.The opening case of this chapter presented an example of a majorfailure caused by a poorly implemented change. Use your most ef-fective communication method to notify all affected parties that achange is forthcoming.

QUALITY CONTROLS AND TECHNIQUES

We define quality as conformance to the project’s requirements.Quality is ultimately judged by the customer and end users, not by theproject manager or other provider personnel. In this case, the cus-tomer may be any person or organization in the complete provider-customer chain extending from those internal to the project to the in-tended user.

It is the final user that determines product or service quality,that is, fitness for use. That viewpoint encompasses ease of learning,usability, serviceability, reliability, durability, and documentationeffectiveness.

Traditional Quality Assurance

The traditional approach to controlling quality (Figure 14.6) fo-cuses on the results of manufacturing operations where quality ismost visible. For example, product quality assurance consists of anorganization that screens the product (perhaps at several points inthe manufacturing process) for adherence to its specifications(Figure 14.7). Suspect material is dispositioned as use-as-is, re-work, or scrap—whichever is appropriate. Eventually, most designor process defects are recognized and corrected by the change con-trol and corrective action process.

INCOSEINCOSE Handbook Sec 7.6Quality Management Processprovides additional informa-

PMBOK ® GuideThe PMBOK ® Guide Ch 8 Proj-ect Quality Managementdescribes three processes:

1. Quality Planning.

2. Quality Assurance.

3. Quality Control.

A quality challenge is todevelop specifications that willproduce products that satisfythe customers’ expectations.

cott_c14.qxd 7/5/05 8:20 AM Page 271


A sensible and enduring standard for all industries is illustratedin Figure 14.7. Current ISO quality standards are based on thesesame sound concepts.

Total Quality Management

The need to improve profitability and to respond to increasingglobal competition have motivated both product and service in-dustries to broaden the scope of quality assurance to reach the en-tire organization at all stages of the process. TQM is:

• Required from project initiation to completion.• Required of everyone.• Applied to every process and transaction.

The quest for higher quality has been embodied in two closelyrelated practices: TQM and Continuous Quality Improvement(CQI). TQM is a sound concept that is founded on the followingthree fundamentals:

1. Everything that people do can be described as a process thatcan constantly be improved. CQI emphasizes the process—thesystem for doing things—rather than the results themselves.

Figure 14.6 Traditional quality assurance.

In many industries, quality isconsidered the foremost com-petitive success factor.

AnyProcess

Input

Output

User/Buyer

Seller

cott_c14.qxd 7/5/05 8:20 AM Page 272

PROJECT CONTROL 273

2. To produce satisfactory results, each individual must haveclearly defined expectations.

3. The person you deliver your output to is your customer and de-serves to be satisfied. Every customer has the right to reject anyunsatisfactory deliverable.

Most people are unaware of their own process and therefore donot consciously attempt to improve it for the customer’s benefit, aswell as for their own. Creating this awareness and motivation is partof the leadership responsibility of both the project manager and thesystems engineering manager.

Attention to TQM principles can enhance other control tech-niques, notably MBO. The two concepts are complementary in thesense that TQM/CQI stresses the process while MBO stresses results.

Software Quality Assurance

The Software Quality Assurance (SQA) function is responsible forauditing software development for compliance to the SQA plan. Theavailability of an audit trail, from automatically generated softwareconfigurations, enhances the efficiency of this audit that:

• Assures that prescribed development environment standards,procedures, and methods are being adhered to.

• Verifies process adequacy.• Alerts the project manager to deficiencies.

Figure 14.7 MIL-STD-9858A: Still a sensible standard for all industries.

To the extent that the projectteam is aware of, accepts, andconscientiously applies thesefundamentals:

• Project output rises.

• Failure rates decline.

• Efficiency improves.

cott_c14.qxd 7/5/05 8:20 AM Page 273


TECHNICAL CONTROLS AND TECHNIQUES

The following controls expand on the basic control techniques pre-viously described. The major selection criterion for these controls isthe risk associated with each technical area, regardless of the pro-portion of project resources it represents. In general, the value ofeach technique depends on the project type, the risk associatedwith the technologies involved, and the project complexity.

Controls Unique to Software

Software-intensive projects have historically been poorly managed.We hear excuses like, “I didn’t change that section, so there’s noneed to test it.” (Invariably, “that section” fails because of a changein another section that was tested independently.) Worse yet is theassurance, “I only changed a few lines of code, so it was easy to ver-ify manually.”

An incident that received national attention in June 1991 pro-vides a graphic example of the consequences of such “leaky” manualcontrols. The telephone services in Los Angeles, Pittsburgh, SanFrancisco, and Washington, D.C., were temporarily shut down. Thereason turned out to be a faulty software change and f lawed verifi-cation controls. A computer programmer, not understanding the po-tential consequences of his action, changed a few lines of code.Since only a few lines were changed, performance verification testsrequired by the company’s configuration management policy wereomitted. The three changed lines of software inadvertently causedthe program to generate a repetitive message saying that the systemrequired maintenance. Soon the system was swamped with suchmessages, blocking all calls.

Part of this problem is the intangibility of software until the codeis highly functional. Other factors include the rapid change in devel-opment tools and technology, coupled with the explosive growth insize and complexity of software products. Although details of theconventions, techniques, and controls needed to manage the designprocess is beyond the scope of this book, the following techniques arecommon to most software development projects, regardless of size.

Before development is started, choices must be made among themyriad software development environments. False starts can some-times be avoided by having this environment evaluated by an experi-enced expert. A Computer Resources Working Group is a namegiven to a panel established to judge the adequacy of the software

Having the developmentenvironment evaluated by anexpert can avoid expensivefalse starts.

cott_c14.qxd 7/5/05 8:20 AM Page 274

PROJECT CONTROL 275

development environment before it is implemented and at majorconversions or ports.

Two major areas requiring improvement in software changecontrols are integration and automation. Integration refers to the combination of all source, executables, objects, graphics, docu-ments, and other applications that are related. The Software Development Library is a controlled collection of software, docu-mentation, test data, and associated tools that include global re-sources common to the entire project as well as product modules. Byadding automatic generation capability, the development systemsupports the regeneration of any level or version. This level of au-tomation is capable of facilitating an automated audit trail as well,fulfilling an important quality assurance audit requirement.

The Software Engineering Institute’s capability maturity mod-els have been used for internal and external evaluation of internalsoftware process or that of software suppliers. The CMM, and its in-tegrated successor, the CMMI, appraises the software process ma-turity of an organization against criteria for five escalating levels.This is discussed in more detail in Chapters 2 and 21.

Design drawings can best be formally controlled through a sub-process of baseline controls whereby all affected disciplines approveinitial releases and design changes. It is also vital that affected disci-plines be involved in the design process itself. Known as concurrentengineering, this process was discussed in Chapter 11.

Design must be controlled for both technical requirements anddevelopment standards. Design controls occur at several organiza-tional levels with commensurate formality. Supervisors, being famil-iar with the designer, the standards, and the design interface can, ona daily basis, adjust review depth and frequency to match the risk.Formal design reviews are addressed in Chapter 7.

Peer Reviews

Peer reviews vary in rate and formality, from informal walkthroughsand “chalk talks” to formal peer group presentations. Peer reviewscan be highly effective and they can provide the additional benefitof cross training. A review board of a recent $60 million project fail-ure identified lack of effective peer review during the design evolu-tion as a significant contributing cause.

Expert reviews usually draw on objective experts from outsidethe project—often outside the organization. They occur less fre-quently than peer reviews and require considerable preparation onthe part of both reviewers and the reviewed. The customer may also

We strongly recommend peerreview on everything of signif-icance, even short memos.

cott_c14.qxd 7/5/05 8:20 AM Page 275


conduct expert reviews. The government often contracts for inde-pendent technical experts to perform ongoing reviews of risky de-velopment projects.

Failure review boards evaluating failed projects almost alwayscite lack of peer reviews as a significant contributing cause of thefailure. Peer reviews are not red teams or tiger teams, but rather asmall collaborative group of domain peers examining work accom-plished to ensure:

• Conformance to the requirements and accepted standards forthe domain,

• Sufficient thoroughness with analytical backup,• Adequate risk assessment,• Attention to details, like using the correct measurement units

(wrong units caused the failure of the Mars Climate Orbiter,which crashed into Mars), and

• Producibility.

While peer review tends to be informal in that the results aresuggestions, they are a powerful control technique as any lack of re-sponse to the suggestions should have to be justified. Many engi-neers resist peer review as they don’t enjoy having others critiquetheir work.

THE CONDUCT AND RESOLUTIONOF DECISION GATES

We defined decision gates in Chapter 7 and discussed their role inmanaging the project cycle. Their primary control objective is to en-sure that the project team has completed and has baselined all re-quired deliverables so as to avoid progressing to a phase for whichthe team is unprepared.

Decision gate conduct should lead to confidence in the project’sprogress by being:

Honest. Constructive in challenges.Open and interactive. Mutually beneficial.Helpful and supportive. Synergistic.

Each decision gate should be defined with the following criteria:

Purpose of the decision gate. Agenda and how conducted.Host and chairperson. Evidence that is evaluated.Attendees. Actions.Location. Closure method.

Pro

d uct

ivity

Effe

ctiv

enes

s

Adversarial

ConstructiveChallenge

Authoritative

DestructiveConfrontation

The slippery slopes

of communicating

Decision Gates - Attitudes

It’s easy to slip off of the bestbehavior.

cott_c14.qxd 7/5/05 8:20 AM Page 276

PROJECT CONTROL 277

The decision gate decision options are:

• Acceptable—proceed with project.• Acceptable with reservations—proceed and respond to identi-

fied action items.• Unacceptable—do not proceed; repeat the review.• Unsalvageable—terminate the project.

On successful completion of a decision gate, the appropriateagreements (usually in the form of artifacts and products of a proj-ect cycle phase) will be added to the baseline and put under config-uration management.

PROJECT CONTROL ELEMENT EXERCISE

Since controls are used to ensure responsiveness to predeterminedstandards they permeate all aspects of projects. Some controls areonly proactive while others are both proactive and reactive. One ex-ample is the tachometer in your car: it is proactive in that it has beeninstalled beforehand and alerts you when you are nearing the redline limit (the control standard). More modern systems now includeignition cutout to prevent violation of the red line limit, which is acomplete proactive and reactive control system. A traffic light isonly proactive while a building sprinkler system is designed to beboth proactive and reactive.

Develop a list of control techniques both within and external toyour project environment. Identify those that are

• Only proactive.• Only reactive.• Both proactive and reactive.

Control Technique Proactive Reactive

Traffic light X XBracing for a fall X

cott_c14.qxd 7/5/05 8:20 AM Page 277

278

15PROJECT VISIBILITY

PMBOK ® GuideThis chapter is consistent withthe PMBOK ® Guide Ch 4 Proj-ect Integration Managementand Ch 10 Project Communica-tion Management.

INCOSEThis chapter is consistent withINCOSE Handbook Sec 5.2Planning and Sec 5.7 ControlProcess.

Can there be status without visibility? Under pressure toreport favorable status, project managers are sometimestempted to look the other way, foregoing visibility. Ferdinandde Lesseps became a national hero in France based on hissuccess as manager of the Suez Canal project in the 1860s.Because of his reputation, he was chosen to head the Frencheffort to build the Panama Canal. The privately fundedconstruction began in 1881. The investors, primarily Frenchfamilies (well over ten thousand), relied on de Lesseps’glowing reports on the progress of the construction. In July1885, he announced that the canal was over 50 percentcomplete and right on schedule. He was prone to inflatereports from subordinates, sometimes reporting statuswithout any input. In fact, at the time of his 50 percent report,“less than a tenth of the canal had been dug. . . .”1 Since deLesseps lived in France and had only been to Panama once(five years earlier, before the work started), he clearly wascaught in the syndrome of reporting status without visibility.In the twenty-first century, this practice continues, asevidenced by Enron, WorldCom, and many others.

Status without visibility is irresponsible at best, and iscriminal at worst. The Panama Canal company declaredbankruptcy in 1889. De Lesseps and four directors wereconvicted of fraud in 1893 and sentenced to five years inprison. Enron officials are also experiencing prison life.

“Not only is there but one wayof doing things rightly, butthere is only one way of see-ing them, and that is, seeingthe whole of them.”

John Ruskin

The motto, “Trust, but verify,” underlies the need for accurateand meaningful visibility as a basis for managing any project.

“Trust me! I’m working on it” is a sure indicator of trouble, and awarning to go look for yourself. Visibility by itself, however, only letsyou know what the team is working on, and how busy they are. To be

ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

Control

Pro

ject

Sta

tus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadership

ProjectVisibility

MaNagementElement 7

cott_c15.qxd 6/30/05 4:05 PM Page 278

PROJECT VISIBILITY 279

useful, you must compare what you see with what is planned, whichprovides the project status covered in the next chapter. If timely sta-tus indicates deviations from plan, you now have information neces-sary to take appropriate corrective action to return to the plan. Butit all begins with visibility.

The lack of total visibility is obscurity, referred to by Robert A.Heinlein as the “refuge of incompetence” and by Vauve-Nargues asthe “realm of error.” In the project environment it is both, and con-sequently, a major cause of project failures.

Project visibility, as shown in Figure 15.1, is the means by whichthe project team and other stakeholders are made aware of projectactivity to facilitate timely statusing and effective corrective action.While its main purpose is to lead directly to reactive management,good visibility also supports proactive management by making surecontrols are in place and are effective. Visibility objectives are to:

• Determine activity.—Planned tasks.—Unplanned tasks.—Work habits.—Control processes.

• Communicate—up, down, and laterally.• Verify status—Is it as reported?• Determine and inf luence morale and team spirit—“How is it

going? Is there anything that you need?”

Project visibility is how youand your team know what’sreally going on.

Figure 15.1 Project visibility decomposition.

ProjectVisibility

Problem Detection Communications

ProcessImplementation

Variance Detection Customer Upper

Management Team

Techniques and Tools

Project Cycle

cott_c15.qxd 6/30/05 4:05 PM Page 279


INCOSEINCOSE Handbook Sec 5.5Monitoring/Assessment Pro-cess identifies that taking thepulse of actual performanceagainst planned is its mainpurpose.

Project visibility includes the facilitation of information gatheringand dissemination techniques such as:

Meetings. Glance Management.Reports. Project Information Center.Tiger Teams. Top Ten Problem List.

These techniques are driven by the timing, need, and geo-graphic location of the required data. They change as the projectprogresses through the project cycle.

GLANCE MANAGEMENT

Glance Management encompasses management-by-walking-around(MBWA) and other informal techniques used for follow-up and dailyawareness by an appropriate project member, particularly the proj-ect manager, chief systems engineer, and subject-matter experts. Wechose the name to ref lect a major visibility lesson learned. Far toomany project failures are caused by fatal problems or omissions thatcould have been detected by a follow-up “glance” by a cognizant ex-pert. Experts can instantly identify small, yet critical, details bysimply glancing at the situation. There is an appropriate Germanterm of augenblict, which means in the blink of an eye. One of theauthors had a major house renovation done, after which all six sky-lights leaked. When questioned, the contractor admitted he dele-gated the job to an inexperienced workman who failed to applyf lashing. Almost anyone would have noticed the missing f lashing inthe blink of an eye but the workman did not know f lashing was nec-essary. Quite often, that trained eye is simply a matter of experienceor a broad view of the environment, such as the case of a communi-cations system that was subject to frequent, but random errors. Thetechnical team was poring over software listings and using sophisti-cated instrumentation and troubleshooting techniques to find thecause. While surveying the site, the project manager noticed thatone of the printers had defective metal plating. Small particles ofmetal were dropping into the control unit causing spurious electricalnoise pulses.

Glance Management involves periodic sampling of work inprogress by:

• Casual questions about a project detail—perhaps in a chancehallway meeting or in the parking lot.

• Engaging in conversations before or after meetings, or atgroup functions.

cott_c15.qxd 6/30/05 4:05 PM Page 280


• Skip-level meetings sitting in on a lower-level meeting.• Quick scans of copies of routine correspondence (FYI or for

your information) for telling phrases.• Maintaining a reputation for an open door and an open mind.• MBWA—walking through the project area and actively observing.

Prior to the Challenger failure, an O-ring Tiger Team glanced atthe booster joint design and proclaimed, “Wrong application of anO-ring.” Contrary to best practices, the O-ring was not always undercompression due to a dynamically varying gap between the adjoin-ing booster structures. This same f lexing of the booster structurerendered the backup O-ring ineffective. Although a recognized con-cern for almost ten years, no corrective action was taken until afterthe Challenger accident. Had someone with authority used glancemanagement to initiate action, perhaps the Challenger failure wouldhave been avoided.

MBWA is a visibility technique with important leadership andteam-building benefits. Even though its primary purpose is to im-prove visibility, it is useful for assessing morale and for obtaininggeneral information. The MBWA method consists of stopping to talkwith team members while taking different routes through the proj-ect area. To promote openness, it is important to give answers toquestions that may be asked and to inform the appropriate managersand supervisors of what you conveyed. Be sure to diffuse politicalsituations and avoid immediate problem solving. Also be careful notto usurp the authority you have delegated to those supporting you.Here are some MBWA guidelines and protocol:

• Make plant tours—your own facility and contractor/subcontrac-tor facilities.

• Go where the action is.• See and be seen.• Observe, but do not direct.• Talk to personnel working on your project.• Verify status—spot check details and look for evidence of

work in progress (drawings completed, software in test, orparts machined).

• Use this opportunity for team building:—Show interest and ask people to tell you what they are doing

and what they might need to be more effective.—Confirm that team members understand their part in the

process.• Carefully and decisively use the information gathered. It may

be used to assist the existing management in their management

PMBOK ® GuideThe PMBOK ® Guide Ch 9Human Resource Manage-ment cites providing timelyperformance feedback as a keymanagement action.

Carefully and decisively usethe information gathered.

cott_c15.qxd 6/30/05 4:05 PM Page 281


Beware of stale data! Theinformation center must bekept current, otherwise it is oflittle or even negative value.

process or it may be used to change the existing management ifthey are found to be ineffective with no hope of improving.

MBWA can be especially effective when two or three workshifts are operating around the clock. The second and third shiftsoften feel left out of the mainstream: “Hardly anybody from day shiftever comes in.” On one such project, the project manager and mar-keting manager, separately, made periodic visits to the work areasduring second and third shifts. They were surprised by the numberof valuable inputs they received. Even more surprising was the gen-eral morale improvement that even carried over to the day shift.

On another project, the chief systems engineer used this tech-nique very effectively by deliberately parking his car in differentparking lots depending on the active phase of the project. Duringthe manufacturing phase, parking on the opposite side of the plantforced several trips through manufacturing operations during whichworkers would call his attention to various conditions and anomalies.Workers soon knew to expect the MBWA, taking pride by showingexamples of their work and being prepared with questions. When ac-tivity moved to integration and verification, the parking lot waschanged, and resulted in the same good collaboration results withthe verification team.

All glance management techniques share a common risk—givingthe impression of invasive scrutiny. Everyone dislikes being interro-gated or watched too closely. This is where leadership techniquescome into play. Glance management, especially MBWA, works bestwhen visibility is both ways—when it includes recognition, praise,and casual advice—as well as questions.

THE PROJECT INFORMATION CENTER

Any visibility system should include a Project Information Center—adedicated area or web page that displays the current status of allproject activities against the plan. The use of a name like Short CycleRoom can convey an important theme and is a constant reminder toproject personnel of the importance of schedule (Figure 15.2).

The main benefactors of the Information Center are projectpersonnel with schedule and budget responsibility and /or interest.All users benefit from this visibility at a glance. It also provides ameans for making the project more visible to stakeholders and oth-ers who may miss, or not be included in, meetings. By reviewingposted notices and selected correspondence, the observer can

cott_c15.qxd 6/30/05 4:05 PM Page 282


quickly scan for pertinent new information. The Project Informa-tion Center is an ideal location for all hands and project manager ’sreviews. On small projects, it can be the project manager ’s officeor a conference room.

An alternative implementation method is to use a web-based in-formation dissemination site with e-mail, baseline document li-braries, and search capability. However, this approach lacks theopportunity for motivation, interaction, and cheerleading providedby a dedicated physical area.

TIGER TEAMS FOCUS ON CONCERNS

In some organizations, Tiger Teams have an unearned negative rep-utation usually propagated by those who were subjected to onewithout adequate preparation. Therefore, to maximize chances forsuccess, the project team must be educated as to the purpose,methods, and expected positive use of Tiger Teams.

Tiger Teams provide focused visibility on selected areas ofconcern. Usually composed of domain experts, their purpose is to

PMBOK ® GuideThe PMBOK ® Guide Sec.10.2.2 Information Distributionsupports these concepts.

Figure 15.2 A dedicated Short Cycle Room.

NETWORK

TOP 10ASSEMBLY A ASSEMBLY C

ASSEMBLY B ASSEMBLY D

ASSEMBLY E SUBCONTRACTOR

SOFTWARE ASSOCIATE

ASSEMBLY

TESTMASTER SCHEDULE

WBS

cott_c15.qxd 6/30/05 4:06 PM Page 283


Informational

Gathering.Disseminating.Clarifying.Training.

Interpersonal

Motivating.Inspiring.Praising.Committing.

Decisional

Investigating.Consensus making.Evaluating.Decisin making.

objectively identify the problem sources and to recommend solu-tions. Solution implementation is usually the responsibility of theproject team. While anybody can suggest the need for a TigerTeam, it is usually initiated by the project manager, upper manage-ment, customer, or functional managers.

Typical areas of concern for the Tiger Team include:

Design approach. Management approach.Interface compatibility. Quality.Software approach. Cost.Schedule approach. Personnel turnover.Failures.

Tiger Teams are composed of project personnel and invited ex-perts with a demonstrated ability to accumulate the facts rapidly,objectively evaluate the status, and impartially report their find-ings. Participants may include seller and /or buyer personnel, out-side consultants, or customer experts.

The benefits of using Tiger Teams to evaluate status include:

• Objective visibility into an area of concern.• Focused approach to improve performance.• Third-party assistance in securing increased resources.• Tiger Team follow-up on success of recommendations.

Precautions when using Tiger Teams include:

• Expected use of Tiger Teams should be publicized by projectmanagement at the outset and during the course of the project.

• Tiger Teams must operate in a team (not adversarial) relation-ship with the project team.

• Tiger Teams must have “free rein.”• Project manager must stay aware and support both project and

Tiger Team personnel.

MEETINGS—THE PROJECT MANAGER’S DILEMMA

Meetings are the major vehicle for performing many management roles:

Tiger Team members shouldbe experts and “quick studies.”

Tiger Teams are for fixingproblems, NOT for fixingblame.

cott_c15.qxd 6/30/05 4:06 PM Page 284


Whether one-on-one or involving the entire project team, meet-ings are a significant technique for gathering and disseminating in-formation. As such, they can easily consume 40 percent to 60percent of a project manager ’s time. High-value meetings are criti-cal to project success. However, meetings that just waste the team’stime can result in decreased morale. For meetings to be effective,they must serve a specific, well-defined purpose.2 Too many meet-ings and poorly conceived and poorly executed ones can be a majordemotivator. When considering whether or not to hold a meeting,ask yourself:

• What is the objective of the meeting?• Is there a better way to achieve the objective?• Is this meeting really necessary?• What would the consequences of not holding it be?• How to mitigate the consequences?

We will return to the interpersonal and decisional meeting as-pects in Chapter 18. Here’s a checklist of recommended conduct:

• Distribute an agenda in advance of the meeting.• Invite only those required.• Schedule the start for an odd time such as 7:56 A.M.• State the purpose of the meeting and stick to it:

—Exchange information.—Determine status.—Solve a problem.—Make a decision.

• Start on time—don’t wait for late people.• Keep the meeting on track and control the progress.• Summarize the results and assign action items.• Follow up on action items.• Ensure that all meetings are summarized including those meet-

ings you are not responsible for.

Informational Meetings

An informational meeting is the opportunity to update the team’scollective knowledge. This knowledge includes perceptions and ex-periences as well as facts. As with traditional staff meetings, a seriesof smaller, nested meetings, as identified in Table 15.1, can be ef-fective in tailoring the information range and depth of detail to theparticular group.

Some informational objectivesare better handled by othervisibility techniques such asinformal discussions, a tele-phone call, or a memo.

cott_c15.qxd 6/30/05 4:06 PM Page 285


News Flash Meetings

News f lash meetings are used to streamline communication forschedule critical projects and to resolve issues immediately. Issuesrequiring further discussion are addressed right after the news f lashmeeting. News f lash meetings work best with a small group—usu-ally the direct reports to the project manager. Some managers preferthat all participants remain standing throughout to instill urgencyand discourage long-winded discussions. Others prefer to assignseats, making it easier to know who, or what organizations, are notpresent and to position adversaries adjacent to one another to facili-tate communication. An effective agenda is:

• What did not happened as planned?• What action is required?• What is not going to happen as planned?• What action is required?• What help is required of management?

All-Hands Meetings

All-hands meetings involve a larger group—usually the entire proj-ect team. Attendance by key personnel is mandatory. These meet-ings are typically convened to announce a major development suchas a new contract, a technical breakthrough, or the need for extra ef-fort. They offer an excellent opportunity for team building.

News flash meetings are mosteffective when conducteddaily at the start of each shiftor a few minutes before thelunch break.

Table 15.1 Examples of Informational Meetings

Type Frequency Typical Duration

News flash Daily or each shift 10 to 15 minutes

All-hands As required Several minutes to20 minutes

One-on-one Weekly One hour

Plan violators Weekly Less than 30 minutes each

Project manager's Weekly Two hoursreview

Executive review Monthly or quarterly One to two hoursCustomer review Monthly Varies—scope

dependent

cott_c15.qxd 6/30/05 4:06 PM Page 286


One-on-One Meetings

One-on-one meetings should be held weekly by every supervisorwith each direct report to exchange information and deal with per-sonal and performance issues. They are most effective when time islimited. Therefore, each employee needs to prepare a priority listto ensure that the high priority items get addressed within the al-lotted time.

Plan-Violator Meetings

Plan-violator meetings are held by the project manager to gain visi-bility. Once you understand what is going on, then this meeting ex-tends beyond visibility to include active statusing and determiningcorrective action for areas not on plan. The manager that, for theprior week, is off schedule, headcount, or budget plan must person-ally meet with the project manager. The violation, cause, and pro-posed recovery are reviewed. Subsequent meetings update therecovery process. The business manager sets the variance thresholdthat triggers this meeting. The major benefits are:

• Causes task managers to pay attention to the plan and their progress.• Provides review of previous week’s headcount and schedule per-

formance immediately following completion of the work week.• Provides for prompt response to new problems.• Keeps budget and schedule plans current.• Keeps management knowledgeable.• Lets the team know that you are paying attention and that you

really care about results.

Project Manager’s Weekly Review

The project manager ’s weekly review meeting extends beyond visi-bility to active statusing and corrective action. It involves all keyproject and functional support personnel. This meeting should beopen to executive management as well as customer personnel. Theagenda includes a thorough review of the status of the total projectto surface conf lict, areas of inaction, items awaiting disposition, andareas requiring special attention. The results include decisive ac-tions by project management. The benefits include:

• Overall view of the project.• Forum for organizational interaction to resolve project issues.

Headcount variance is oftenthe earliest indicator of moreserious problems.

cott_c15.qxd 6/30/05 4:06 PM Page 287


• Insight for support managers into project needs.• Visibility for all key participants into top project issues, con-

cerns, and problems.

It is often beneficial to hold this meeting on Friday morningsto determine what weekend effort can substantially shorten thecritical path.

Executive Management Review

The executive management review is to provide upper managementvisibility into the status of the project. It usually consists of a pre-sentation by the project’s management on the overall health of theproject. The format emphasizes accomplishments, particularly re-garding contract requirements, and the efficient use of resources.This review is the opportunity for the project manager to alert exec-utive management to bad news, potential risks, contingency plans, orcorrective action, and any additional resources required.

Customer Review

The purpose of the customer review is to provide the customer anopportunity for constructive challenge of the progress against plan.This applies equally well to contract customers and to internal cus-tomers—namely, marketing. This review can be avoided alto-gether, or reduced in content, by including the customer in theweekly project manager ’s review. As with the executive review, keyproject team members present status against plan, problems analy-sis, and recovery actions, and seek concurrence from the customeras to the approach. Well-run projects routinely generate the type ofdata needed for this meeting, therefore, little new material needsto be prepared.

TECHNIQUES FOR ENHANCING VISIBILITY

The effectiveness of some visibility techniques can be situational—a matter of management style or project environment. Here are afew that work over a broad range of situations.

Top Ten Problem List

A Top Ten Problem List heightens the visibility of the most impor-tant concerns of the customer, project manager, functional man-

Publicize names of owners ofthe Top Ten problems. It willhelp them get the priority theyneed.

cott_c15.qxd 6/30/05 4:06 PM Page 288


agers, and task managers. These problems should be coded by eachidentifier as:

• Minor—I’m in control.• Major—I need help.• Showstopper—emergency action required.

All problems on the Top Ten List need to be statused daily bythe responsible individual. The list is initiated by the task managersand propagates upward. The project manager ’s list should includemajors and showstoppers that reach that level as well as pertinentitems from the customer’s list.

Use the Walls

Walls are an excellent display board for documentation review(RFP, proposals, user manuals, etc.) or design drawings. Use coloredpaper to indicate maturity (e.g., white for first draft, yellow for sec-ond, blue for the third). This technique has several benefits:

• Entire team has visibility.• Helps identify inconsistencies,voids,overlaps,andscheduleslippage.• Highlights missing document sections.

Project Coordinators

Project coordinators augment the project manager ’s visibility forlarger projects. A coordinator is chartered as a representative of theproject manager who proactively ensures future events will occur asplanned. He or she signals problem areas and recommends solutions.Project coordinators:

• Know how the organization “works.”• Provide expediting help to project and support organizations.• Provide independent assessment of project information and sta-

tus to the project manager.• Ensure planning and milestones are satisfied.• Ensure control procedures are being adhered to.• Seek to shorten the critical path every day. A best practice is to

title the coordinator the Critical Path Manager.

Customer In-Plant Representatives

Customer in-plant representatives reside with the supplier projectteam and provide two-way visibility because they:

cott_c15.qxd 6/30/05 4:06 PM Page 289


Visibility is only the beginning.The visibility system must leadto statusing and timely correc-tive action.

• Understand customer expectations, needs, and capabilities.• Provide continuous visibility into supplier and subcontractor ac-

tivity and status.• Can arrange with suppliers to have full plant access and random

access accessibility.

The latter is accomplished by attending all in-plant visibility meet-ings and by other techniques such as MBWA. The techniques ofglance management are particularly relevant to benefitting fromcustomer visibility. A customer in-plant representative can addressitems that require guidance from the customer by immediately con-sulting with customer personnel. A secondary benefit is the escort-ing and briefing of customer visitors and their contacts.

TWENTY-FIRST CENTURY VISIBILITY TOOLS

Visibility tools include traditional devices and services such as:

Telephone. Cellular phone.Teleconferencing. Video conferencing.E-mail. Fax.Courier services. Mail.Internet. Web conferencing.

The Internet has become the most important of all visibilitytools. Bill Gates thinks so.3 So do some project managers keepingabreast of a variety of projects overseas from their U.S.-based of-fice. Photographs, taken twice a day with a digital camera and sentdaily via the Internet, keep the team informed of progress worldwideand provide focused visibility on trouble spots. The personal com-puters, together with wireless local, wide-area networks, and the In-ternet have grown into powerful visibility tools. PDAs now provideintegrated visibility through a range of phone and Internet services.

WHEN DESIGNING YOUR PROJECT’SVISIBILITY SYSTEM

Keep an open door and an open mind. The concept of visibility can-not coexist with significant secrecy, avoidance, or exclusion. Yet, thesecan take root and grow—particularly in the absence of strong leader-ship. The project manager needs to set an example by being open andwilling to seek and accept expert advice, as well as bad news.

cott_c15.qxd 6/30/05 4:06 PM Page 290


Avoid information overload. While it is better to be over-informedrather than under-informed, when carried to the extreme extrane-ous information causes overload and missed details.

Be selective. A visibility system can incorporate many tech-niques and tools. You need to determine the timing, critical need,and geographic location of the required information before design-ing and implementing the system you will use. These factors, andtherefore the techniques, will generally change as the project pro-gresses through its phases. It is important to carefully select themost cost-effective techniques and tools that get the job done.

PROJECT VISIBILITY EXERCISE

Considering your current or recent project experience, design a vis-ibility system as follows:

1. Make a geographic map of the project activity locations withtime zones.

2. Add the information f low requirements, format, and timing.3. Add any other factors inf luencing the design.

Based on this trade space, design a system including method, for-mat, and timing that will efficiently accomplish project visibility toall stakeholders.

cott_c15.qxd 6/30/05 4:06 PM Page 291

292

16PROJECT STATUS

“Would you tell me please, which way I ought to go from here?”“That depends a good deal on where you want to get

to,” said the cat.“I don’t much care where—,” said Alice.“Then it doesn’t matter which way you go,” said the cat.

* * *As the cat observed in Lewis Carroll’s Alice’s Adventures inWonderland, it doesn’t matter which way you go if you don’tknow your destination. Likewise, your current projectsituation is only meaningful from the perspective of whereyou need to be in order to reach your destination. Planningand status are inextricably linked.

Determining where you needto be in order to reach theintended destination—theessence of project status.

PMBOK ® GuideThis chapter is consistent withthe PMBOK ® Guide Ch 10Project Communications Man-agement and Ch 11 ProjectRisk Management.

INCOSEThis chapter is consistent withINCOSE Handbook Sec 6.3Audits and Reviews, and Technical PerformanceMeasurement and Metrics.

“Nothing is good or bad, butby comparison.”

Thomas Fuller1

Project status provides team members the ability to determinewhere they are against the plan—both present and projected—

and the impact of this status on the anticipated project outcome.The main objective is to identify variances that require correctiveaction in order to recover to plan. To initiate corrective actionquickly when deviations occur, the measurements must be:

• Relevant,• Timely,• Accurate,• Comprehensive, and• Compared to the plan.

Project activity without comparison to the plan may well be irrel-evant, or even diversionary, in determining the need for corrective

Statusing must accuratelyreflect reality against theplan—not how busy the proj-ect team is.

ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

Control

Pro

ject

Sta

tus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadership

ProjectVisibility

ManagementElement 8

cott_c16.qxd 7/1/05 3:55 PM Page 292

PROJECT STATUS 293

PMBOK ® GuideThe PMBOK ® Guide uses theterm monitor for the processwe describe as status.

action. For example, the project manager may proclaim the team’slong work hours and describe their dedicated efforts—even detailedwork activities. Such reporting is often confused with status and con-tributes to information overload.

An effective status process:

• Collects performance of critical metrics—matched to projectcomplexity and risk.

• Compares baseline plan to current forecast and actual to plan.• Evaluates the deterioration rate if no corrective action were

to be taken.• Tailors information to the needs of the team members inter-

preting it.

Status should be continuously known by task managers and byall levels of project management. Others who can affect projectsuccess, such as customers, subcontractors, and vendors, shouldprovide status as to their critical obligations. Brief monthly statusreports for distribution to executive management and functionalsupport managers are a necessary communication technique forthe project manager and the project team. Like many major corpo-rations, Microsoft uses e-mail to distribute and comment on themonthly project status reports. Bill Gates and other top executivesreview them in appropriate detail. Gates reviews a hundred or soprojects each month, and he “especially looks for schedule slips,cutting too many product features, or the need to change a specifi-cation.”2 The project manager creates monthly management re-ports based on detailed knowledge of the project’s status using acommon template that ensures completeness of information andease of interpretation by the recipients. This chapter discusses thestatus methods the project manager should use to orchestrate theproject to a successful conclusion.

STATUS MEANS TECHNICAL ANDBUSINESS—COMBINED

To know the health of your project, schedule, cost, and other busi-ness factors must be evaluated together with technical perfor-mance, which requires the use of performance measurementtechniques such as metrics and earned value. The following lists arerepresentative of individual metrics often considered in each of thefour factors:

cott_c16.qxd 7/1/05 3:55 PM Page 293


Schedule

Progress summary.Master schedule.Milestone accomplishments.Earned value.Assemblies and modules.Tasks.Subcontractors.Parts and material.

Cost

Actuals versus budget.Headcount.Earned value versus expendi-tures.Burn rate and overtime ratio.Estimate to completion.Estimate at completion.Profit.Dispersion ratio.

Technical

Development results.Design release.Technical review (closure onaction items).Technical performancemeasurements.Interface control.Quality.Design change rate.

Other Business Factors

Contract change process.Actions to/from customers.Actions to/from management.Actions to/from contractors.Funding.Top ten problems.Security clearances.Project manager ’s assessment.

(Note: Dispersion ratio refers to the equivalent full-time head-count divided by the number of different individuals charging tothe project.)

Although each of these factors individually provides insight intoaspects of the project, accurate status is only obtained when they areintegrated. This integration requires tying the technical results toschedule, resources, and business impact. Without this integration,decisions may degrade one factor while trying to improve another.

CONDUCTING THE MAJOR STATUS REVIEWS

This discussion relates to status reviews for the examination of proj-ect health leading to a prescription for the cure, if appropriate.While decision gates may include reviews in both their name andthe event, their purpose is approval of baseline elaboration. Statusreviews result in action items directed at fixing problems.

The following three review types can represent a significantexpenditure of team time and effort. They should be conducted as

INCOSEINCOSE Handbook Sec 6.3Audits and Reviews addressesthis area.

PMBOK ® GuideThe PMBOK ® Guide coversmetrics under the specificdomain chapters (i.e., cost,schedule, scope, quality, time).

cott_c16.qxd 7/1/05 3:55 PM Page 294

PROJECT STATUS 295

working meetings to avoid wasting time, particularly the repetitionof carefully rehearsed scenarios.

This section addresses the details of format and agenda that facil-itate the bulk of reactive management decisions. Detailed statusingdoes occur in smaller meetings—even one-on-ones—where correc-tive actions are sometimes decided. However, the project manager ’sreview is the best opportunity for all relevant stones to be turned andassumptions to be challenged. The executive and customer reviewshave two purposes: to aid visibility and provide a forum for correctiveactions that need higher level management or customer concurrenceand support. Figure 16.1 is a checklist for conducting these meetings.

EVALUATING STATUS

The foundation of status is technical accomplishment (which deter-mines the schedule situation). Whatever method is used to collectstatus, it must ref lect both the work accomplished and the accept-ability of the results achieved to date. Without the assessment ofthe acceptability of the results, the status simply measures effort(how hard the team is working) and not how effective the team is inachieving the project objectives.

Once a calibrated understanding of technical accomplishment isdetermined, the schedule status ref lects the difference between theplanned time for successful accomplishment and reality. Although adelivery or review may occur when planned, it is not “on-time” un-less it meets all defined objectives.

Likewise, the amount of resources consumed to fully accom-plish technical objectives versus the resources planned for those ob-jectives, provides the basis for cost status. Resources consumedagainst time is a measure of resource consumption, which is an im-portant factor, but not relevant to project performance.

Once accurate technical, schedule, and resource consumption(cost) are determined, the business outcomes of the project may beestimated and appropriate actions taken. The following sections pro-vide insight into how status may be taken and evaluated.

USING TPMS AND MARGIN MANAGEMENTTO OBTAIN TECHNICAL STATUS

Tying schedule and resource (cost) status to technical accomplish-ment requires effective means of determining the technical status.

INCOSESee INCOSE Handbook Sec 6.3Technical PerformanceMeasurement and Metrics(TPM).

cott_c16.qxd 7/1/05 3:55 PM Page 295

296

Project Manager Customer Executive

General announcements � � �

Awards � �

Past and future meetings � � �

Organization (optional) � �

System concept overview (optional) � �

Action items from the customer � � �

Action items from upper management � �

Internal project action items �

Master schedule with dateline and status � � �

Project milestone status � � �

Major accomplishments since last review � � �

Major customer-directed change status � � �

Engineering change request status � � �

Items awaiting customer disposition � � �

Top ten problem review � � �

Interface control action item status � � �

Systems engineering detailed status � �

Technical Performance Measurement status � � �

Engineering release status � � �

Subsystem detailed status � �

—Component by component status—Milestones accomplished vs. plan—Funds expended versus plan

Contractor/Subcontractor technical status � � �

Contractor/Subcontractor key milestones � � �

Contractor/Subcontractor detailed status by item �

—Budget, EAC, VarianceTop level cost performance vs. budget � � �

Financial status—top level � � �

—Budget, EAC, VariancePlan for handling the reported variances � �

Manpower status vs. plan—top level � � �

Funding status � �

Management reserve �

Profit analysis if internal �

Summary of new action items � � �

Key milestones for next 6 months � � �

Calendar of planned meetings � � �

Future business opportunities � if internal �

Project manager’s assessment � �

Customer’s closing comments �

Figure 16.1 Typical status agenda checklist.

cott_c16.qxd 7/1/05 3:55 PM Page 296

PROJECT STATUS 297

In new development efforts, a method is needed to give early warn-ing of development difficulties. For instance, if in the developmentof a new laptop computer, a high-speed computer chip is selectedto meet performance objectives, the higher heat load could forcethose responsible for thermal control to use a larger cooling fan,which impacts system weight, physical volume, and power require-ments. Cascading impacts such as this occur in almost every newdesign, so the risk of final system nonperformance is managed byestablishing reasonable subsystem or component margins early inthe design process. The project team should identify the drivingtechnical parameters of their system (weight, average power, peakpower, thermal limits, memory capacity, processing speed, systemsize, etc.). These key parameters are the technical performancemeasurement (TPM) set to be used to status and manage the tech-nical development.

The microrover f light experiment on the Mars Pathfinder Proj-ect made very effective use of the TPM concept.3 In their report,the authors note that, “by tracking the microrover ’s TPMs, the taskmanager gained insight into whether the delivered product wouldmeet its performance requirements. There are several methodsby which to track TPMs (i.e., system technical resources) and thetask manager chose the development-phase margin managementmethod. . . . The margin requirement is . . . expressed as a percent-age of the TPM’s allocation that declines toward zero consistentwith design maturity. One of the advantages of margin managementis that it allows management-by-exception—that is, so long as a TPMlike mass has an actual margin that is within the requirement, con-tingent risk management action is usually not needed.”

Figure 16.2 illustrates one of the TPMs (mass) used on theNASA Microrover System (Rover + Lander Mounted Rover Elec-tronics or LMRE) (the team ultimately kept track of nine TPMs).The design margin requirement (established using the good judg-ment and experience of the team) started at 15 percent when the de-sign was immature and performance predictions were speculation. Itthen dropped stepwise from 10 percent to 5 percent and finally to 1percent as the design matured and speculation gave way to actualmeasurements. As shown, at critical design review (CDR) in Febru-ary 1994, the system design was in a risk zone because the 11 per-cent actual margin violated the 15 percent margin requirement. Sixmonths later, the best estimate indicated that the mass margin hadviolated the desired 10 percent limit, and weight reduction actionsinitiated at CDR were intensified. By February 1995, the designmodifications succeeded in recovering to the desired margin. When

cott_c16.qxd 7/1/05 3:55 PM Page 297


the fully mature system was evaluated in April 1996, the margin was4 percent, easily satisfying the minimum margin target of 1 percent.Timely action 20 months earlier (in August 1994) precluded a crisislate in the system development.

The microrover team highlighted several lessons learned.“First, it was very useful to begin tracking TPMs early even thoughthere were changes in the TPMs included and their allocations.. . . Second, TPM/margin management was one of the most cost-effective risk management methods. A collection of simple graphi-cal displays made it extremely easy to see looming problems. . . .Third, . . . the right number of TPMs to track in low-cost, high-risk . . . projects is small, but . . . should include key parametersused in any operations. . . .”

DETERMINING SCHEDULE STATUS

The quantity of milestones accomplished can be used as a scheduleperformance metric (Figure 16.3). The Milestone Deficiency Re-

Figure 16.2 Microrover mass—example of a TPM status chart.

3

2.5

2

1.5

1

0.5

0

-0.5

-1

15% Margin Level

10% Margin Level

1% Margin Level

5% Margin Level

CDR Value

Month

Mas

s M

arg

in (

kg)

Jul-9

3

Oct

-93

Jan-

94

Apr

-94

Jul-9

4

Oct

-94

Jan-

95

Apr

-95

Jul-9

5

Oct

-95

Jan-

96

Apr

-96

Jul-9

6

Oct

-96

Jan-

97

Current Margin DescriptionMicrorover System (Rover + LMRE) Allocation = 16.0 kgMicrorover System (Rover + LMRE) Current Best Estimate = 15.2 kgMicrorover System (Rover + LMRE) Margin = 0.8 kg (5.0%)

cott_c16.qxd 7/1/05 3:55 PM Page 298

PROJECT STATUS 299

port (Figure 16.4) should include an estimated completion date(ECD) and a recommended corrective action for each milestonethat is past due. This way of highlighting exceptions, problems, andactions is very effective for most status measurements and report-ing. The Configuration Item Status Report (Figure 16.5) illustrates

Figure 16.3 Milestone status report.

160

190

220

250

280

JAN FEB MAR APR MAY JUN

166

165172

175199

201

222

243

263

281

180 ScheduledMilestonesCompleted

TotalMilestonesCompleted

Milestone Status

PlannedActual (Total)

Actual (Scheduled)

Nu

mb

er o

f M

ilest

on

es

Shows total projectmilestone performance

Back-up chart describeseach deficiency withrecovery plan

•

•

Figure 16.4 Milestone deficiency report.

cott_c16.qxd 7/1/05 3:55 PM Page 299


the utility of pulling together and focusing on the tasks related toeach deliverable and combined schedule, cost, and technical report-ing. Again, statusing consists of reporting exceptions and actions,not activities.

Material shortage, which is critical to status, is shown here as asummary only (Figure 16.6). A separate page should be devoted todetailing each problem with actions completed and still open.

Before covering several comprehensive metrics for statusingproject cost, consider a simple headcount cost indicator for payroll-intensive projects (Figure 16.7). As with other areas, there are sev-eral formats and metrics for statusing headcount. Typicalparameters include part-time headcount ratios, on loan, and specificskill levels.

In this example, the project manager can use Total and Experi-enced headcount metrics to anticipate efficiency, cost, and scheduleproblems, because:

• Total personnel are exceeding plan.• Experienced personnel are under plan.

With these expectations, the project manager should increase the ex-perience or proficiency of the team.

The Top Ten Problem Summary (Figure 16.8) is a tool to high-light major problems which may result from a combination of fac-tors. These can become worry lists and a place to track unsolvable

Figure 16.5 Configuration item status report.

cott_c16.qxd 7/1/05 3:55 PM Page 300

PROJECT STATUS 301

The percentage method basedon interim milestone accom-plishment is as accurate as 0to 100 and requires fewercharge numbers.

problems, but small problems solved may prevent future large ones. The summary should include the ECD, the number of weekson the list, and the identity of the responsible person. A detailedchart should cover actions competed to date and actions plannedwith dates.

Figure 16.6 Material shortage list.

PartNumber

PartType Quantity Vendor Next

AssemblyNeedDate

PromDate

Resp.Individ. Action

Visit vendor factory to pick up partsin person; daily phone calls to verifyprogress of tab and test of parts.

Firmware coding requirementsclarification to be delivered to vendorby 10 Sept. Check out tests to bewitnessed by our QA and engineeringat vendor facility.

103-231

621-040

Elect.

Firm-ware

42

1

Viking

S/WCreations

1040

7131

26 Sep

26 Sep

10 Oct

15 Oct

Fred H.

Jenny C.

The last part inpaces the project.

Figure 16.7 Headcount variance report.

cott_c16.qxd 7/1/05 3:55 PM Page 301


PERFORMANCE MEASUREMENT SYSTEMSQUANTIFY THE SERIOUSNESS OF VARIANCES

Unless you are an accountant, it is very hard to see trends in tabulardata. With graphical displays, significant items become vivid andtrivial data can be appropriately obscured. Tufte, in his excellent1983 work on the visual display of data, uses two figures that empha-size the value of graphics in detecting trends (Figures 16.9a and b).

Figure 16.8 Top Ten Problem Summary.

Figure 16.9a Anscombe’s quartet. All four of these data sets are described by exactly the same linear model. Used

by permission. © Edward Tufte, The Visual Display of Quantitative Data, Cheshire, CT: Graphics Press, 1983.

I II III IVX Y X Y X Y X Y

10.0 8.04 10.0 9.14 10.0 7.46 8.0 6.588.0 6.95 8.0 8.14 8.0 6.77 8.0 5.76

13.0 7.58 13.0 8.74 13.0 12.74 8.0 7.719.0 8.81 9.0 8.77 9.0 7.11 8.0 8.84

11.0 8.33 11.0 9.26 11.0 7.81 8.0 8.4714.0 9.96 14.0 8.10 14.0 8.84 8.0 7.04

6.0 7.24 6.0 6.13 6.0 6.08 8.0 5.254.0 4.26 4.0 3.10 4.0 5.39 19.0 12.50

12.0 10.84 12.0 9.13 12.0 8.15 8.0 5.567.0 4.82 7.0 7.26 7.0 6.42 8.0 7.915.0 5.68 5.0 4.74 5.0 5.73 8.0 6.89

N = 11mean of X’s = 9.0mean of Y’s = 7.5equation of regression line: Y = 3 + 0.5Xstandard error of estimate of slope = 0.118t = 4.24sum of squares X – X = 110.0regression sum of squares = 27.50residual sum of squares of Y = 13.75correlation coefficient = .82r2 = .67

Meaningful statusing dependson accurate and completeinformation.

cott_c16.qxd 7/1/05 3:55 PM Page 302

303

Figure 16.9b Graphical display. Used by permission. © Edward Tufte, The Visual Display of Quantitative Data,

Cheshire, CT: Graphics Press, 1983.

10

5

2010

III IV

III

Figure 16.9c Solar radiation and stock prices. Used by permission. © Edward

Tufte, The Visual Display of Quantitative Data, Cheshire, CT: Graphics Press, 1983.

–.012

–.010

–.008

–.006

–.004

–.002

Normal

+.002

Cal

ori

es p

er s

q. c

m. p

er m

inu

te

New York Stock Prices

Solar Radiation

London Stock Prices

Jan. Feb. Mar. Apr. May June July Aug. Sep. Oct. Nov. Dec.

A

B

C

700

650

600

550

500

450

400

350

145

152

156

160

164

168

Lo

nd

on

New

Yo

rk

cott_c16.qxd 7/1/05 3:55 PM Page 303


He also warns against plotting data if it has no significance, as shownin Figure 16.9c.4

In his 1997 book, Visual Explanations, Tufte revisits the infor-mation presented to the Launch Review Board on the night beforethe fatal 1986 space shuttle Challenger launch.5 He makes a strongcase that the way the data were displayed obscured significant facts.It is worth reviewing Tufte’s displays to help you consider how toimprove the display of information.

Comprehensive performance measurement systems like earnedvalue quantify the seriousness of the problems you should haveknown about and acted on much earlier. Performance measurementsystems vary widely, depending on the organization’s managementinformation system and the techniques and tools available to theproject. For highly effective status systems, time reporting to taskcodes is required to track the funds. In rapid growth years, manycompanies—especially technology start-ups where cost to capture amarket is of little concern—may use crude, qualitative systemsbased on headcount estimates only. It is interesting to note that, ongovernment projects, time reporting to the task level is manadatoryall the way to direct charging managers. Figure 16.10 illustrates acost status chart that fails to provide sufficient detail to decide oncorrective action because schedule performance and technical mile-stone achievements are not included.

Figure 16.10 Superficial cost status.

cott_c16.qxd 7/1/05 3:55 PM Page 304

PROJECT STATUS 305

EARNED VALUE TIES STATUSTO PLANNING

As competition increases and profit margins shrink, most orga-nizations recognize the need to refine their performance measure-ments. Some commercial companies and many government agenciesand their contractors use a system similar in framework to the onewe describe here. This type of system requires detailed planning topredict cost and schedule expectations and interim milestones foreach task. The insight provided is worth the effort, if the data areconstructively used. In our experience, they’ve proven their valueon projects with a budget as small as $500 thousand.

Earned Value Management (EVM) systems objectively evaluatestatus by comparing the budgeted value of work scheduled with the“earned value” of physical work completed and the actual value ofwork completed:

• EVM relates time-phased budgets to project tasks.• EVM integrates cost, schedule, and technical performance.

Figure 16.11 illustrates the primary EVM elements.When applied effectively as described here and in Chapters 8

and 11, the power of earned value as a predictive and preventivetool is available to be tapped. When used only as a status tool, how-ever, the earned value approach will not earn its own value andcould even contribute to project failure.

Garbage in—Garbage out.Meaningful statusing dependson good planning. Poorlyplanned projects simply can-not be statused.

Figure 16.11 Earned value management system elements.

PMBOK ® GuideEarned value terminology istransitioning to PV, EV, and ACnomenclature to simplify theacronyms. Both sets of termsare in the PMBOK ® Guide.

cott_c16.qxd 7/1/05 3:55 PM Page 305


BCWS Budgeted costof work sched-uled.

The planned budget forthe scheduled work.

Planned value(PV).

BCWP Budgeted costof work per-formed.

The planned budget forthe completed work.

Earned value(EV).

ACWP Actual cost ofwork per-formed.

Actual cost of perform-ing the completed work.

Actual cost(AC).

BAC Budget atcompletion.

The planned budget forall the work (a manage-ment reserve is often sub-tracted from thecontracted or committedfunding to arrive at aproject budget).

EAC Estimate atcompletion.

Estimated total costupon work completion.

ETC Estimate tocomplete.

Estimated remainingcosts to complete thework.

The PMBOK® Guide uses the somewhat less precise vocabularyshown in the last column.

Cost and schedule variances can both be expressed as dollarsor percentage. Using the definitions that follow, negative indicatesan overrun:

In Dollars In Percent

Cost variance BCWP − ACWP (BCWP − ACWP)/BCWPSchedule variance BCWP − BCWS (BCWP − BCWS)/BCWS

The alternative methods for estimate to complete (ETC) and es-timate at completion (EAC) are:

Performance projections.Managerial judgment.Bottom up (grass roots).Statistical projections.

Performance projections assume that performance will continueat the same rate:

PMBOK ® GuideThe PMBOK ® Guide Sec 7.3.2Cost Control provides earnedvalue terminology and equations.

cott_c16.qxd 7/1/05 3:55 PM Page 306

PROJECT STATUS 307

Managerial projections for ETC are a matter of judgment. Typi-cal methods are:

• Original budget plan to go (if original plan is valid).• Current burn rate multiplied by the estimated time to complete

(if these factors are reliable).• Burn rate multiplied by schedule slip plus the original plan in-

cluding normal personnel roll off for project shut down.• Performance factor multiplied by the original budget plan to go

(if efficiency rate is expected to continue).• New bottom-up quote (scrubbed—if time permits since person-

nel will stop work to produce it).• The EAC is determined by adding the ETC to ACWP.

There are several negotiable options for measuring work prog-ress, expressed as the earned value (BCWP) by task. Four commondefinitions are listed next:

Option Amount of Task BCWP (Earned Value)

0–100 Zero until task completion. (For this method,work packages should be small, probably lessthan 100 hours.) Distortion can occur sinceearned value is zero up until the task is complete.

50–50 One-half of Task BAC at start; final one-half isearned at completion. Distortion can occur sinceearned value is 50 percent at start with no workactually accomplished.

Percentage Percentage of Task BAC based on interim mile-stones or task leader ’s estimate (BCWP at com-pletion = Task BAC). For this method, workpackages can be two to three times larger thanthose for the 0–100 option but require interimprogress measurement milestones to achieve ac-curate status.

(ACWP) (BCWP)

ETC = (BAC – BCWP) ×

EAC = ACWP + ETC

The 0 to 100 method is effec-tive for small work packages.On large projects, there is asignificant administrativeeffort required to manage theindividual task cost accounts.

The percentage method basedon interim milestone accom-plishment is as accurate as 0to 100 and requires fewercharge numbers.

cott_c16.qxd 7/1/05 3:55 PM Page 307


Level-of-Effort BWCP is earned as effort is expended (BCWP =BCWS at any time). Used for level of efforttasks (should not exceed 10 percent to 15 per-cent of the total contract value).

These examples of using the 0 to 100 and percentage earnedvalue (Figure 16.12) are shown here for the same three tasks. Theearned value of the 0 to 100 option is distorted, since the secondtask is incomplete at the status date. The task earned value beingzero makes the total look like bad news. In reality, the news is good.For the 0 to 100 method to be effective, the tasks should start andend within the reporting period so unfinished tasks will not distortthe progress measurement.

The percentage example shows a more accurate status. With thismethod, the data reliability depends on the task leader ’s ability toaccurately assess status of work progress. The preferred approach isto set interim milestones with accomplishment values and earnedvalue accrued when milestones are satisfied, thereby eliminating theneed to estimate percent complete. The assessment of software prog-ress can be more difficult. The downloadable files available with thisbook include a set of spreadsheets for calculating earned value forsoftware tasks. The forms automatically calculate percent completebased on the Xs appearing in the appropriate cells as entered by theprogrammer.

INTERPRETING THE TRENDS

In the previous sections, we selected charts that exemplify the keyfactors to status. These illustrations also provide templates that are

Figure 16.12 The 0-–100 and percentage methods compared.

Interim milestones increasemeasurement accuracy.

cott_c16.qxd 7/1/05 3:55 PM Page 308

PROJECT STATUS 309

adaptable to most projects. The performance of individual workpackages is summed up to measure the aggregate performance ofmajor WBS elements and the overall project. But status shouldn’t bestatic. You need to pay careful attention to the trends, such as thosein Figure 16.13, which can be leading indicators of trouble.

Two helpful indicators for trend analysis are CPI and SPI:

Cost Performance Index (CPI) = BCWP/ACWPSchedule Performance Index (SPI) = BCWP/BCWS

Both CPI and SPI can be calculated cumulatively or for themost recent period. Both are helpful for f lagging problems. Theseare interpreted in eight separate performance trend examples (Fig-ure 16.14).

Timely, comprehensive project status information is important be-cause it enables you to identify variances and quantify their seriousness.

Differences between planned and actual results need to be re-viewed on at least a monthly basis, but weekly is advisable. Vari-ances that exceed predetermined thresholds should be analyzedfurther to determine the reasons and the actions required to im-prove performance and recover to plan. The thresholds depend onthe specific metrics. Example thresholds are:

± 20 percent and ± $20 thousand for the current period.± 10 percent and ± $40 thousand for cumulative amounts.

Figure 16.13 Trends provide leading indicators.

If you can’t measure it, youcan’t manage it!

cott_c16.qxd 7/1/05 3:55 PM Page 309

310

Figure 16.14 CPI and SPI trend analyses (may display

cumulative or measurement period trend).

cott_c16.qxd 7/1/05 3:55 PM Page 310

PROJECT STATUS 311

Variance analysis reports need to be specific as to variancecause. Figure 16.15 illustrates the status for an example task, to-gether with the corrective actions, the subject of the next chapter.

PROJECT STATUS ELEMENT EXERCISE

Considering your current or recent project experience, evaluate theeffectiveness of the status metrics used. Based on the evaluation,recommend additional metrics to aid in navigating the project.

Figure 16.15 Status report example.

Actual Metric Importance

Headcount Accomplishing staffingBurn rate Funds consumption

Desired Metric Importance

Time to next milestone Keep eye on the ballOpen action items Keep in field of view

cott_c16.qxd 7/1/05 3:55 PM Page 311

312

17CORRECTIVEACTION

There are many pressures to keep a project on schedule. Inorder to avoid admitting to a schedule slip, appropriate andtimely corrective actions are sometimes delayed oreliminated altogether. Engineers were not allowed to pursueefforts to understand why some test data during the HubbleTelescope development evidenced that the mirror metrequirements, while conflicting tests (on prior testequipment) indicated defects. The already overrun programcould not “afford” the delay. Everything was assumed to befine until eight years later when the telescope was put intoorbit and first operational use revealed the defect previouslydetected in ground tests. Similarly, engineers were disturbedthat the space shuttle booster field joints deformed differentlythan expected when under motor combustion pressure. Theytoo were told that lack of funding prohibited furtherinvestigation. One joint subsequently failed on Challenger.

PMBOK ® GuideThis chapter is consistent withthe PMBOK ® Guide treatmentof corrective action within theindividual knowledge areas ofscope, time, schedule, cost,quality, and so on.

INCOSEThe INCOSE Handbook treatscorrective action similarly tothe PMBOK ® Guide. Webelieve it warrants specialattention as the culmination ofplanning, visibility, and status.

CORRECTIVE ACTIONS ARE TAKENTO FIX VARIANCES

Corrective actions are the valid and necessary reactive managementactions to correct unacceptable variances detected (usually throughstatusing techniques) (Figure 16.15). Assessing status without fol-lowing through with corrective action is meaningless. Therefore, theprocess described in this section—corrective action—usually takesplace as a result of statusing.

Data have finally come to light that might explain the mysteri-ous sinking of the USS Scorpion submarine. The evidence is strong

PMBOK ® GuideThe PMBOK ® Guide differenti-ates between correctiveactions (bringing future perfor-mance in line with the plan)and preventive actions (actionsto manage the probabilityand/or impact of issues—something we treat in opportu-nity and risk management).

ProjectRequirements

Opportunities

and Risks

Corrective

Action

Organization

Options

Pro

ject

Tea

m

Pro

ject

Pla

nnin

g

Project

Control

Pro

ject

Sta

tus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadership

ProjectVisibility

ManagementElement 9

cott_c17.qxd 6/30/05 4:02 PM Page 312

CORRECTIVE ACTION 313

that a battery in a Mark 37 torpedo burst into f lames when a tinyfoil diaphragm, costing pennies, ruptured in the battery. The crewof 99 died when the sub sank in May 1968. Earlier that year, a bat-tery diaphragm failure occurred in a torpedo battery in a test laband six people were sent to the hospital. Tracing back to 1966, theNaval Ordnance laboratory had bypassed its own safety and accep-tance procedures in order to meet the demand for torpedo deliver-ies (with their batteries installed) to the f leet. The diaphragm wasknown to be a poor design and was difficult to make. Yield from onesupplier was so low that 250 batteries had to be “accepted” despitefailing required verification tests. One of the 250 batteries explodedin the laboratory. The ongoing “corrective action” was to deny that aproblem existed, to continue with deliveries to the f leet, and to dis-cipline anyone who tried to link any operational problems to theprocuring command. It is presumed that one of the 250 explodedaboard Scorpion.1 A safe diaphragm design was introduced in 1969.

Commercial products also find their way to the marketplacewith design defects. Children’s toys are often subject to recall forchoking hazards, cars are recalled for mechanical or safety defects,software products are released for sale—followed shortly by bugfixes. Many of these defects are discovered in the development orverification process, but timely corrective action is often not taken inorder to be first to market. However, producers of consumer prod-ucts are increasingly being held accountable for consequential dam-age caused by defects, such as poorly designed car seats for children.

Future investors will not be silent about an online trading com-pany’s liability when Internet trading is shut down for four daysdue to the online company’s software problems. This happened in 1999 when incomplete testing of software changes caused theshutdown. In another situation reported by the Associated Press,“sports equipment maker Shimano American Corporation agreedto pay a $150,000 civil penalty to settle allegations that it failed toreport in a timely manner bicycle crank defects that caused 22 in-juries.” The cranks were put on more than 200 models of mountainbikes over a two-year period.

Corrective actions may indeed have impact on project cost orschedule, especially if design f laws are not found until the product(hardware or software) is in final system verification or in opera-tional use. The objective is to find problems early and fix themswiftly and completely. Schedule pressures, optimism, and the pres-sures by customers or management for the project manager to “goalong with the crowd” are real issues that make effective correctiveaction easy to talk about but sometimes difficult to do.

Statusing is comparing currentperformance to the plan—cor-rective action is doing some-thing about the difference.

PMBOK ® GuideThe PMBOK ® Guide identifiescorrective actions (and occa-sionally preventive actions) asoutputs of the nine knowledgeareas.

The goal is to find problemsearly and fix them completelyand correctly—the first time.

cott_c17.qxd 6/30/05 4:02 PM Page 313


In theory, if there is sound visibility and a solid plan, the only timea project status meeting would be required is when corrective action isnecessary, as determined by a continuously available status system.Generally, those team members who are on plan would not need to at-tend such meetings. In practice, however, periodic status meetingswith key team members are valuable, even if visibility and status sys-tems appear to be sound and the project is on plan. Status meetingsallow the team to see the project as a whole, and omissions—in projectintegration, for instance—can be identified and corrected early.

The effective use of positive reactive management considersmany of the same attributes as an automatic control system or servo-mechanism (depicted in Figure 17.1):

• Fidelity—detection and accuracy.• Disturbances—irrelevant data.• Noise level—false input.• Time lag—timeliness and validity.• Lead time—early detection.• Gain versus stability—too much gain can produce overreaction.

Corrective Action begins with periodic variance analysis toidentify significant differences from the plan. The period andthreshold for action is proportional to the criticality to the project.Near-term critical issues may need to be statused daily with tightthresholds while noncritical issues are relegated to monthly status-ing with broader thresholds. The business manager should determinethe periods and thresholds. Cost thresholds should be expressed inboth percentage and absolute terms—say, for example, 20 percent or$20 thousand for current periods and 10 percent or $40 thousand forcumulative measurements.

Schedule thresholds could vary widely, depending on the time re-maining to task completion and whether the task is on the criticalpath, a low-slack path, or a high-slack path. A one-week slip is a rea-sonable threshold for a critical milestone with one year to completion.

Figure 17.1 Corrective action closes the control loop.

Budget underruns may bemore critical than overruns.

Repeated schedule slipsrequire special attention, lestthey become the critical path.

cott_c17.qxd 6/30/05 4:02 PM Page 314


DETERMINING THE CORRECTIVE ACTION

Approach

1. Analyze the problem:• The current impact.• The impact growth if no action is taken.

2. Prioritize all project problems from the most serious to theleast serious.

3. Determine the best approach for each using the analytical deci-sion process.

In determining the “best” corrective action, classical root causeanalysis is applicable. It consists of seeking answers to:

• What has changed from before the problem to after the problem?• Were expectations unreasonable?• Was the plan wrong?• Were requirements ill defined?• Were resources insufficient?• Was there a lack of interest?• Was there conf licting direction?• Were communications faulty?

Identify Corrective Action Candidates

Cost overrun corrective actions seek to reduce:

• Requirements.• Labor rates and /or hours.• Overtime.• Project length.

More imaginative cost options are to:

• Develop a more producible design.• Install more efficient processes.• Eliminate waste or superf luous tasks.• Assign work to lower labor rate areas.

Schedule overrun corrective actions add:

• Work shifts and /or overtime.• Personnel.

and improve:

• Tools.• Processes.• Network (shorten critical path).

Problems may have severalunderlying causes.

$

Corrective actions should deci-sively solve the problem. Theymay require outside-the-boxcreativity.

cott_c17.qxd 6/30/05 4:02 PM Page 315


More imaginative schedule options are to:

• Overlap tasks.• Use higher skilled personnel.• Send work to high-efficiency specialty shops.

Technical corrective actions seek to resolve shortcomings:

• Add Tiger Team review.• Challenge requirements.• Reduce quantities.• Add skilled talent.• Add more capable tools.• Improve supplier(s).• Add training.

Business corrective actions seek to improve the business process andeliminate bureaucracy. They involve:

• Experts.• Consultants.• Executive management.• Customer involvement.

Select the Highest Value Solution

Selecting among alternatives, like any difficult decision process, mayrequire an objective selection system. First, establish evaluation cri-teria (musts and wants). Then assign relative weighting factors andscore the alternatives against the criteria. Figure 17.2 illustrates anapproach for selecting schedule recovery action.

The tentative choice is usually the highest scoring alternative.However, the evaluation criteria and weighting factors, being some-what subjective, may lead to a close, but biased, decision. A tech-nique to evaluate the tentative decision is to assess other factors notcontained in the decision criteria. Compare that assessment of im-plementing the tentative choice with the closest alternative(s). Theprocess should also consider the consequences of doing nothing dif-ferent—always an alternative worth evaluating. It is important todocument the decision analysis for later justification.

Once the decision is made:

1. Develop an implementation plan.2. Get the commitments.

The project manager approves the decision and is responsiblefor the timely implementation of the corrective action.

In some cases, taking no cor-rective action may be the bestof the alternatives.

cott_c17.qxd 6/30/05 4:02 PM Page 316


Expensive expert consultantsmay be a real bargain . . . ifthey eliminate schedule slipsduring high “burn-rate”periods.

SUCCESSFULLY IMPLEMENTINGCORRECTIVE ACTION

The most prevalent error in reacting to variances is that corrective ac-tion is usually applied too little, too late, and with insufficient vigor.Problems must be dealt with promptly, decisively, and completely.

• Problems prevented are least expensive.• Problems solved quickly are cheaper than delayed solutions.

Other common errors are:

• Corrective action is insufficiently imaginative to consider all vi-able options.

• The effect of labor burn rate and schedule slippage is usu-ally ignored.

Problems that occur during high burn-rate periods are expen-sive (Figure 17.3). Extraordinary action may be justified to elimi-nate high burn-rate slippages. If too many critical path activities arein variance, or if the burn rate renders the variances nonrecover-able, it may be necessary to redefine the baseline plan since the cur-rent plan may be unachievable.

Figure 17.2 Evaluating alternatives by weighted scoring.

Some problems require majoractions.

cott_c17.qxd 6/30/05 4:02 PM Page 317


To ensure that all viable corrective actions are considered:

• Identify the total problem and impact.• Develop alternative courses of action as straw man solutions.• Select the highest value alternative.

Finally, to ensure that the plan is successfully implemented:

• Seek team consensus for the solution.• Develop the implementation plan.• Announce the plan.• Status and control the corrective action plan along with the

baseline plan.

CORRECTIVE ACTION ELEMENT EXERCISE

Considering your current or recent project experience, list all of thecorrective actions you observed. Try to identify some in each of thecategories of business, budget, and technical. Also critique how suc-cessful they were.

Figure 17.3 The high costs of schedule slips.

Act

ivity

Leve

l (bu

rnra

te)

Time

Implementation OperationsStudy

SCHEDULESLIPS HEREARE COSTLY

Re-baselining the project isoften the first task of the“new” project manager.

CA Technique Objective Success Rating

Tiger Team Problem solving 9

Overtime Shorten schedule 10

cott_c17.qxd 6/30/05 4:02 PM Page 318

319

18PROJECTLEADERSHIP

“We all need to be ready for those moments when ourleadership is on the line and the fate or fortune of othersdepends on what we do.”1 With this introduction to TheLeadership Moment, Michael Useem tells nine grippingleadership stories and draws out the following principles:

Know yourself: Understanding your values and where youwant to go will assure that you know which paths to take.

Explain yourself: Only then can your associatesunderstand where you want to go and whether they wantto accompany you.

Expect much: Demanding the best is a prerequisite forobtaining it.

Gain commitment: Obtaining consensus before a decisionwill mobilize those you are counting on after the decision.

Build now: Acquiring support today is indispensable ifyou plan to draw on it tomorrow.

Prepare yourself: Seeking varied and challengingassignments now develops the confidence and skillsrequired for later.

Move fast: Inaction can often prove as disastrous as ineptaction.

Find yourself: Liberating your leadership potentialrequires matching your goals and talents to the rightorganization.

Remain steadfast: Faith in your vision will ensure that youand your followers remain unswerving in pursuit of it.

PMBOK ® GuideThe PMBOK ® Guide Sec 1.5.5Interpersonal Skills identifiesleadership as a skill needed forinterpersonal relationshipmanagement along with:

• Effective communication.

• Influencing the organization.

• Motivation.

• Negotiation and conflictmanagement.

• Problem solving.

ProjectRequirements

Opportunitiesand Risks

Corrective

Action

Organization

Options

Pro

ject

Team

Proj

ect

Plan

ning

Project

Control

ProjectVisibility

Pro

jectS

tatus

ProjectLeadership

ProjectLeadership

Pro

ject

Lea

der

ship

Pro

ject

Lea

der

ship

Project Leadership

Project Leadership

ManagementElement 10

INCOSEThe INCOSE Handbook Sec 1.7Systems Engineering Has aHuman Orientation cites lead-ership as essential for systemsengineering, but does notexpand further.

cott_c18.qxd 6/30/05 4:01 PM Page 319


“The only way in which any-one can lead us is to restoreto us the belief in our ownguidance.”

Henry Miller

Leadership is primarily a high-powered, right-brain activity.

Leadership includes lifting aperson’s vision to highersights.

THE ESSENCE OF LEADERSHIP:VISION AND ACTION

To paraphrase the author in his conclusion to The Leadership Mo-ment, examining the behavior of strong leaders teaches us to thinkmore strategically and act more decisively. “By watching those wholead the way—as well as those who go astray—we can see what worksand what fails, what hastens our cause or subverts our purpose.”

In its role as the uniting management element, the proper appli-cation of leadership must ensure that the other nine elements are ac-cepted, passionately supported, and faithfully implemented. In thischapter, we address three primary aspects of project leadership:

1. Techniques for inspiring and motivating individual and teamperformance.

2. Situational leadership—the relationship of leadership tomanagement.

3. Style—determining and communicating your leadership style.

In the context of project management, leadership represents theability to inspire—to ensure that project members are motivated—on both the individual and the team levels. Several leadership pro-fessionals, quoted here, have captured the essence of inspirationand self-motivation. Regarding self-motivation, Peter De Vries wrylycommented, “I write when I’m inspired, and I see to it that I’m in-spired at nine o’clock every morning.”

As Peter Drucker defines it, “Leadership is not a magnetic per-sonality—that can just as well be a glib tongue. It is not ‘makingfriends and inf luencing people’—that is f lattery. Leadership is lift-ing a person’s vision to higher sights, raising a person’s performanceto a higher standard, building a personality beyond its normal limita-tions.” He contrasts leadership, “doing the right things,” with man-agement, “doing things right.”2

Stephen Covey reminds us that management is clearly differentfrom leadership. “Leadership is primarily a high-powered, rightbrain activity. It’s more of an art; it’s based on philosophy. Manage-ment is the breaking down, the analysis, the sequencing, the specificapplication, the time-bound left-brain aspect of self-government.”His own maxim of personal effectiveness: “Manage from the left;lead from the right.”3

Peter Drucker, Stephen Covey, and Warren Bennis associate ef-ficiency with management, even in climbing the ladder of success.To paraphrase their observation, leadership determines whether theladder is leaning against the right wall.

Managing is doing thingsright. Leadership is doing theright things, like leaning theladder against the right wall.

cott_c18.qxd 6/30/05 4:01 PM Page 320

PROJECT LEADERSHIP 321

Motivational experts seek to explain why some projects succeedwhile others do not. These studies result in leadership-success mod-els based on the project environment, the characteristics of the lead-ers being studied, and the leader ’s ability to inf luence others. Somehave studied the basis for leadership power and inf luence, notablyHans Thamhain4 and the Wilson Learning Corporation,5 by havingvarious inf luence factors ranked by managers, peers, and supportpersonnel. To highlight the consistencies among their findings, we’vefocused on four inf luence categories. They’re in the following list inthe order of their effectiveness as rated by team members:

• Organizational position or formal authority.• The manager’s personal factors—Expertise, interpersonal skills,

information, connections and alliances, trust, and respect. Allcredibility factors.

• The project work itself—Work interest and challenge; future as-signments.

• Rewards and penalties—Salary and promotion; coercionand penalties.

While the order varies somewhat among surveys and industries,most participants rank the project manager ’s authority and exper-tise at the top along with the work itself. Surprisingly, salary andpromotions are perceived only a little more positively than coercionand penalties, the latter being seen as the least inf luential.

One author ’s career-limiting experience takes a (somewhat ob-structed) view of organizational position.

As a new lieutenant on active duty with the U.S. Army during peace-time, I was assigned to a combat engineering company at Fort Lewis,a large military base near a major city. I was assigned to lead a convoyof 107 vehicles through the military base, continuing 10 milesthrough the city, and on to a remote training area 90 miles away. Theconvoy consisted of jeeps, light trucks, one high-back communica-tions van, and over 100 very heavy, very long, very slow vehicles, in-cluding heavy-duty dump trucks, f lat-bed trucks with bulldozers, andrubber-tire-mounted cranes.

We set out at the appointed time, just at the start of the Tacomarush hour. The convoy requirement was that we had to allow civilianvehicles to pass and to intermingle with the long line of trucks. As wasappropriate, I was in the lead jeep, with my second in command in thejeep at the rear. The communications van was right behind me.

An hour later, a military police sergeant on a motorcycle, redlights f lashing, pulled us over. The communications van, which I hadbeen carefully watching—but could not see around—pulled over be-hind us. The police sergeant asked, “Lieutenant, are you the leader of

cott_c18.qxd 6/30/05 4:01 PM Page 321


In the absence of adequateformal authority, strong per-sonal skills and leadershiptechniques are indispensable.

this convoy?” “Yes, I am,” I replied. He said, “Would you like to knowwhere they are?” I got out of the jeep to discover that no army vehiclewas in sight. Some of the longest vehicles “got lost” in the officers’quarters, wandering past the homes of the commanding general, thebattalion commander, and others, causing a major traffic jam. Othersof the lost 105 vehicles made it off the Fort, but got lost in the busi-ness areas of Tacoma. It took over two hours to round up everyoneand reform the convoy.

A valuable lesson: Leadership is not about being in front.When we discussed forming the project team, we emphasized

that the project manager should be given as much authority as possi-ble. But we need to add one important caveat. The existence of theauthority is considered to be a positive inf luence; however, itsundue exercise can be perceived as coercion—diminishing the netinf luence. Selective use of authority only when absolutely requiredwill produce the best overall results.

THE MOTIVATIONAL TECHNIQUES OFPROJECT LEADERSHIP

Nothing requires leadership skills more than the challenges of moti-vation. The payoff is very high. According to the results of studiesby the Public Agenda Foundation, a private research organization inNew York, 88 percent of workers responded positively when asked ifthey considered it important to do their best job. However, 44 per-cent of those surveyed admitted that they “exert no effort over theminimum.” And only 23 percent believe they work to their full ca-pacity. The leader ’s motivation challenge is to tap that available dis-cretionary effort.

The limitations of control and authority demand that projectmanagers be able to differentiate motivational causes and effectsand be able to accurately relate them to the specific project teamand member needs. Misplaced or ill-conceived motivation oftenturns into demotivation—much worse than no motivation at all. Thefollowing groups of techniques, when properly applied, have provedeffective in the project environment.

Vision

Above all else, we demand that our leaders have a vision and be ableto articulate and structure its attainment. Whether it’s successfultask completion or a company reorganization, the ability to convey

Vision pursuit is the glue thatholds all the other leadershiptechniques together.

cott_c18.qxd 6/30/05 4:01 PM Page 322


Hallucinator: a visionary whocannot lead to realization oftheir vision.

INCOSEThe INCOSE Handbook Sec 1.7refers to leadership as avision-based activity and citesthe need for systems engi-neers to have systemic vision.

the vision and then affect its realization is the glue that holds all theother leadership techniques in place. Leaders must accept the goalsof the larger organization, of which their work is a part, and createthe vision that supports the goals. They must understand the drivingforces of the various stakeholders who will gain or lose by the vi-sion’s fulfillment. Finally, they must be able to communicate that vi-sion to the team in relationship to their work.

Creating the Environment

How we manage vision attainment is the heart of the technique set.Attainment begins by creating the environment in which the work isto be accomplished.

Initially, this means defining management practices that will beused to manage the project and determining your style (discussed indetail at the end of the chapter).

In Chapter 5, we addressed the decision-making process as amajor environmental and teamwork factor. The work of DouglasMcGregor is also useful in characterizing the leadership environ-ment.6 He defined two types of environments (Figure 18.1): TheoryX (authoritative) and Theory Y (challenge). Theory X is the mili-taristic environment based on the assumption that people reallydon’t like to work and must be coerced into following orders, most of which originate with top management. But direct orders cannot

Figure 18.1 Theory X (authoritative) and Y (challenge) environments.

12 12

3

56

47

9

1011

8

IN OUT

X - Management

Environment

FAX

Y - Management Environment

cott_c18.qxd 6/30/05 4:01 PM Page 323


Variations in performanceoften stem from the leadershipstyle used by the accountableperson—for example, theway the task work is assigned,planned, and statused.

always be depended upon, as the following story, originally appear-ing in the Naval Institute’s Proceedings, illustrates.

Two battleships assigned to the training squadron had been at sea onmaneuvers in heavy weather for several days. I was serving on thelead battleship and was on watch on the bridge as night fell. The visi-bility was poor with patchy fog, so the captain remained on the bridgekeeping an eye on all activities.

Shortly after dark, the lookout on the wing of the bridge re-ported, “Light, bearing on the starboard bow.”

“Is it steady or moving astern?” the captain called out.Lookout replied, “Steady, captain,” which meant we were on a

dangerous collision course with that ship.The captain then called to the signal man, “Signal that ship: We

are on a collision course, advise you change course 20 degrees.”Back came a signal, “Advisable for you to change course 20 degrees.”The captain said, “Send, I’m a captain, change course 20 degrees.”“I’m a seaman second class,” came the reply. “You had better

change course 20 degrees.”By that time the captain was furious. He spat out, “Send, I’m a

battleship. Change course 20 degrees.”Back came the f lashing light, “I’m a lighthouse.”We changed course.

Theory X often results in an adversarial relationship betweenmanager and subordinates—totally inappropriate for most projectteams. Theory Y assumes that people want to work and can behighly self-directed with an appropriate work environment and re-ward system.

Subsequent to McGregor ’s original work, William Ouchi intro-duced Theory Z to refer to the participative format that grew out ofthe Japanese “quality circles” movement and broadened with TotalQuality Management.7 It is typified by closely knit teams that de-velop common goals to which they are committed through sharedvalues and a refined process (Figure 18.2).

For most projects each of these concepts has shortcomings.While Theory Z represents the project environment most closely—especially small, well-controlled projects—it has been found defi-cient in atmospheres of conf lict. Larger projects involving multipleorganizations, customers, and subcontractors work best when theenvironmental elements of both Theory Y (individual) and Theory Z(team) are combined. For your project, you need to determine theappropriate environment and decide how to set that environment in place.

This “beacon of information”provides several metaphorsregarding position power, perceptions of authority, andthe need to act on completeinformation.

cott_c18.qxd 6/30/05 4:01 PM Page 324


Regardless of the specific style, a leader creates a problem-solving environment by:

• Building urgency and “admiring” the problem.• Removing roadblocks so the team can do their things.• Eliminating window dressing.• Rising above bureaucracy and politics.

The same approach should be taken for a task managed by aself-directing team or by McGregor ’s worst nightmare, the X-stylemanager. That is, after assessing the team and the stakeholder ex-pectations, adopt or adapt a project cycle for the project and an-nounce what tailoring the team is expected to do to that cycle.Identify the training needed to increase the team effectiveness,both at the team and individual levels. You will also need to definethe balance of decision-making authority among the team, you asthe project manager, and higher-level management.

Due to the interdependent nature of project people and theteamwork culture, each team member wants to be involved and tofeel responsible for proactive participation in management activi-ties. These include planning, measuring, evaluating, anticipating,and alerting others to potential problems. To become committed toproject goals, as Stephen Covey observes, “. . . they want involve-ment, significant involvement. And if they don’t have involvement,they don’t buy it. Then you have a significant motivational problemwhich cannot be solved at the same level of thinking that created it.”

Project failures can frequently be traced to unrealistic techni-cal, cost, or schedule targets. Such targets may be entirely arbitrary

Figure 18.2 Theory Z (participative) environment.

Z - Management Environment

The leader knows the peopleon the team and recognizestheir needs.

cott_c18.qxd 6/30/05 4:01 PM Page 325


A pattern of ineffective meet-ings is a sign of weakleadership.

or based on bad assumptions—setting team members up for failure.Furthermore, the goals that motivate one team member may notmotivate another member. All tasks don’t have to be inherently mo-tivating—that’s not sensible. But there have to be motivating fac-tors, if by nothing more than participating in goal determination.This also helps ensure adequate opportunity and risk identification,analysis, and management.

We’ve found that it is better to aim high and to occasionally missthan to aim low. For example, Intel Corporation encourages employ-ees to include goals in their management by objectives (MBOs) forwhich there is at least a 50 percent chance of accomplishing. Anoverall MBO score of 75 percent is considered good—encouraging astretch. Even overly aggressive goals, if set by the team memberrather than the leader, can stimulate the extra effort needed to meetthem. And they pay an extra dividend—on-the-job training.

Meetings—lots of them—are an inherent part of the projectmanagement process. Nearly everyone complains about the timethey waste in meetings. But meetings are the major vehicles for ex-ercising leadership. In Chapter 15, we provided conduct guidelinesfor the various types, from one-on-one meetings to formal reviews.Well-conducted meetings can inspire and motivate the team, but toomany meetings, or poorly conceived or poorly executed ones, can bedemotivators.

Effective meetings are no accident. They demand managementskills for preparation and leadership skills for conduct. For example,people who are needed for decisions, but who arrive late or not atall, waste everyone’s time. Attendees who are not needed at all alsofeel that their time is wasted. On the other hand, one of the mostneedless and damaging demotivators is exclusion. Occasionally, ateam member will be “spared” from an important meeting or a diffi-cult task with no explanation. With proper explanation, that personmight have been relieved not to be involved, but may feel left out—perhaps even penalized—with no explanation.

A problem-solving meeting is a contest. The leader ’s challenge isto convince others to: change their positions or realign priorities,overcome prejudices and accept another point of view, and extendcommitments and increase vulnerability. But the leader needs torecognize and control counterproductive power struggles.

The leader should be an orchestrator, keeping the meeting bal-anced and on track. This often requires drawing out needed partici-pation by others and preventing domination by overly vocal members,the leader included.

Studies by industrial psychologist Frederick Herzberg examinespecific factors that motivate people in their work environment—

Involving team members inthe goal-setting process facili-tates team buy-in.

Goal setting by team membersultimately leads to greaterself-confidence and moreaggressive goals.

Meeting format and conduct isa significant aspect of creatingthe environment.

Major meeting demotivatorsinclude: lack of an agenda,indefinite start/stop times, andfailure to stay on schedule.

cott_c18.qxd 6/30/05 4:01 PM Page 326


Discussionon

track

Lecture

Snooore Discussionoff

track

Leader

Active

Active

Inactive

Inactive

Participants

A leader’s effectivenessdepends on the ability toassess maturity levels and toadopt the appropriate delega-tion style.

and those that don’t.8 Herzberg and his coauthors identify severalmaintenance or “hygiene” factors that are not motivational. Pay andworking conditions (safety, security, and comfort) reduce motiva-tion when absent. But maintenance factors were found to lead todiscontent only when they are missing or perceived as deficient,otherwise they have very little attitudinal affect. They are nevermotivators.

The presence of motivational factors, such as the work itself andrecognition, can significantly improve job satisfaction, goal orienta-tion, and productivity. But they must not be manipulative. AlfieKohn, in Punished by Rewards, observed “Do this and you’ll getthat, is not much different from do this or else.”9

The maintenance and motivation factors are in the following listin order of their relative importance revealed by Herzberg’sresearch:

Motivational (Positive) Maintenance (Negative)

Achievement. Policy and procedure.Recognition. Supervision.Work itself. Salary.Responsibility. Interpersonal relations.Advancement. Working conditions.

Company-wide-employee-relations campaigns involve mainte-nance factors, whereas motivational factors are generally in the do-main of the project manager and others in a direct leadership role.

Supervision Maturity

A good leader evaluates each team member’s ability to accept dele-gation and supervise others. Every opportunity should be taken tomatch the job assignments with interest and skills, keeping in mindthat a perfect match is impractical. This means assessing everymember’s individual job knowledge and maturity, then planning de-sired growth so that detailed direction can progress to coaching onimportant points; where coaching can transition to supporting asneeded; and where supporting can mature to full delegation.

As the maturity level moves from low to high, leaders need tovary their style from directing to delegating. Hersey and Blanchardhave developed a comprehensive situational leadership theoryand process that helps in assessing maturity and determining theappropriate delegation style by considering the interaction be-tween two major determinants (see Figure 18.3):10

cott_c18.qxd 6/30/05 4:01 PM Page 327


Task behavior: The degree to which a leader tells people what,why, and how. Generally, task-oriented leaders set the goals anddefine the detailed steps to reach them.Relationship behavior: The degree of support provided by theleader and the extent of feedback sought. Relationship-orientedbehavior is characterized by good bilateral communications andactive listening.

Figure 18.3 The Hersey situational leadership model. Reprinted from Paul Hersey and Ken Blan-

chard, Management of Organizational Behavior: Utilizing Human Resources, Englewood Cliffs,

NJ: Prentice Hall, 1993, sixth edition. All rights reserved.

cott_c18.qxd 6/30/05 4:01 PM Page 328


Follower readiness: The degree to which the followers need di-rection from the leader—individually and as a team. In the proj-ect environment, readiness depends on the level of experienceand knowledge available for the specific project and the inter-personal growth from working together as a team, all of whichcan be expected to grow as the project moves through itsphases. The four basic situational leadership styles are summa-rized in Figure 18.3, followed by their appropriate application:• Telling (S1): This style is most appropriate for followers who

are unable or unwilling to take responsibility because theylack knowledge or experience.

• Selling (S2): This style can be practiced when selling con-cepts to top management and customers. It can be effective inobtaining team buy in through selling the benefits of deci-sions. It is the natural training style.

• Participating (S3): This style is appropriate for a moderatelymature team. The leader and followers share in the problem-solving and decision-making processes, with the main role ofthe leader being facilitator.

• Delegating (S4): This style matches the needs of teams or in-dividuals who have reached a high maturity level. They haveacquired both the motivation and ability to allocate projecttasks and then to accomplish them with a minimum of super-vision. The leader delegates and follows up.

Appropriate delegation is an effective technique for avoidingover management while, at the same time, improving job satisfac-tion. As a project or task manager, a particularly strong motivator isthe confidence demonstrated by turning over one of your own plumsto another team member.

If they’re not ready now, then consciously grow personnel to thepoint where they can accept delegation. Mismanaging this growthprocess can mean either delegating too early and experiencing per-formance problems or giving overly detailed directions and beingbranded a nit manager. Whether a project manager or a junior teammember, a sign of management maturity is knowing when to applythe following three approaches with your boss:

1. “It’s my responsibility, and I am taking care of it.”2. “It’s my responsibility, and I am taking care of it. But you need

to know what I am doing.”3. “It’s my responsibility, but the best solution is beyond my au-

thority and I need your assistance.”

Delegate whole tasks—aslarge of a piece as possible—not bits and pieces.

People who can handle dele-gation usually don’t complain.

cott_c18.qxd 6/30/05 4:01 PM Page 329


Interpersonal Traits

Leading people is, in part, the skill of knowing how to draw on theteam’s strengths and minimize the weaknesses. It takes time to un-derstand others—to understand why a single act of ours can have apositive effect on some and the exact opposite effect on others. It’snot merely a one-time event of being typecast by Wilson Learning11

or Myers Briggs12 or other good assessment tools and then wearing alabel. It requires conscious attention to the needs of each team mem-ber and hard work to understand the complexities of the team mem-bers in order to work with them and benefit from that complexity.

Much of traditional motivation theory is based on AbrahamMaslow’s five hierarchical levels (physical, security, social, status,and psychic), each level becoming an intrinsic motivator after thelower-level need has been met. Any one of the levels may be domi-nant in a particular person. For example, some people are more re-sponsive to psychic than to social incentives, regardless of how welltheir social needs have been met.

Needs can regress as the environment changes. Stephen Coveydramatizes the point:

If all the air were suddenly sucked out of the room you’re in rightnow, what would happen to your interest in this book? You wouldn’tcare about the book; you wouldn’t care about anything except gettingair. Survival would be your only motivation.

But now that you have air, it doesn’t motivate you. This is one ofthe greatest insights in the field of motivation: Satisfied needs do notmotivate. It’s only the unsatisfied need that motivates.13

Interpersonal clashes are inevitable, even in the most compatibleteams. The techniques suggested here seek to channel the conf lictin constructive ways so as to prevent a significant demotivator—prolonged or unresolved conf lict.

The traditional conf lict resolution methods are:

• Confrontation/Collaboration (Integration).• Compromise (Negotiation).• Smoothing (Suppression).• Forcing (Power or Dominance).• Withdrawal (Denial /Retreating).

Fact- and issue-based confrontation is the most favored modefor resolving conf licts, especially in dealing with superiors. Con-structive confrontation has grown from a technique to a methodcomplete with its own textbooks. But it is not a panacea.

The process of constructiveconfrontation can be honedinto a significant asset.

cott_c18.qxd 6/30/05 4:01 PM Page 330


Every action you take sends apowerful leadership style mes-sage to team members.

Compromise is usually the best mode for dealing with functionalsupport departments. At the other extreme, withdrawal is usuallyseen as capitulation, and is at best a temporary resolution. A skilledleader employs the full range of conf lict resolution modes.

Brainstorming techniques are often used to attack the most dif-ficult problems while enhancing interpersonal skills. The leaderneeds to ensure an open and noncritical atmosphere. For example,unusual or impractical ideas should be encouraged—they often leadto new combinations and improvements. Remember—the moreideas, the better.

The one-on-one meeting is one of the best techniques for exer-cising leadership on an interpersonal level. It provides the opportu-nity to demonstrate four important leadership qualities:

• Sensitivity to personnel issues.• Accessibility and friendliness.• Trust—respect for confidentiality.• Training and coaching.

Reinforcement

Reinforcement refers to techniques used to remind team membersof the vision and the continuing requirements of working as a team.Because the project process includes difficult aspects that may notyet be intuitive, team members may resist or circumvent them. Atevery opportunity, the leader should emphasize the benefits of theproject management essentials. Posters and slogans around a teamroom reminding people of important things are good if there is fol-low through to make them credible. The project leader ’s spokenwords and body language, and especially job performance, can rein-force those points.

Setting the Example

Walk the walk, don’t just talk the talk if you expect others to follow.It is less what you say and more what you do that inf luences behav-ior. Your attitude and body language set the tone for the entire team.You need to establish an atmosphere of openness by your willingnessto seek advice, as well as bad news.

It’s damaging to continually demand on schedule performance,and yet begin every meeting late. Act as you want your team to act: up-beat, punctual, decisive, untiring, enthusiastic, fair, and dependable.

Group activities such as planning and problem solving offerample opportunity for setting examples. Make sure that you begin

Group brainstorming can bevery beneficial, but also verytime consuming, so make sureit is time well spent.

A leader’s spoken and bodylanguage as well as job performance can provide reinforcement.

Never ask your team to dowhat you would be unwillingto do yourself.

cott_c18.qxd 6/30/05 4:01 PM Page 331


meetings on time and operate by the same standards that the teamhas committed to.

Rewarding Achievement

It may be time to put away the carrot and stick for good. Recentstudies are calling into question the maxim of “You get what you re-ward.” These studies show that, while some rewards can bring aboutshort-term compliance, others often backfire in the longer term.Rather than getting sidetracked trying to resolve reward controver-sies, managers can benefit most by simply being aware of the issues.Much of the conf lict confirms that people respond to widely varyingrewards and some do not respond to external motivations at all. Ourpurpose is to characterize these forces so that they can be made partof everyone’s awareness—managers and team members alike.

Some rewards can be perceived as denials of self-control andfreedom of choice, especially if they don’t address a need. Eventhough there are many techniques for finding out what people want,managers hesitate to pursue them. You may not be prepared to dealwith the answer. But you’ll discover that asking about motivations,whether by a formal survey or a simple one-on-one question session,is motivating in itself. You need to follow-up to prevent being judgeda hypocrite.

A Hilton Hotels’ Time Values survey revealed that 70 percent ofpeople earning over $30 thousand would trade a day’s pay each weekfor an extra day of free time. This phenomenon exists even in thelower-pay brackets. Almost half of those surveyed earning less than$20 thousand would also make the trade.

You should take advantage of every opportunity to recognizegood performance, but it’s most effective when done in a group en-vironment such as at meetings or reviews—even off-site pizzabreaks. Be sure you’re aware of the supporting details and that youdon’t leave somebody out. A further note of caution: intrinsic moti-vation, so fragile in the team environment, can be destroyed by any-thing that is perceived as being manipulative or controlling—evenpraise. Those who receive excessive praise can become so self-conscious that they have trouble concentrating. They may even duckchallenges to avoid potential failure.

Rewarding individual performance doesn’t necessarily result ina lack of teamwork. But cooperation does need to be one of themajor performance rating factors. Accomplished leaders recognizeand reward cooperation with teammates as an essential element ofindividual merit. One motivator for team performance is to do away

Interesting assignments areoften their own reward. Peoplewillingly work harder, as wellas smarter, at interestingtasks.

Most people simply want tohave interesting work and tobe recognized for their accom-plishments.

Most time-off incentives tiedto productivity or scheduleimprovements get results.

It’s important to recognize sig-nificant accomplishments fre-quently—but not routinely.

Rewarding team performancecan work as it does in sports—motivating stronger players tohelp weaker ones improve.

cott_c18.qxd 6/30/05 4:01 PM Page 332


with individual reviews. Some managers consider an entire taskgroup’s effort as one performance.

Regardless of your reward philosophy or the details of your re-wards, they need to be systematically aligned with the goals and val-ues of your project, environment, and company.

Training

Trying to do a job you haven’t been trained for is discouraging anddemotivating. This applies double to the project manager whoneeds to be trained to select appropriate project personnel, depend-ing on the project type and size, and then to contribute to their ca-reer development.

We are frequently retained by clients to train both their projectteams and their executive management. We use techniques thatbring groups together, encourage them to practice common goal set-ting and problem solving, and acknowledge their interdependencies.We’ve used managed delegation exercises, joint buyer-seller projectplanning, project simulations, and a host of other techniques. Weoften train in-house trainers—a group responsible to train others.But this doesn’t work unless the trainers have extensive—and suc-cessful—project management experience and can credibly addressdetailed issues from that perspective. As one of our clients asserted:“Someone with that kind of capability is usually very busy managinga hot project.”

Not all people are emotionally or technically equipped to takeon the teaching role. A teaching attempt at the wrong time, or by thewrong person, can be seen as a form of judgment or criticism. Alter-natively, being taught by your own management, if done well, can beextremely motivating. The higher the management doing the train-ing, the more stimulating and effective it is in establishing a consis-tent culture (assuming that manager has progressed through theproject trenches).

DETERMINING AND DECLARING YOURLEADERSHIP STYLE

The practice of project management is increasingly inf luenced byhuman relations. Developing human relations skills, in turn, dependson awareness of your own operating style and behavior patterns aswell as a willingness to adapt those qualities to the specific projectenvironment.

Training does not work as aone-shot seminar, regardlessof how long or how intensiveit may be.

cott_c18.qxd 6/30/05 4:01 PM Page 333


A person’s reaction to an unwanted fire offers a good metaphorfor appreciating how extreme a rigid personal style can be:

• Reactive—Run for water.• Inactive—Watch the blaze.• Counteractive—Apply gasoline.• Distractive—Send the fire trucks to the parade.• Retroactive—“I could have told you to install sprinklers if

you’d asked.”

The proactive manager would have already installed a sprinklersystem.

The project manager ’s ability to get the job done usually de-pends more on operating style than on any other factor—even morethan power or authority. A true leader knows what is going on at alltimes and anticipates situations, consciously operating in the appro-priate style. While most leadership techniques are directed towardmotivation, leadership styles characterize the methods for applyingthe techniques.

There are numerous texts and self-study guides for analyzingone’s own style tendencies and preferences. To conclude this chap-ter, we introduce two models that have proved to be particularly ef-fective. The details of any specific self-typing or group analysisscheme are less important than the process itself—exploring yourown preferences and stretching your range of styles. To benefit fromthat process, you first have to be self-aware.

Before analyzing further, you may find it useful to jot down yourown behavior patterns, both formal and informal. As Frankl says, we“detect” rather than “invent” our missions in life. Think about theway in which you respond to different situations. Think about the sit-uations in which you’re comfortable—and others where you’re un-comfortable. In which kind of relationship problems do you investtime and energy on a regular basis—which ones need more of yourtime? Identify your motivation source (personal need served) in each.

Wilson Learning Corporation’s Interpersonal Relations Modelhas been widely used in the business environment for characterizingyour own style. It is usually associated with a formal training semi-nar that includes a preliminary survey completed by selected peers.This is done through formal questionnaires similar in format to psy-chology and aptitude profiles. Your interpersonal style is determinedby an evaluation of your peers’ perceptions. In Figure 18.4 the re-sults are displayed relative to a four-quadrant model.

Combining your primary style—Analytical, Driver, Amiable, orExpressive—with your secondary or backup style (one of the same

As the leader, you need to bemotivated to adapt your ownbehavior rather than to “shapeup” someone else.

cott_c18.qxd 6/30/05 4:01 PM Page 334


four quadrants in the basic model), places you in one of the 16 stylecategories, for example, an Expressive/Driver (Figure 18.5).

The usefulness of the Wilson model becomes clear when youconsider the interactions among the various categories. The result isa much-improved insight and awareness, not only of your own styles,

Figure 18.4 The basic Wilson Learning Model.

Figure 18.5 The 16 Wilson learning style combinations.

Analytical

ExpressiveAmiable

orSupportive

Driveror

ControllerExpressive

Driver

cott_c18.qxd 6/30/05 4:01 PM Page 335


but more importantly the patterns and characteristics of those youwork with. Perhaps most important is to anticipate interactions so asto adapt and adjust your own personal behavior to maximize chanceof success in business and personal interactions.

The Myers-Briggs model is broadly supported in psychology andself-help. It uses a questionnaire to help you determine your domi-nant trait in each of four pairs of traits:

E/I Extrovert or Introvert.N/S Intuitive or Sensing.T/F Thinking or Feeling.J/P Judging or Perceiving.

The model is based on the theory of psychological types describedby C. G. Jung (1875–1961). Jung’s model places you in one of 16 cat-egories based on combining that one dominant trait from each pair.The characterizations in Figure 18.6 are adopted from Keirsey andBates, one of several guides for interpreting the results.14

Rather than consolidating peer- and self-review into one com-posite result, you are encouraged to characterize yourself and to in-dependently have others respond to the same questions about you.Additional insight can thus be gained by comparing your results foreach trait with the perception of others. As with the Wilson model,most authors provide detailed advice and insight regarding the dy-namics of one style interacting with another (e.g., an ENTJ interact-ing with an ISFP), whether the interaction is as team members,manager/subordinate, or spouses.

Figure 18.6 Myers-Briggs’ 16 types, characterized by Keirsey and Bates.

cott_c18.qxd 6/30/05 4:01 PM Page 336


Regardless of your preferred style, your actual style at any timeshould be affected by such factors as the maturity level of teammembers and the gravity or priority of the situation. Variety andshifts in style are not only healthy—they’re necessary. Leadershiprequires f lexibility and adaptability in dealing with the task at hand,the personalities involved, events, and the situation.

Anticipate beneficial changes in your own style and declare whatwill trigger a change. A good time to announce these to the team is atthe kick-off meeting. Here’s an example: “I’ll implement news-f lashmeetings, plan-violation meetings, daily stand-up meetings, and asneeded, red teams and tiger teams. I’m an expressive/driver. I willoperate in the Y-mode most of the time. I will be proactive and reac-tive—seldom inactive. I want to delegate as much as possible, but if I’m the one to recognize a slip in a delegated task, I’ll switch todriver/directing mode.”

LEADERSHIP ELEMENT EXERCISE

The objective of this exercise is to provide experience in describingyour leadership style to others.

Based on the explanations of this chapter and your own leader-ship experiences, develop a single chart that clearly declares yourleadership style to others. If you use unfamiliar terms or jargon, ex-plain it for the uninitiated. Encourage feedback from peers, superi-ors, and subordinates as to its validity.

You need to develop the abilityto vary your style.

Once you determine your pre-ferred styles, declare yourselfand lead consistently withyour stated standard.

cott_c18.qxd 6/30/05 4:01 PM Page 337

cott_c18.qxd 6/30/05 4:01 PM Page 338

P a r t F o u r

Implementingthe FiveEssentials

We were about to name Part Four Advanced Topics, but agreedwith our Wiley editor, Richard Narramore, that this rather

ambiguous title could set false expectations. Part Four is not aboutdepth of details or advanced theories. It is about the subtle combi-nation of breadth and depth needed to build a process culture in thereal world. We address overall implementation while selecting spe-cific topics for drilling deeper to get to where the rubber meets theroad (more on that in a moment).

Chapter 19 picks up from earlier chapters that introduced ourvisual models and proceeds through the tactics needed to mastercomplex systems. Chapter 20 focuses on predictable, high-qualityresults and Chapter 21 wraps up by addressing the challenges of im-plementing cultural changes and of sustaining a successful culture inthe face of growth and environment erosion.

That process is freedom may not always be intuitive. This realityis demonstrated dramatically by Hyundai’s process route on itsroad from rags to riches, and conversely by Intel, a highly successfulprocess-driven organization that may have lost its way along thesame route of travel.

In 2004, Hyundai ($24 billion in revenue) startled the world byascending from almost last place in automobile quality to firstplace. Consumer Reports magazine recently labeled the HyundaiSonata as the most trouble-free 2004 model in the country. “It is

Process is freedom.

The investments and effortsmade to revitalize the projectenvironment, or to create one,can pay high dividends to theentire organization.

cott_c19.qxd 7/5/05 3:08 PM Page 339

340 IMPLEMENTING THE FIVE ESSENTIALS

pretty amazing. I don’t think we’ve ever documented in our studiesan improvement quite like this,” said Chance Parker, of J.D.Powerand Associates, a marketing research firm.1 The byline of a Forbes ar-ticle sums up the situation: “How Hyundai’s carmaking prowess wentfrom punchline to powerhouse . . .”2

The prevailing industry opinion is that Hyundai has built a pro-cess culture that fosters teamwork and ensures that the right thinggets done right. The company releases designs that work, manages de-sign stability throughout the life cycle, and uses new vehicle launchesto make small continuous refinements to improve cost, quality, andreliability. Their teamwork culture views suppliers as valuable supplychain partners. Hyundai manages aggressive cost reduction targets asa joint responsibility with their suppliers, expending substantial effortand resources to assist suppliers in meeting cost targets without mar-gin erosion.

By contrast, Intel ($34 billion in revenue) appears to haveslipped from being the world leader in a process-driven industry toscrambling to sustain the culture that paved its road to success.Intel has been shipping defective parts late. In July of 2004, CraigBarrett, Intel CEO, found it necessary to write a letter to all 80,000employees encouraging them to revisit the Intel culture and to rein-stall “indicators, reviews, and management attention to start to turnthese problems around by ensuring good planning, staffing and pro-gram management.”3

These two situations highlight the role of organizational com-mitment, and its potential for misinterpretation, as ref lected by topmanagement behavior. During Andy Grove’s tenure as Intel’s CEO,the Intel cultural elements of training (every employee was chal-lenged to devote 10% of his or her time to education or educating)and constructive confrontation (direct, forthright communication)were reinforced every day by Andy’s personal presence in the class-room as teacher or student and at project reviews. Craig Barrett’sexternal focus needed to sustain growth has lowered the bar on in-ternal expectations at the same time that Hyundai Chairman, Mong-Koo Chung, has aggressively raised theirs. “He’s not looking at[quality problems] on paper; he’s very hands-on,”4 says Robert Cos-mai, chief executive of Hyundai Motor America.

Industry pundits debate how well these two companies willbuild, rebuild, or sustain their cultures over the long range. Themessages are that culture building requires a committed, focused or-ganization. Once in place, sustaining even the strongest and mostproductive process culture requires nurturing and involved leader-ship from top to bottom.

Whereas technology is sur-prisingly easy to clone, a well-integrated, high-performanceproject culture is an invaluableproprietary asset for sustain-ing high performance well intothe future.

cott_c19.qxd 7/5/05 3:08 PM Page 340

341

19PRINCIPLES ANDTACTICS FORMASTERINGCOMPLEXITY

We have selected several key topics, introduced in prior chapters,to address in more depth. This chapter is intended for those re-sponsible for the technical aspect of complex system development.It covers:

• Combining architecture and entity development to create thesystem solution—the Dual Vee.

• Agile development practices.• Technical development tactics, including incremental and evolu-

tionary development.• Tactics and the critical path.• Artifacts and their roles.

COMBINING ARCHITECTURE ANDENTITY DEVELOPMENT TO CREATE

THE SYSTEM SOLUTION

Chapters 7 and 9 introduced the Architecture Vee Model that por-trays the product breakdown of the system, illustrating decomposi-tion and definition down the left Vee leg and integration andverification up the right Vee leg. Figure 19.1 incorporates the basicVee attributes introduced in Chapters 7 and 9.1

INCOSEThe INCOSE Handbookdefines these sevendecomposition levels:

1. System.

2. Segment.

3. Element.

4. Subsystem.

5. Assembly.

6. Subassembly.

7. Part.

cott_c19.qxd 7/5/05 3:08 PM Page 341


The Architecture Vee Model

The Architecture Vee model extends downward according to thenumber of levels in the architecture. More complex projects mayhave several levels of segments, such as the first segment level andthe second segment level or they may have multiple levels of ele-ments. On the other hand, systems with a simpler architecture mayhave only two or three levels.

To develop complex systems—especially systems of systems—involves the orchestration of many concurrent tasks and intersectingprocesses. Development of every entity of the architecture, fromthe top-level system down to the lowest configuration items or low-est replaceable units is integral and concurrent with architecturedevelopment. For this discussion, lowest configuration item (LCI) isused to refer to the lowest level in the architecture from the per-spective of the project’s systems engineer. As such, the item can be

Figure 19.1 Architecture Vee Model.

Architecture Vee

System RealizationSystem Realization

seussI erutcetihcrA

noitagitsevnI

ylamon

A

noitagitsevnInoita

mrifnoC re

motsuC

SystemRequirements, Concept, Architecture, Design-to,Build-to, and Verification




SubsystemRequirements, Concept, Architecture, Design-to,Build-to, and Verification








ComponentRequirements, Concept, Architecture, Design-to,Build-to, and Verification








Lowest CI Requirements, Concept, Architecture, Design-to,Build-to, and Verification






Verification



Verification


Validation


Validation





IV&V

SubsystemVerification, Validation and Preparation for System Integration

SubsystemVerification, Validation and Preparation for System Integration





Lowest CIVerification/Validationand Preparation for


Lowest CIVerification/Validationand Preparation for


noiti

sop

moce

D eru

tceti

hcrA

noiti

nifeD

& noitargetnI erutcetihcrA

noitacifireV &

noitargetnI erutcetihcrA

noitacifireV &

Verification and Validation Planning(all levels)

Descends to LowestConfiguration Item

noitamrifno

C remotsu

C

cott_c19.qxd 7/5/05 3:08 PM Page 342

PRINCIPLES AND TACTICS FOR MASTERING COMPLEXITY 343

assigned to an individual and it will be designed and verified to itsconfiguration item (CI) specification. It will be statused by the proj-ect as a deliverable entity. The LCI may also be the lowest replace-able unit (LRU).

THE ENTITY SOLUTION ANDARCHITECTURE PHASE SEQUENCE

To convert a set of user needs into a deployed system satisfyingthose needs requires that a solution be found for each entity atevery level of architecture decomposition. Each rectangle in theArchitecture Vee of Figure 19.1 contains a description of the devel-opment activities needed to create that entity. The series of eightfigures, starting with Figure 19.2, illustrates the development sequence and the relationship of development steps at a particularlevel of decomposition with those of higher and lower levels ofdecomposition.

Figure 19.2 Development Sequence 1.

noit

isop

moce

D er

utce

tihc

rA

noiti

nife

D &


noitacifireV

&





Verification


Validation





Lowest CIVerification and Preparation for


System Realization

noit

isop

moce

D er

utce

tihc

rA

noiti

nife

D &


noitacifireV

&





Verification


Validation







noit

isop

moce

D er

utce

tihc

rA

noiti

nife

D &

noit

isop

moce

D er

utce

tihc

rA

noiti

nife

D &


noitacifireV

&





Verification


Validation







System Realization

Solution/System

Architecture

Solution/System

Architecture

Solution/System

Requirements

Solution/System

Design-toArtifacts

Solution/System

Design-toArtifacts

Solution/SystemConcept

Creating a system solutionstarts at the upper left of theArchitecture Vee with a firstphase that defines user andsystem requirements. This isfollowed by three sequentialphases, which define andbaseline the system concept,the system architecture, andthe system level design-tospecification. At this point,system level developmentcannot proceed further untilthe entities at lower levels ofdecomposition are designed.

cott_c19.qxd 7/5/05 3:08 PM Page 343

344

Figure 19.3 Development Sequence 2 (subsystem level).

noit

isop

moce

D er

utce

tihc

rA

noiti

nife

D &


noitacifireV

&





Verification


Validation







System Realization

noit

isop

moce

D er

utce

tihc

rA

noiti

nife

D &


noitacifireV

&





Verification


Validation







noit

isop

moce

D er

utce

tihc

rA

noiti

nife

D &

noit

isop

moce

D er

utce

tihc

rA

noiti

nife

D &


noitacifireV

&





Verification


Validation







System Realization

SubsystemRequirements


SubsystemRequirements Subsystem

Concept

SubsystemConceptSubsystemConcept

SubsystemConcept

SubsystemConcept

SubsystemConcept

SubsystemArchitecture

SubsystemArchitectureSubsystemArchitectureSubsystemArchitecture

SubsystemArchitectureSubsystemArchitecture

SubsystemDesign-toArtifacts






Solution/System

Architecture

Solution/System

Architecture

Solution/System

Requirements

Solution/System

Design-toArtifacts

Solution/System

Design-toArtifacts


ecne

uqeS

eta

G tpe

cno

C

Defining requirements,concept, architecture, anddesign-to specifications at thesystem level makesrequirements flowdown fromthe system level to thesubsystem level possible.Requirements, concepts,architectures, and design-tospecifications are developedfor the subsystems thatcomprise the system.Collaboration among thosemanaging the subsystems isnecessary to ensure interfaceand design-to compatibility aswell as ease of futureintegration and verification.The diagram shows the top-down progression of decisiongates to manage the evolvingarchitecture baseline.

Figure 19.4 Development Sequence 3 (lowest CI entity level).





Verification


Validation






Subsystem IntegrationLCIArchitecture

LCIArchitecture

LCIDesign-toArtifacts


LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept




Concept

SubsystemConceptSubsystem

ConceptSubsystem

Concept

SubsystemConcept

SubsystemConcept











Solution/System

Architecture

Solution/System

Architecture

Solution/System

Requirements

Solution/System

Design-toArtifacts

Solution/System

Design-toArtifacts


ecne

uqeS

eta

G tpe

cno

C ngi

se

D-

ecne

uqe

S et

aG

ot

Upon completing thesubsystem design-tospecifications, the effort shiftsto the next lowerdecomposition level, the LCIdevelopment. Note that thedesign-to decision gatesequence starts at the systemlevel and proceeds to lowerlevels of decomposition toensure the correct flowdownof requirements.

cott_c19.qxd 7/5/05 3:08 PM Page 344

345






Verification


Validation







LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept




Concept


SubsystemConcept

SubsystemConcept

SubsystemConcept











Solution/System

Architecture

Solution/System

Architecture

Solution/System

Requirements

Solution/System

Design-toArtifacts

Solution/System

Design-toArtifacts


ecne

uqeS

eta

G tpe

cno

C ngi

se

D-

ecne

uqe

S et

aG

ot

Design LCI and

Build-to and Code-toArtifacts

This diagram shows thesimultaneous development ofthe build-to and code-toartifacts for all of the lowestconfiguration items. Of course,some LCIs, and even somesubsystems, may not bedesigned if their design-tospecifications can be met byprocuring off-the-shelf items.Comprehensive technicalmanagement is needed toensure compatibility of all LCIinterfaces and intrafaces. Withthe completion of the build-toand code-to artifacts, includingdraft verification procedures,the build-to decision gatesequence is conducted toprove the feasibility ofbuilding, coding, integrating,and verifying the LCI designsand to baseline them.






Verification


Validation







LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept




Concept


SubsystemConcept

SubsystemConcept

SubsystemConcept











Solution/System

Architecture

Solution/System

Architecture

Solution/System

Requirements

Solution/System

Design-toArtifacts

Solution/System

Design-toArtifacts


ecne

uqeS

eta

G tpe

cno

C

ngi

se

D-

ecne

uqe

S et

aG

ot

Design LCI and


DesignSolution/

System andBuild-to

and Code-to Artifacts

DesignSubsystem

andBuild-to and

Code-toArtifacts

dliu

B-

ecne

uq e

S et

aG

ot

The LCI-level build-to baselinewill be followed by thesubsystem level baseline andthen the system level. At thesystem build-to decision gate,evidence must be providedthat proves that, if all theentities are built as designed,the system will perform asexpected.

cott_c19.qxd 7/5/05 3:08 PM Page 345

346






Verification


Validation







LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept




Concept


SubsystemConcept

SubsystemConcept

SubsystemConcept











Solution/System

Architecture

Solution/System

Architecture

Solution/System

Requirements

Solution/System

Design-toArtifacts

Solution/System

Design-toArtifacts


ecne

uqeS

eta

G tpe

cno

C

ngi

se

D-

ecne

uqe

S et

aG

ot

Design LCI and


DesignSolution/

System andBuild-to


LCIInterface

Build

LCIBuild

LCIIntegration

LCIIntegration

LCIIntegration

LCIIntegration

LCIVerification

LCIVerification

LCIVerification

LCIVerification

LCIValidation

LCIValidation

LCIValidation

LCIValidation

DesignSubsystem

andBuild-to and

Code-toArtifacts

dliu

B-

ecne

uqe

S et

aG

ot

The satisfactory conclusion ofthe build-to gate sequenceprovides assurance that aviable solution exists and thatit is realizable if the build-todesigns and processes arecarried out as prescribed.

This diagram shows thelowest configuration itemsbeing produced, verified, andvalidated at the LCIdecomposition level. If COTSitems are being integrated,they will already exist, butthey must be verified andvalidated at the appropriateentity level.






Verification


Validation







LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept




Concept


SubsystemConcept

SubsystemConcept

SubsystemConcept











Solution/System

Architecture

Solution/System

Architecture

Solution/System

Requirements

Solution/System

Design-toArtifacts

Solution/System

Design-toArtifacts


ecne

uqeS

eta

G tpe

cno

C

ngi

se

D-

ecne

uqe

S et

aG

ot

Design LCI and


DesignSolution/

System andBuild-to


LCIInterface

Build

LCIBuild

LCIIntegration

LCIIntegration

LCIIntegration

LCIIntegration

LCIVerification

LCIVerification

LCIVerification

LCIVerification

LCIValidation

LCIValidation

LCIValidation

LCIValidation

DesignSubsystem

andBuild-to and

Code-toArtifacts

dliu

B-

ecne

uqe

S et

aG

ot

SubsystemInterface

BuildSubsystemIntegration

SubsystemIntegration Subsystem

Verification

SubsystemVerification Subsystem

Validation

SubsystemValidation

ecneuqeS etaG noitacifireV

& noitargetnI

Once verified, the lowestconfiguration items are readyfor physical integration intohigher level subsystems.Integration hardware andsoftware not already availablewill have to be created, forexample, software to interfacetwo COTS products or cablesto interconnect twoconfiguration items.

cott_c19.qxd 7/5/05 3:08 PM Page 346







Verification


Validation







LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture

LCIArchitecture



LCIRequirements

LCIRequirements

LCIConcept

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept




Concept


SubsystemConcept

SubsystemConcept

SubsystemConcept











Solution/System

Architecture

Solution/System

Architecture

Solution/System

Requirements

Solution/System

Design-toArtifacts

Solution/System

Design-toArtifacts


ecne

uqeS

eta

G tpe

cno

C

ngi

se

D-

ecne

uqe

S et

aG

ot

Design LCI and


DesignSolution/

System andBuild-to


LCIInterface

Build

LCIBuild

LCIIntegration

LCIIntegration

LCIIntegration

LCIIntegration

LCIVerification

LCIVerification

LCIVerification

LCIVerification

LCIValidation

LCIValidation

LCIValidation

LCIValidation

DesignSubsystem

andBuild-to and

Code-toArtifacts

dliu

B-

ecne

uqe

S et

aG

ot

SubsystemInterface

BuildSubsystemIntegration

SubsystemIntegration Subsystem

Verification

SubsystemVerification Subsystem

Validation

SubsystemValidation

Solution/System

Integration

Solution/System

Verification

Solution/System

Validation

Solution/System

InterfaceBuild

ecneuqeS etaG noitacifireV

& noitargetnI

The Entity Vee Model

The basic principles embodied in the Vee model can be used to il-lustrate the process for developing each entity. The Entity Veemodel represents this process. Referring to Figure 19.10, the left legrepresents the sequence of definition elaboration (decompositionanalysis and resolution or DAR) and the right leg represents the se-quence of assembly and performance assurance (verification analy-sis and resolution or VAR). All activities within one Entity Vee areat the same architecture level. The Entity Vee is repeated for everyentity of the architecture from the system, down to the LCIs, suchas computer software units or hardware components.

At each elaboration level, there is a direct correlation betweenactivities on the left and right legs of the Vee. This is deliberate.The method of verification to be used on the right Vee leg must bedefined at the time requirements are developed on the left; other-wise, requirements could be created that could never be verified.For example, “user friendly” is a perfectly valid requirement, but it

The right side of both Veesdirectly corresponds to theleft—the rationale for theshape.

Verification must be plannedat the same time requirementsare developed; otherwise, theverification tends to addressthe “goodness” of the designrather than its compliance tothe requirements.

The integration andverification gate sequence isconsistent with the buildup ofthe system, that is, from thebottom up. Finally, whensubsystems are verified toperform as specified, fullsystem integration is possiblefollowed by systemverification and validation.

cott_c19.qxd 7/5/05 3:08 PM Page 347


is unverifiable. Instead, a requirement that a computer screen display have “no more that five lines of 14-point text” defines userfriendly in measurable terms. Verification plans should be baselinedto ensure verification requirements and methods are known andprovided for at the design-to decision gate (PDR). Draft verificationprocedures based on the verification requirements, verificationplan, and proposed entity design must be available at the build-toand code-to decision gate (CDR). This reduces the chances that re-quirements are specified and implemented in a way that cannot bemeasured or verified.

The vertical dimension is elaboration detail at an architecturelevel (for instance, at the subsystem level) and the core of the En-tity Vee is entity baseline elaboration. Also included (similar to theArchitecture Vee) are the activities associated with opportunityand risk management, pursued downward and off core to the levelof detail necessary for issue evaluation and resolution. Unlike thecommonly held view of the Waterfall Model, there is no prohibi-tion against doing exploratory design and analysis at any point inthe project cycle to investigate or prove performance or feasibilityconcepts. Unlike the Spiral Model, the Vee opportunity and riskinvestigations are performed either in series or in parallel with theon-core development work, rather than being conducted sequen-tially and prior to the overall development process. Hardware andsoftware requirements-understanding models or technical feasibil-ity models are encouraged early in the project cycle to pursue op-portunities such as emerging technologies and to manage risk. Forinstance, to evaluate a concept requiring a manual override versusa concept with full automation, technical feasibility of the twoconcepts would be modeled. Selection might be based on responsetime versus cost and complexity of the system. Customer confir-mation can provide valuable in-process validation of the preferredapproach.

In the right leg, off-core investigations are used to resolve as-sembly and verification anomalies. This may require descending todesign errors, a cold solder joint, or operator error and the like. Up-ward off-core user interactions obtain confirmation or rejection ofthe realized performance. Note that, in the Entity Vee, these inter-actions address individual entity solutions and not the integration ofthe architecture. That activity is modeled by the Architecture Vee.At any level of decomposition, the customer of an entity is the man-ager of the next higher level of decomposition. For example, thepower subsystem manager is the customer of the person responsiblefor the battery.

cott_c19.qxd 7/5/05 3:08 PM Page 348


Figure 19.10 Entity Vee Model.

Dual Vees: The Entity Vee Related to the Architecture Vee

To convert a set of user needs into a deployed system that satisfiesthose needs requires that a solution be found for each entity at eachlevel of architecture decomposition. This can be visualized by posi-tioning Entity Vees orthogonal to the Architecture Vee as shown inFigure 19.11. For each entity of the Architecture Vee there is a cor-responding Entity Vee that addresses the entity development. Forexample, the Architecture Vee in Figure 19.1 shows two subsystems.The two Entity Vees shown represent the process for creating thosetwo subsystems.

Figure 19.12 reiterates the relationship of the DAR and VARprocesses to the Architecture Vee as discussed in Chapter 9 andillustrated by Figures 9.6, 9.7, and 9.8. Figure 19.12 elaborates fur-ther on the interrelationships by superimposing the DAR and VARon the Entity Vees that they support.

Solution Realization

Defini t ion

Sequ

encean

d

Elaborationo f

Detail

Ass

embl

yan

dP

erfo

rman

ce

Ass

u ran

ceSe

qu e

nce

Stakeholder Requirements

and Implementation

Context

Verification and Validation Planning

Define Entity Requirements (Behavior and Performance)

Define Entity Requirements (Behavior and Performance)

Concept & Architecture

Selection and Design- to

Specification

Concept & Architecture Selection and Design-to

Specification

Buy, Build, Code

Buy,Build,Code

Verification –Inspection, Test,

Demonstration, Analysis

Verification – Inspection, Test,, Demonstration,

Analysis

Cus

tom

erC

on

firm

atio

n





ValidationValidation

Customer Confirmation

Build- to and

Code- to Artifacts

Build- to and

Code- to Artifacts

Opp

ort

unit

yan

dR

isk

Inve

stig

atio

n

Cu

sto

me r

Con

firm

ati

on

Build- to and

Code- to Artifacts

Build- to and

Code- to Artifacts Verification

Planning

CDR

VerificationVerification

Validation PreparationValidation

PreparationA

no m

aly

Inve

s

mer

Co

nfir

mat

ion



Verification – Inspection, Test,

Demonstration,Analysis

ValidationValidation

Customer Confirmation

Build- to and

Code- to Artifacts

Build- to and

Code- to Artifacts

Opp

ort

unit

yan

dR

isk

Inve

stig

atio

n

Cu

sto

me r

Con

firm

ati

on

Build- to and

Code- to Artifacts

Build-toand

Code-toArtifacts Verification

Planning

CDR

VerificationVerification

Validation Preparation

Validation Preparation

An

o mal

yIn

vest

igat

ion

Entity Vee

PDR

cott_c19.qxd 7/5/05 3:08 PM Page 349

350

Figure 19.11 Architecture and Entity Vees intersecting.

System

Subsystem

System

Subsystem

EntityEntity Requirements,

System SystemSystem

Subsystem

EntityLowestConfiguration

Item

LowestConfiguration

Item

Subsystem

Architecture Vee

Entity Vees

Figure 19.12 Dual Vee with DAR and VAR.

System

Subsystem


Validation

Subsystem

EntityEntity

Verification and Validation

System

Subsystem


Validation


Validation

Subsystem

EntityEntityEntity

DARVAR

Requirements, Concept,Architecture, Design-to,Build-to, and Verification






Verification and Preparation for


Verification and Preparation for


cott_c19.qxd 7/5/05 3:08 PM Page 350


Phasing of Decision Gates

Lowest configuration items and subsystems are developed and in-tegrated into the architecture using interleaved phases. The activi-ties are ordered in accordance with systems engineering bestpractices. Figures 19.3 through 19.9 reveal the sequence in detail.Figure 19.13 adds a three-dimensional view to clarify the phasingin relationship to the Entity Vees. The design-to and build-to deci-sion gates are repeated to emphasize proper process sequence andf low:

Design-to (Preliminary Design Review, PDR).Build-to (Critical Design Review, CDR).

For simplicity of illustration, only one Entity Vee is shown inter-secting the Architecture Vee at each decomposition level. Note thatthe design-to sequence is top down, starting at the system level andproceeding down through decomposition to the LCI level. This se-quence ensures that there is proper requirements allocation andf lowdown from the system down through each decomposition levelto the LCI.

When build-to and code-to artifacts, including draft verifica-tion procedures, are ready for baselining, the build-to decision gate

Figure 19.13 Design-to and build-to decision gate sequence.

SystemRequirements, Concept, Architecture, Design-to,

Build- to, and Verification and Validation Plans


Preparation for System Integration and Verification


Validation

Subsystem Requirements, Concept,

Architecture, Design-to, Build-to, and Verification


EntityVerification and Preparation for


Entity Requirements, Concept, Architecture,

Design- to, Build- to, and Verification and Validation

Plans

Subsystem


Validation

Subsystem

EntityVerification and Preparation for


EntityRequirements, Concept, Architecture, Design-to, Build-to, and Verification


Requirements, Concept, Architecture, Design-to, Build-to, and Verification





Validation

EntityVerification andPreparation for


Verification andPreparation for System

Integration andVerification

Design-to and Build-toDecision Gate Sequence

cott_c19.qxd 7/5/05 3:08 PM Page 351


sequence is conducted to prove the feasibility of building or codingthe designs. The review also confirms that, if the solution is builtaccording to the build-to artifacts, the required performance willbe achieved. The build-to sequence is bottom up, starting with theLCI and proceeding upward through the decomposition levels tothe system level. This sequence ensures that, if the entity designs ata particular level of decomposition are producible and satisfy theirdesign-to requirements, the entities will integrate into the nexthigher-level entity. This review sequence ensures that the entiresystem is buildable, will perform as expected, and will satisfy theusers.

AGILE DEVELOPMENTPRACTICING IN-PROCESS VALIDATION

The preceding discussions have emphasized the benefits of orderly,hierarchical baseline progression followed by a corresponding veri-fication sequence. Recognizing that the development process mayrequire more f lexibility in some circumstances, the wheel-and-axleprocess model provides a tailoring framework, based on opportunityto simplify development methods and to assess the risks in so doing.The extent of tailoring is determined by whether the opportunity toshorten the project cycle is worth the risk of doing the developmentsteps out of sequence or in parallel.

The Agile Alliance is dedicated to developing iterative and agilemethods, seeking a faster and better approach to software and system development, and challenging more traditional models.There are many references describing the agile concepts (www.agilealliance.com). Craig Larman addresses agile methods in thecontext of UML and iterative development.2 The key objective isf lexibility and allowing selected events to be taken out of sequence(as illustrated in Figure 19.14) when the risk is acceptable.

The features that distinguish agile development from the con-ventional approach are velocity and adaptability. While marketstrategies often emphasize that time to market or speed is critical, amore appropriate criterion is velocity, which adds direction to speed.By incorporating the customer into their working-level teams, theagile developers are ensuring that they are going in a direction thatsatisfies the customer’s highest needs first. This is in-process valida-tion in action. By adopting the following seven key practices of agilesystems engineering, any organization can improve its velocity to cus-tomer satisfaction:

cott_c19.qxd 7/5/05 3:08 PM Page 352


1. The project team understands, respects, works, and behaveswithin a defined systems engineering process. The process issystemic in the organization and implicit to the participants.

2. The project is executed as fast as possible with minimum downtime or staff diversion during the project. Every opportunity isexercised to move the project forward, especially for the criticalpath activities.

3. All key players are physically or electronically collocated. Othercontributors are available online 24/7.

4. There is a strong bias for automatically generated electronic doc-umentation. Engineers rely on their tools and their ElectronicEngineering Notebooks to record decision rationale. Artifacts foroperations and replication are done only if necessary—not to sup-port an existing bureaucracy or policy. Notebooks are team prop-erty and are available to all.

5. Baseline management and change control is achieved by formal,oral agreements based on “make a promise, keep a promise” dis-cipline—participants hold each other accountable. Decisiongate agreements are confirmed with a binding handshake. For-mality relates to the binding of the action not the amount ofdocumentation.

6. Opportunity exploration and risk reduction are accomplished byexpert consultation and rapid model verification, coupled withclose customer collaboration. Software development is done in a

Figure 19.14 Hierarchical baseline elaboration (left) and Nonhierarchical baseline elaboration (right).

cott_c19.qxd 7/5/05 3:08 PM Page 353


rapid development environment, while hardware is developed ina multidisciplined model shop. There is no resistance or inertiato securing expert help; it is sought rather than resisted.

7. A culture of constructive confrontation pervades the project or-ganization. Issues are actively sought. Anyone can identify anissue and pass it on to the most likely solver. No issue is left unre-solved. The team takes ownership for success; it is never “some-one else’s responsibility.”

TECHNICAL DEVELOPMENT TACTICS

Development and delivery decisions are usually driven by the businesscase in response to the demands of the market or the customer. Theseresult in a business strategy that is then achieved through implementa-tion tactics. While the project manager needs to be well versed in thebusiness case, the systems engineer needs to fully appreciate the f lex-ibility of the project to accommodate and benefit from the various tac-tical development and delivery approaches. To arrive at the bestdecision for the sake of the market and the project, the project man-ager and the systems engineer must collaborate until consensus isreached. Then, the decision must be baselined and communicated tothe project team so that the tactics can be built into all planning.

The strategic goals of a project drive the development tactics.For instance, if the goal is to upgrade the solution over time with

Figure 19.15 Technical development tactics.

DeliveryMethod MultipleSingle MultipleSingleSingle MultipleSingle

PrimaryDevelopmentMethod

IncrementalUnified

SecondaryDevelopmentMethod

EvolutionaryLinearEvolutionaryLinear

Vee

SystemRequirements

SystemRequirements



Preliminary DesignPreliminary Design

DetailedDesign

DetailedDesign

Code and Debug

Code and Debug

Test andPre- operations


Operations and Maintenance


?

?

?

?

?

?

?

?

?

?

?

?

SystemRequirements

SystemRequirements




DetailedDesign

DetailedDesign

Code and Debug

Code and Debug





?

?

?

?

?

?

?

?

?

?

?

?

SystemRequirements

SystemRequirements




DetailedDesign

DetailedDesign

Code and Debug

Code and Debug





??

??

??

??

??

??

??

??

??

??

??

??

Waterfall Spiral

DevelopmentModel

cott_c19.qxd 7/5/05 3:08 PM Page 354


newly developed improvements, then selecting an architecture withincrements configured for easy upgrading and fielding may be thebest tactical approach. Similarly, if the goal is to migrate technologyinto the solution over time, then an evolutionary development ap-proach with delivery of successive versions is appropriate, each withpotential for increased capability.

Figure 19.15 illustrates the decisions to be made for each archi-tecture entity regarding development models, development meth-ods, and delivery methods.

Waterfall and Spiral

At the highest level, the most effective models must be selected toaddress the development challenge. All three models shown in Fig-ure 19.15 can be effective, but each emphasizes different aspects ofsystem development. The objective of Royce’s Waterfall model, dis-cussed in Chapter 7 and illustrated in Figure 7.8, is to convert undis-ciplined software development into an orderly linear phased processand it does just that. However, as critics point out, it does not ad-dress complexities of architecture development or risk management.The Waterfall model is sometimes blamed for the significant soft-ware failures of the 1980s and 1990s since the model does not showiterative expansion and refinement of requirements.

The Spiral (Figure 7.9) is a widely used risk-driven model thataddresses some of the shortcomings of the Waterfall model.3 Boehm’sobjective was to focus on risk prior to development. Boehm dealt withrisk by adding early requirements understanding, technical feasibil-ity, and operational scenario investigations (prototyping) to the frontend of Royce’s Waterfall. The Spiral model is effective in emphasiz-ing the risk-reduction objective, but it is silent on both architecturedevelopment and the development risks commonly experienced in theWaterfall phases.

The Dual Vee model, described earlier, is the third developmentmodel choice.

There are two primary development methods, unified or incre-mental (Figure 19.15). Unified is effective for entities where de-composition into an architecture with separate deliverable elementsor modules is not practical. Examples include the physical structureof a spacecraft, a simple software application, and the concretefoundation of a building.

The alternative to unified development is to decompose the con-cept into an architecture having entities to be developed incremen-tally (i.e., separately for later integration; Figure 7.13). This tactic

Incremental developmentprovides for staged develop-ment and delivery followed byupgrades to the incrementsas needed.

cott_c19.qxd 7/5/05 3:08 PM Page 355


usually allows parallel development, assigning experts to each incre-ment, and f lexibility to accommodate funding and schedule con-straints. Incremental development is used, for example, in productlines such as automobiles where engines, chassis, and transmissionsare separately developed and then integrated into a complete automo-bile at the final assembly plants. Incremental development can planfor subsequent upgrading by increment. In the automobile example,increments that are later discovered to be faulty can be recalled andreplaced in the field. In software, incremental development can startwith the most important requirement and complete an increment thatsatisfies it. Then building on that verified increment, the thrust wouldbe to satisfy the second requirement and so on. With this incrementalapproach, each increment is built on the previous set resulting in onesingle delivery. However, later upgrades to internal increments arenot possible. The integrated set must be upgraded.

As illustrated by Figure 19.15, there are two alternative sec-ondary methods, linear and evolutionary. Linear development is thesingle path approach where the requirements and the solution aresufficiently well understood to allow straightforward design and im-plementation without iteration or experimentation. The installationof electrical and plumbing systems in home construction is a linearapproach developed over years of experience. No iteration or exper-imentation is required or desired.

Evolutionary development is appropriate where experimentationor investigation is necessary to determine the best solution. This ap-proach works well for uncertain requirements, pursuit of opportuni-ties and risks, or the pursuit of alternate concepts and solutions, andis common to research projects. A disadvantage of the evolutionaryapproach is unpredictability of progress. As a result, cost and sched-ule estimates are guesses. The evolution of Microsoft’s Windows op-erating system is an example of evolutionary development providing aseries of versions over the years with occasional increment upgradesto deal with user bugs and new security threats (Figure 19.16). Win-dows’ past delivery record demonstrates that evolutionary develop-ment schedules are rarely met.

After selecting the development method, the delivery decisionscan be made. For unified, linear development, only a single deliveryoccurs. Incremental, with or without evolutionary development, re-quires a decision to field the system in a single delivery or to deliverincrements and versions of increments to gradually increase solutioncapability over time. This decision can be driven by the urgency for asolution to be fielded, the staggered availability of functional capabil-ity, funding limitations, regulatory constraints, or any other factorsmaking staged fielding beneficial.

Evolutionary developmentprovides for investigation andexperimentation to develop acapability. Delivery is usuallyin entity versions, each deliv-ering improved performance.Increments can be developedusing the evolutionaryapproach.

cott_c19.qxd 7/5/05 3:08 PM Page 356


The tailored project cycle must ref lect the tactics of the devel-opment and delivery methods. Figures 19.16, 19.17, and 19.18 pro-vide simplified Vee Model visualizations for three of the tacticalmethod combinations.

By their nature, bridges and tunnels require single delivery.Light rail systems are usually built in increments delivered and con-nected over time to ultimately result in an entire transportation sys-tem (Figure 19.17). If requirements are unstable and the technologyis emerging, then an incremental evolutionary approach will enablelow-risk increments to proceed while experimentation and modelingis carried out on the high-risk increments (Figures 7.13 and 19.18).4

SELECTION OF TECHNICAL DEVELOPMENTTACTICS DETERMINES THE CRITICAL PATH

Much has been written about the definition and management of thecritical path. It is widely understood that the critical path is the se-quence of project activities that cannot be shortened, thereby deter-mining the length of the project schedule. It is the task sequencewith zero slack. Critical paths result from a combination of planned

Figure 19.16 Evolutionary development: Used for increasing capability in successive versions.

Unified/Evolutionary DevelopmentSingle or Multiple Version Deliveries

Example:• Windows NT• Windows 2000• Windows XP

PossibleVersion

Deployment

Verification

Code, Fab,and Assemble

PDR

PossibleVersion

Deployment

VerificationUpdatePDR

Version Acceptanceand Deployment

UpdatePDR Verification


UpdatePDR


UpdatePDR Verification

cott_c19.qxd 7/5/05 3:08 PM Page 357

Figure 19.18 Incremental development—incremental delivery, with evolutionary iterations on increment 3.

Incremental/Linear and Evolutionary DevelopmentSingle or Multiple Deliveries

Increment 1 PDR

Code, Fab, Assemble

Increment 3PDR

Increment 2PDR

System PDR

Increment 1 PDR

Code, Fab, Assemble

Increment 3PDR

Increment 2PDR

System PDR

Code, Fab, Assemble

Increment 3PDR

Increment 2PDR

System PDR

Incre1+2

Verif.& Possible

Delivery

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR

Increment 3 Evolutionary Development

Version 1

Incre1+2

Verif.& Possible

Delivery

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR


Version 1

Incre1+2

Verif.& Possible

Delivery

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR


Version 1

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR


Version 1

SystemAccept& Deliver

Integrate 1+2+3

SystemTRR

Version 2 Version 3


Integrate 1+2+3

SystemTRR


Integrate 1+2+3

SystemTRR

Version 2 Version 3

Figure 19.17 Incremental development—single or multiple delivery.

Incremental/Linear DevelopmentSingle or Multiple Increment Deliveries

Examples:

Multiple Delivery• San Jose Light Rail

– Phase 1 199010 mi of track


– Phase 3 20??X mi of track toadjacent cities

Single Delivery• St. Gotthard Alps Tunnel

- Sedrum Start – 4/1996 - Amsteg Start – 71999- Faido Start – 7/1999- Bodio Start – 9/1999- Erstfeld Start – 1/2002- Commission - 2011

Examples:

Multiple Delivery• San Jose Light Rail



– Phase 3 20??X mi of track toadjacent cities

Single Delivery• St. Gotthard Alps Tunnel

- Sedrum Start – 4/1996 - Amsteg Start – 71999- Faido Start – 7/1999- Bodio Start – 9/1999- Erstfeld Start – 1/2002- Commission - 2011

Code, Fab, Assemble Units

Increment 3PDR

Increment 2PDR

Code, Fab, Assemble Units

Increment 3PDR

Increment 2PDR

Increment 1 PDR

System PDR

Increment 1 PDR

System PDR

Incre1+2

Verif.& Possible

Delivery


Integrate 1+2+3

SystemTRR

Incre1+2

Verif.& Possible

Delivery


Integrate 1+2+3

SystemTRR

Incre1+2

Verif.& Possible

Delivery


Integrate 1+2+3

SystemTRR


Integrate 1+2+3

SystemTRR

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR

Incre 1Verif.

& Possible Delivery

Incre 1TRR

Incre1+2

TRR

cott_c19.qxd 7/5/05 3:08 PM Page 358


activities and unplanned reactive activities such as late suppliersand quality problems.

As discussed in Chapter 12, the management of the critical pathis usually focused on the task schedules and their dependencies, asrepresented by the structure of the project network. But prema-turely focusing on precise calculation of the critical path may bemissing the forest for the trees. The purpose of this section is tohighlight the interdependency between the technical developmenttactics and the critical path throughout the project cycle.

Deployment strategies have a strong inf luence on the criticalpath, especially the early part. A strategy might be to capture mar-ket share by deploying a system solution quickly even though itmight not initially achieve its full performance goals. Another strat-egy might be to field a system that is easily upgradeable after intro-duction to provide after-market sales. The resulting developmenttactics, selected for system entities, determine the connectionsamong tasks and the relationships that form the project network.When the predicted task schedules are applied, their summation de-termines the length of the critical path.

In considering the development tactics, we sometimes misjudgethe importance of integration, verification, and validation (IV&V)tactics. Projects that require the ultimate in reliability will usuallyadopt a bottom up step-by-step IV&V sequence of proving perfor-mance at every entity combination. High-quantity production sys-tems may skip verification once the production processes have beenproven to reliably produce perfect products. Yet other projects mayelect a “threaded” or “big bang” verification approach. It is not un-common for different project entities to embrace different task-dependent verification and validation tactics. The tasks associatedwith these tactical decision activities must also be incorporated intothe critical path to accurately represent the planned approach. Thesesystem integration and verification activities will almost always be onthe critical path. The next chapter addresses IV&V in detail.

ARTIFACTS AND THEIR ROLES

Project management artifacts are the results of communicationamong the project participants. Documentation is the most commonartifact, but models, products, material samples, and even white-board sketches are valid artifacts. Artifacts are representations offacts and can be binding when used as such. Some projects managedin a bureaucratic environment develop too many artifacts withoutregard to their purpose and ultimate use. The three fundamentalroles that artifacts fulfill are (Figure 19.19):

cott_c19.qxd 7/5/05 3:08 PM Page 359


1. Manage the elaboration of the development baseline. Since allteam members should be working to the most current elaboration,it needs to be communicated among the team. The artifacts canrange from oral communication to volumes of documentation. Ina small skunk works team environment, whiteboard sketches arehighly effective as long as they are permanent throughout thetime they are needed (simply writing SAVE across the board maynot be strong enough). These artifacts include system require-ments, concept definition, architecture, design-to specifications,build-to documentation, and as-built documentation.

2. Communicate to the verification and operations personnel whatthey need to know to carry out their responsibilities. These arti-facts communicate the expected behavior over the anticipatedoperational scenarios. These artifacts include user ’s manuals,operator ’s manuals, practice scenarios, verification plans, veri-fication procedures, validation plans, and validation procedures.

3. Provide for repair and replication. These must represent the as-operated configuration, which should include all modificationsmade to the as-built baseline. These artifacts include the as-builtartifacts together with all modifications incorporated, processspecifications, parts lists, material specifications, repair manu-als, and source code.

Figure 19.19 The three roles for artifacts.

Verification& Operations

Artifactsprovide the

ability to verify and operate as

expected.


ability to verify and operate as

expected.

Managing the Solution DevelopmentManaging the Solution Development

BaselineElaboration

Artifactscontrol the

solutionmaturation.

Artifactscontrol the

solutionmaturation.

Replication& Repair


ability to repair and replicate as designed.


ability to repair and replicate as designed.

cott_c19.qxd 7/5/05 3:08 PM Page 360

361

20INTEGRATION,VERIFICATION,AND VALIDATION

Chapter 7 addressed integration, verification, and validation(IV&V) as represented by the Vee Model and in relationship to

the systems engineering role. In Chapter 9, the planning for IV&Vwas emphasized in the Decomposition Analysis and Resolution pro-cess, followed by a broad implementation overview in the Verifica-tion Analysis and Resolution process. This chapter addresses theimplementation of IV&V in more depth.

Successful completion of system-level integration, verification,and validation ends the implementation period and initiates the op-erations period, which starts with the production phase if more thanone article is to be delivered. However, if this is the first point inthe project cycle that IV&V issues have been considered, the team’sonly allies will be hope and luck, four-letter words that should not bepart of any project’s terminology manual.

We have emphasized that planning for integration and verifica-tion starts with the identification of solution concepts (at the system,subsystem, and lowest entity levels). In fact, integration and verifica-tion issues may be the most significant discriminators when selectingfrom alternate concepts. Equally important, the project team shouldnot wait until the end of the implementation period to determine ifthe customer or user(s) likes the product. In-process validation shouldprogress to final validation when the user stresses the system to en-sure satisfaction with all intended uses. A system is often composed ofhardware, software, and firmware. It sometimes becomes “shelfware”

Integration: The successivecombining and testing of sys-tem hardware assemblies,software components, andoperator tasks to progressivelyprove the performance andcapability of all entities of thesystem.

Verification: Proof of compli-ance with specifications.

Was the solution built right?

Validation: Proof that theuser(s) is satisfied.

Was the right solution built?

When an error reaches thefield, there have been twoerrors. Verification erred byfailing to detect the fieldederror.

cott_c20.qxd 6/30/05 3:55 PM Page 361


Verification complexityincreases exponentially withsystem complexity.

In cases of highest risk, Inde-pendent Verification and Vali-dation is performed by a team that is totally indepen-dent from the developingorganization.

when the project team did not take every step possible to ensure useracceptance. Yet, this is a frequent result, occurring much too often.Most recently, the failure of a three-year software development pro-gram costing hundreds of millions of dollars has been attributed tothe unwillingness of FBI agents to use the system (a validation fail-ure). These surprise results can be averted by in-process validation,starting with the identification of user needs and continuing with userconfirmation of each elaboration of the solution baseline.

IV&V has a second meaning: independent verification and vali-dation used in high-risk projects where failure would have profoundimpact. See the Glossary for a complete definition. Examples are thedevelopment of the control system for a nuclear power plant and theon-board f light-control software on the space shuttle. The IV&Vprocess on the shuttle project resulted in software that had an im-pressively low error rate (errors per thousand lines of code) that wasone-tenth of the best industry practice. Proper developmentprocesses do work.

In the project environment, IV&V is often treated as if it werea single event. This chapter details each of these three distinctprocesses. Integration is discussed first. Then the discussion of ver-ification covers design verification, design margin verification andqualification, reliability verification, software quality verification,and system certification. Validation covers issues in interactingwith users, both external and internal to the project team. In clos-ing, anomaly management addresses the unexpected.

INTEGRATION

The integration approach will drive the key details of the productbreakdown structure (PBS), the work breakdown structure (WBS),the network logic, and the critical path. Interface specifications de-fine the physical and logical requirements that must be met by enti-ties on both sides of the interface. These specifications must coverboth internal interfaces as well as those external to the system. Along-standing rule is to keep the interfaces as simple and fool proofas possible.

Integration takes place at every level of the system architecture.The PBS (see examples in margin opposite Figure 20.1) identifieswhere these interfaces occur. In Figure 20.1, the N2 diagram illus-trates relationships between system entities and relates the entitiesto the PBS. The entities are listed on the diagonal of the matrix, withoutputs shown in the rows and inputs in the columns. For instance,

Integration: The successivecombining and testing of sys-tem hardware assemblies,software components, andoperator tasks to progressivelyprove the performance andcapability of all entities of thesystem.

cott_c20.qxd 6/30/05 3:55 PM Page 362

INTEGRATION, VERIFICATION, AND VALIDATION 363

Entity B has input from Entities A and C, as well as input from out-side the system. In Figure 20.1, Entity B provides an output externalto the system. Interfaces needing definition are identified by the ar-rows inside the cells. The BMW automobile manufacturer has suc-cessfully used a similar matrix with over 270 rows and columns toidentify critical interface definitions.

Integration and verification planning, which must have projectmanagement focus from the outset, begins in the concept develop-ment phase. The planning must answer the following questions:

• What integration tasks are needed?• Who will perform each task?• Where will the task be performed?• What facilities and resources are needed?• When will the integration take place?

Integration and verification plans should be available at the design-to decision gate.

There are four categories of integration:

1. Mechanical:• Demonstrates mechanical compatibility of components.• Demonstrates compliance with mechanical interface speci-

fications.2. Electrical:

• Demonstrates electrical /electronic compatibility of com-ponents.

• Demonstrates compliance with electrical interface require-ments.

Figure 20.1 Interfaces illustrated by the N2 and PBS diagrams.

ABCD

A B C D

ABCD

A B C D

OA

BI

OA

DI

OC

DIOC

BI

OC

AI

OD

AI

OD

CI

A

OutputInput

OutputInput

B

C

D

Output

OA

BI

OAOA

BIBI

OA

DI

OAOA

DIDI

OC

DI

OCOC

DIDIOC

BI

OCOC

BIBI

OC

AI

OCOC

AIAI

OD

AI

ODOD

AIAI

OD

CI

ODOD

CICI

AAA

OutputInput

OutputInput

OutputInput OutputInput

BBB

CCC

DDD

Output

ABCD

A

AB CD

C D

A

DCAB

ABCD

B

B

Integration Planning

cott_c20.qxd 6/30/05 3:55 PM Page 363


3. Logical:• Demonstrates logical (protocol) compatibility of components.• Demonstrates the ability to load and configure software.

4. Functional:• Demonstrates the ability to load, configure, and execute solu-

tion components.• Demonstrates functional capability of all elements of the so-

lution working together.

Integration can be approached all at once (the “big bang”) or in-crementally. Except for very simple systems, the big-bang approachis generally considered too risky. Table 20.1 shows four incrementalapproaches. Three of these (top-down, bottom-up, and thread) areillustrated in Figure 20.2. Each approach is valid, and the choice de-pends on the project circumstances.

Interface management to facilitate integration and verificationshould be responsive to the following:

• The PBS portion of the WBS should provide the road map forintegration.

• Integration will exist at every level in the PBS except at the toplevel.

• Integration and verification activities should be represented bytasks within the WBS.

Table 20.1 Incremental Integration Approaches

Technique Features

Top-down Control logic testing first.Modules integrated one at a time.Emphasis on interface verification.

Bottom-up Early verification to prove feasibility and practicality.Modules integrated in clusters.Emphasis on module functionality and performance.

Thread Top-down or bottom-up integration of a softwarefunction or capability.

Mixed Working from both ends toward the middle.Choice of modules designated top-down versus bottom-up is critical.

cott_c20.qxd 6/30/05 3:55 PM Page 364


• The WBS is not complete without the integration and verifica-tion tasks and the tasks to produce the products (e.g., fixtures,models, drivers, databases) required to facilitate integration.

• Interfaces should be designed to be as simple and foolproofas possible.

• Interfaces should have mechanisms to prevent inadvertent in-correct coupling (for instance, uniquely shaped connectors suchas the USB and S-Video connectors on laptop computers).

• Interfaces should be verified by low-risk (benign) techniquesbefore mating.

• “OK to install” discipline should be invoked before all matings.• Peer review should provide consent-to authorization to proceed.• Haste without extra care should be avoided. (If you cannot pro-

vide adequate time or extra care, go as fast as you can so therewill be time to do it over . . . and over. . . .)

Integration Issues

• Clear definition, documentation, and management of the inter-faces are key to successful integration.

Figure 20.2 Alternative incremental integration approach tactics.

Stub

B

Stub

GE

DC

F

Drivers

Top-Down

Not yet integrated

Already integrated

ImplementsRequirement A

A

B L

M

Stub

KD

IH

Driver (simulate)Requirement A

G

Threaded

Driver

B L

K

I

D

HG

Bottom-Up Driver/Stub

J

Stub

Driver/Stub

J

Stub

Stub

Legend:

Drivers and StubsSpecial test items to simulate the start (Driver) or end (Stub) of a chain

cott_c20.qxd 6/30/05 3:55 PM Page 365


• Coordination of schedules with owners of external systems is es-sential for integration into the final environment.

• Resources must be planned. This includes the development ofstub and driver simulators.

• First-time mating needs to be planned and carefully performed,step-by-step.

• All integration anomalies must be resolved.• Sometimes it will be necessary to fix the “other person’s”

problem.

Risk: The Driver of Integration/Verification Thoroughness

It is important to know the project risk philosophy (risk tolerance) ascompared to the opportunity being pursued. This reward-to-riskratio will drive decisions regarding the rigor and thoroughness of in-tegration and the many facets of verification and validation. There isno standard vocabulary for expressing the risk philosophy, but it isoften expressed as “quick and dirty,” “no single point failure modes,”“must work,” “reliability is 0.9997,” or some other expression or acombination of these. One client reports that their risk tolerantclient specifies a 60 percent probability of success. This precise ex-pression is excellent but unusual. The risk philosophy will determinewhether all or only a portion of the following will be implemented.

VERIFICATION

If a defect is delivered within a system, it is a failure of verificationfor not detecting the defect. Many very expensive systems have failedafter deployment due to built-in errors. In every case, there were twofailures. First the failure to build the system correctly and second thefailure of the verification process to detect the defect. The most fa-mous is the Hubble telescope delivered into orbit with a faulty mir-ror. There are many more failures just as dramatic that did not makenewspaper headlines. They were even more serious and costly, butunlike the Hubble, they could not be corrected after deployment.

Unfortunately, in the eagerness to recover lost schedule, verifi-cation is often reduced or oversimplified, which increases thechances of missing a built-in problem.

There are four verification methods: test, demonstration, analy-sis, and inspection. While some consider simulation to be a fifthmethod, most practitioners consider simulation to be one of—or acombination of—test, analysis, or demonstration.

Verification management:Proof of compliance withspecifications.

Was the solution built right?

cott_c20.qxd 6/30/05 3:55 PM Page 366


Verification Methods DefinedTest (T): Direct measurement of performance relative to func-tional, electrical, mechanical, and environmental requirements.Demonstration (D): Verification by witnessing an actual opera-tion in the expected or simulated environment, without need formeasurement data or post demonstration analysis.Analysis (A): An assessment of performance using logical, math-ematical, or graphical techniques, or for extrapolation of modeltests to full scale.Inspection (I): Verification of compliance to requirements thatare easily observed such as construction features, workmanship,dimensions, configuration, and physical characteristics such ascolor, shape, software language used, and so on.

Test is a primary method for verification. But as noted previ-ously, verification can be accomplished by methods other than test.And tests are run for purposes other than verification (Figure 20.3).Consequently, extra care must be taken when test results will beused formally for official verification.

Engineering models are often built to provide design feasibil-ity information. The test article is usually discarded after test com-pletion. However, if the test article is close to the finalconfiguration, with care in documenting the test details (setup,equipment calibration, test article configuration, etc.), it is possi-ble that the data can be used for design verification or qualifica-tion. The same is true of a software development prototype. If care

Figure 20.3 Test and verification.

cott_c20.qxd 6/30/05 3:55 PM Page 367


is used in documenting the test stubs, drivers, conditions, andsetup, it might be possible to use the development test data for ver-ification purposes.

The management of verification should be responsive to lessonslearned from past experience. Eight are offered for consideration:

1. A requirements traceability and verification matrix (RTVM)should map the top-down decomposition of requirements andshould also identify the integration level and method for theverification. For instance, while it is desirable to verify all re-quirements in a final all-up systems test, there may be require-ments that cannot be verified at that level. Often there arestowed items at the system level that cannot and will not be de-ployed until the system is deployed. In these instances, verifi-cation of these entities must be achieved at a lower level ofintegration. The RTVM should ensure that all required verifi-cation is planned for, including the equipment and faculties required to support verification at each level of integra-tion. An example of a simple RTVM for a bicycle is shown inFigure 20.4.

2. The measurement units called out in verification proceduresshould match the units of the test equipment to be used. For ex-ample, considerable damage was done when thermal chamberswere inadvertently set to 160 degrees centigrade although theverification procedure called for 160 degrees Fahrenheit. In an-other instance, a perfectly good spacecraft was destroyed whenthe range safety officer, using the wrong f light path dimensions,destroyed it during ascent thinking it was off course. Unfortu-nately, there are too many examples of perfect systems beingdamaged by error.

3. Redline limits are “do not exceed” conditions, just as the redline on a car ’s tachometer is designed to protect the car ’s en-gine. Test procedures should contain two types of redline lim-its. The first should be set at the predicted values so that ifthey are approached or exceeded the test can be halted and aninvestigation initiated to determine why the predictions andactual results don’t correlate. The second set of redline limitsshould be set at the safe limit of capability to prevent failure ofthe system or injury to personnel. If these limits are ap-proached the test should be terminated and an investigationshould determine the proper course of action. One of theworld’s largest wind tunnels was destroyed when the test pro-cedures that were required to contain redline limits did not.

cott_c20.qxd 6/30/05 3:55 PM Page 368


During system verification, the testers unknowingly violatedengineering load predictions by 25 times, taking the system tostructural failure and total collapse. The failure caused a four-year facility shutdown for reconstruction.

4. A test readiness review should precede all testing to ensurereadiness of personnel and equipment. This review should in-clude all test participants and should dry run the baselined ver-ification procedure, including all required updates. Equipmentused to measure verification performance should be confirmedto be ‘‘in calibration,” projected through the full test durationincluding the data analysis period.

5. Formal testing should be witnessed by a “buyer” representativeto officially certify and accept the results of the verification.Informal testing should precede formal testing to discover andresolve all anomalies. Formal testing should be a predeterminedsuccess based on successful informal testing.

Figure 20.4 Requirements traceability and verification matrix (RVTM) example.

Level Rev ID Name

Makeor

Buy Requirement Predecessor Verification0 0 0.0 Bicycle System M 0.0.1 "Light Wt" - <105% of Competitor "User Need" Doc ¶ 1 0.0.1 Assess Competition Auditor Date

0 0 0.0 Bicycle System M 0.0.2 "Fast" - Faster than any other bik "User Need" Doc ¶ 2 0.0.2 Win Tour de France

1 0 1.1 Bicycle M 1.1.1 8.0 KG max weight 0.0.1, Marketing 1.1.1 Test (Weigh bike)

1 0 1.1 Bicycle M 1.1.2 85 cm high at seat Racing rules ¶ 3.1 1.1.2 Test (Measure bike)

1 0 1.1 Bicycle M 1.1.3 66 cm wheel dia Racing rules ¶ 4.2 -- Verif at ass'y level

1 0 1.1 Bicycle M 1.1.4 Carry one 90 KG rider Racing rules ¶ 2.2 1.1.4 Demonstration

1 0 1.1 Bicycle M 1.1.5 Use advanced materials Corporate strategy ¶ 6a -- Verif at ass'y level

1 0 1.1 Bicycle M 1.1.6 Survive FIVE seasons Corporate strategy ¶ 6b 1.1.6 Accelerated life test

1 0 1.1 Bicycle M 1.1.7 Go VERY fast (>130 kpm) 0.0.2 1.1.7 Test against benchmark

1 0 1.1 Bicycle M 1.1.8 Paint frame Red, shade 123 Marketing 1.1.8 Inspection

1 0 1.2 Packaging B 1.2.1 Packaged for Shipment 0.0.4, Marketing

1 1 1.2 Packaging B 1.2.1 Photo of "Hi Tech" Wheel on Box 0.0.4, Marketing

1 0 1.2 Packaging B 1.2.2 Survive 2 m drop Industry std

1 1 1.3 Documentation M 1.3.1 Assembly Instructions 0.0.4

1 1 1.3 Documentation M 1.3.2 Owner's Manual 0.0.4

2 0 2.1 Frame Assembly B 2.1.1 Welded Titanium Tubing 1.1.5, 1.1.6

2 0 2.1 Frame Assembly B 2.1.2 Maximum weight 2.5 KG 1.1.1, allocation

2 0 2.1 Frame Assembly B 2.1.3 Demo 100 K cycle fatigue life 1.1.6

2 0 2.1 Frame Assembly B 2.1.4 Support 2 x 90 KG 1.1.4, 1.1.6

• •• •• •

Level Rev ID Name

Makeor

Buy Requirement Predecessor Verification0 0 0.0 Bicycle System M 0.0.1 "Light Wt" - <105% of Competitor "User Need" Doc ¶ 1 0.0.1 Assess Competition Auditor Date

0 0 0.0 Bicycle System M 0.0.2 "Fast" - Faster than any other bike "User Need" Doc ¶ 2 0.0.2 Win Tour de France

1 0 1.1 Bicycle M 1.1.1 8.0 KG max weight 0.0.1, Marketing 1.1.1 Test (Weigh bike)

1 0 1.1 Bicycle M 1.1.2 85 cm high at seat Racing rules ¶ 3.1 1.1.2 Test (Measure bike)

1 0 1.1 Bicycle M 1.1.3 66 cm wheel dia Racing rules ¶ 4.2 -- Verif at ass'y level

1 0 1.1 Bicycle M 1.1.4 Carry one 90 KG rider Racing rules ¶ 2.2 1.1.4 Demonstration

1 0 1.1 Bicycle M 1.1.5 Use advanced materials Corporate strategy ¶ 6a -- Verif at ass'y level

1 0 1.1 Bicycle M 1.1.6 Survive FIVE seasons Corporate strategy ¶ 6b 1.1.6 Accelerated life test

1 0 1.1 Bicycle M 1.1.7 Go VERY fast (>130 kpm) 0.0.2 1.1.7 Test against benchmark

1 0 1.1 Bicycle M 1.1.8 Paint frame Red, shade 123 Marketing 1.1.8 Inspection

1 0 1.2 Packaging B 1.2.1 Packaged for Shipment 0.0.4, Marketing

1 1 1.2 Packaging B 1.2.1 Photo of "Hi Tech" Wheel on Box 0.0.4, Marketing

1 0 1.2 Packaging B 1.2.2 Survive 2 m drop Industry std

1 1 1.3 Documentation M 1.3.1 Assembly Instructions 0.0.4

1 1 1.3 Documentation M 1.3.2 Owner's Manual 0.0.4

2 0 2.1 Frame Assembly B 2.1.1 Welded Titanium Tubing 1.1.5, 1.1.6

2 0 2.1 Frame Assembly B 2.1.2 Maximum weight 2.5 KG 1.1.1, allocation

2 0 2.1 Frame Assembly B 2.1.3 Demo 100 K cycle fatigue life 1.1.6

2 0 2.1 Frame Assembly B 2.1.4 Support 2 x 90 KG 1.1.4, 1.1.6

• •• •• •

• The project team must verify that every requirement has been met. Verification is performed by:- Test- Demonstration- Inspection- Analysis

• System Engineering is responsible for auditing the verification results and certifying that the evidence demonstrates that requirements have been achieved.

• The project team must verify that every requirement has been met. Verification is performed by:- Test- Demonstration- Inspection- Analysis

• System Engineering is responsible for auditing the verification results and certifying that the evidence demonstrates that requirements have been achieved.

cott_c20.qxd 6/30/05 3:55 PM Page 369


6. To ensure validity of the test results, the signed initials of theresponsible tester or quality control should accompany each offi-cial data entry.

7. All anomalies must be explained with the associated correctiveaction. Uncorrected anomalies must be explained with the pre-dicted impact to system performance.

8. Unrepeatable failures must be sufficiently characterized to de-termine if the customer/users can accept the risk should theanomaly occur during operations.

Design Verification

Design verification proves that the design for the entity will per-form as specified, or conversely, that there are identified designdeficiencies requiring design corrective action (Figure 20.5). De-sign verification is usually carried out in nominal conditions unlessthe design-to specification has design margins already built intothe specified functional performance. Design verification usuallyincludes the application of selected environmental conditions. De-sign verification should confirm the required positive events andthe absence of negative events. That is, things that are supposedto happen do happen, and things that are not supposed to happen

do not.Software modules that are too complex (i.e., they have too many

alternate paths) to verify all possible combinations of events containa residual risk within those that have not been verified. Many organizations have been successful in using informal and formalsoftware inspections to give confidence that software design verifi-cation goals have been achieved (Figure 20.6).

Figure 20.5 Design verification considerations.

Quality Verification Range

ExpectedOperational Range

Quality Verification RangeQuality Verification Range



Design Margin/Qualification Range

Design RangeDesign Range

Provenmargin

Unprovenmargin

Provenmargin

Unprovenmargin

cott_c20.qxd 6/30/05 3:55 PM Page 370


Advocates of Agile methods (including eXtreme Programming)emphasize thorough unit testing and builds (software integration)daily to verify design integrity in-process. Projects that are not agood match for an Agile methodology may still benefit from rigor-ous unit tests, frequent integrations, and automated regression test-ing during periods of evolving requirements and /or frequentchanges.

Design Margin Verification: Qualification

Design margin verification, commonly called qualification, provesthat the design is robust with designed-in margin, or, conversely,that the design is marginal and has the potential of failing whenmanufacturing variations and use variations are experienced. For in-stance, it is reasonable that a cell phone user will at some time dropthe phone onto a concrete surface from about four or five feet. How-ever, should the same cell phone be designed to survive a drop by ahigh lift operator from 20 feet (6 meters)?

Qualification requirements should specify the margin desired.Qualification should be performed on an exact replica of the solu-tion to be delivered. For instance, car crash tests are performed onproduction models purchased from a retail dealer to verify thatmeasured test results are meaningful to the user (the buying public).In general, the best choice is a unit within a group of productionunits. However, since this is usually too late in the project cycle to

Figure 20.6 Software formal inspections.

cott_c20.qxd 6/30/05 3:55 PM Page 371


discover design deficiencies that would have to be retrofitted intothe completed units, qualification is often performed on a first unitthat is built under engineering surveillance to ensure that it is builtexactly as specified and as the designers intended.

Qualification testing usually includes the application of envi-ronment levels and duration to expose the design to the conditionsthat may be accumulated in total life cycle use. Qualification testsmay be performed on replica test articles that simulate a portion ofan entity. For instance, a structural test qualification unit does nothave to include operational electronic units or software; inert masssimulators may be adequate. Similarly, electronic qualification testsdo not need the actual supporting structure since structural simula-tors with similar response characteristics may be used for testing.The exposure durations and input levels should be designed to en-velop the maximum that is expected to be experienced in worst-caseoperation. These should include acceptance testing (which is qualityverification) environments, shipping environments, handling envi-ronments, deployment environments, and any expected repair andretesting environments that may occur during the life of an entity.

Environments may include temperature, vacuum, humidity,water immersion, salt spray, random vibration, sine vibration,acoustic, shock, structural loads, radiation, and so on. For software,transaction peaks, electrical glitches, and database overloads arecandidates. The qualification margins beyond normal expected useare often set by the system level requirements or by the host system.Twenty-degree Fahrenheit margins on upper- and lower-temperatureextremes are typical, and either three or six dB margins on vibra-tion, acoustic, and shock environments are often applied. In somecases, safety codes establish the design and qualification margins,such as with pressure vessels and boiler codes. Software designmargin is demonstrated by overtaxing the system with transactionrate, number of simultaneous operators, power interruptions, andthe like.

To qualify the new Harley-Davidson V Rod motorcycle for “Pa-rade Duty,” it was idled in a desert hot box at 100 degrees Fahrenheit(38 centigrade) for 8 hours. In addition, the design was qualified foracid rain, fog, electronic radiation, sun, heat, structural strength,noise, and many other environments. Actual beyond-specificationfield experience with an exact duplicate of a design is also admissi-ble evidence to qualification if the experience is backed by certifiedmetrics. Once qualification has been established, it is beneficial tocertify the design as being qualified to a prescribed set of condi-

cott_c20.qxd 6/30/05 3:55 PM Page 372


tions by issuing a qualification certification for the exact designconfiguration that was proven. This qualification certification canbe of value to those who desire to apply the same design configura-tion to other applications and must know the environments and con-ditions under which the design was proven successful.

Reliability Verification

Reliability verification proves that the design will yield a solutionthat over time will continue to meet specification requirements.Conversely, it may reveal that failure or frequency of repair is be-yond that acceptable and anticipated.

Reliability verification seeks to prove mean time between fail-ure (MTBF) predictions. Reliability testing may include selectedenvironments to replicate expected operations as much as possible.Reliability verification tends to be an evolutionary process of uncov-ering designs that cannot meet life or operational requirements overtime and replacing them with designs that can. Harley-Davidsonpartnered with Porsche to ultimately achieve an engine that wouldsurvive 500 hours nonstop at 140 mph by conducting a series of evo-lutionary improvements to an engine that initially fell short of meet-ing the requirement.

Life testing is a form of reliability and qualification testing. Lifetesting seeks to determine the ultimate wear out or failure condi-tions for a design so that the ultimate design margin is known andquantified. This is particularly important for designs that erode, ab-late, disintegrate, change dimensions, and react chemically or elec-tronically, over time and usage. In these instances, the design isoperated to failure while recording performance data.

Life testing may require acceleration of the life process whenreal-time replication would take too long or would be too expensive.In these instances, acceleration can be achieved by adjusting thetesting environments to simulate what might be expected over theactual lifetime. For instance, if an operational temperature cycle isto occur once per day, forcing the transition to occur once per hourcan accelerate the stress experience. For software, fault tolerance isthe reliability factor to be considered. If specified, the softwaremust be tested against the types of faults specified and the softwaremust demonstrate its tolerance by not failing. The inability of soft-ware to deal with unexpected inputs is sometimes referred to asbrittleness.

cott_c20.qxd 6/30/05 3:55 PM Page 373


Quality Verification

In his book Quality Is Free, Phillip Crosby defines quality as“conformance to requirements” and the “cost of quality” as the ex-pense of fixing unwanted defects. In simple terms, is the productconsistently satisfactory or is there unwanted scrapping of defec-tive parts?

When multiple copies of a design are produced, it is often diffi-cult to maintain consistent conformance to the design, as materialsuppliers and manufacturing practices stray from prescribed formu-las or processes. To detect consistent and satisfactory quality—aproduct free of defects—verification methods are applied. First,process standards are imposed and ensured to be effective; second,automatic or human inspection should verify that process results areas expected; and third, testing should prove that the ultimate per-formance is satisfactory.

Variations of the process of quality verification include batchcontrol, sampling theory and sample inspections, first article verifi-cation, and nth article verification. Quality testing often incorpo-rates stressful environments to uncover latent defects. For instance,random vibration, sine sweep vibration, temperature, and thermalvacuum testing can all help force latent electronic and mechanicaldefects to the point of detection. Since it is difficult to apply all ofthese environments simultaneously, it is beneficial to expose theproduct to mechanical environments prior to thermal and vacuumenvironments where stressed power-on testing can reveal intermit-tent malfunctions.

Software Quality Verification

The quality of a software product is highly inf luenced by the qualityof the individual and organizational processes used to develop andmaintain it. This premise implies a focus on the development processas well as on the product. Thus, the quality of software is verified bydetermining that development followed a defined process based onknown best practices and a commitment to use it; adequate trainingand time for those performing the process to do their work well; im-plementation of all the process activities, as specified; continuousmeasurement of the performance of the process and feedback to en-sure continuous improvement; and meaningful management involve-ment. This is based on the quality management principles stated byW. Edwards Deming that “Quality equals process—and everythingis process.”

cott_c20.qxd 6/30/05 3:55 PM Page 374


-ilities Verification

There are a number of “-ilities” that require verification. Verifica-tion of -ilities requires careful thought and planning. Several can beaccomplished by a combined inspection, demonstration, and /or testsequence. A verification map can prove to be useful in making cer-tain that all required verifications are planned for and accom-plished. Representative “ilities” are:

Accessibility Hostility ReusabilityAdaptability Integrity ScalabilityAffordability Interoperability SecurabilityCompatibility Liability ServiceabilityCompressibility Maintainability SurvivabilityDegradability Manageability TestabilityDependability Mobility TransportabilityDistributability Portability UnderstandabilityDurability Producibility UsabilityEfficiency Recyclability Variability

Certification

Certification means to attest by a signed certificate or other proofto meeting a standard. Certification can be verification of an-other ’s performance based on an expert’s assurance. In the UnitedStates, the U.S. Food and Drug Administration grades and approvesmeat to be sold, and Consumer Reports provides a “Best Buy”stamp of approval to high-value products. Certification often ap-plies to the following:

• The individual has achieved a recognized level of proficiency.• The product has been verified as meeting/bettering a speci-

fication.• The process has been verified as routinely providing pre-

dictable results.

The ultimate project certification is the system certificationprovided by the chief systems engineer that the solution provided tothe customer will perform as expected. This testimonial is based onthe summation of the verification history and the resolution of allanomalies. Figure 20.7 is an example certification by a chief sys-tems engineer.

cott_c20.qxd 6/30/05 3:55 PM Page 375


VALIDATION AND VALIDATION TECHNIQUES

Most projects produce hardware, software, and /or firmware. Whatis not wanted is shelfware. Shelfware is a product that fails to vali-date, and the user puts it on a shelf or in a warehouse.

Validation is proof that the users are satisfied, regardless ofwhether the specifications have been satisfied or not. Occasionally,a product meets all specified requirements but is rejected by theusers and does not validate. Famous examples are the Ford Edsel,IBM PC Junior, and more recently, Iridium and Globalstar. In eachcase, the products were exactly as specified but the ultimate usersrejected them, causing very significant business failures. Con-versely, Post-It Notes failed verification to the glue specification,but the sticky notes then catapulted into our lives because we allloved the failed result. The permanently temporary or temporarilypermanent nature of the glue was just what we were looking for, butit hadn’t been specified.

Traditionally, validation occurs at the project’s end when theuser finally gets to use the solution to determine the level of satisfac-tion. While this technique can work, it can also cause immense wastewhen a project is rejected at delivery. Too many projects have been

Figure 20.7 CSE system certification example.

Date:

I certify that the system deliveredon will perform as specified. This certification isbased on the satisfactory completion of all verification andqualification activities. All anomalies have been resolved tosatisfactory conclusion except two that are not repeatable. Thetwo remaining are:

1.

2.

All associated possible causes have been replaced andregression testing confirms specified performance. If either ofthese anomalies occurs during the operational mission therewill not be any effect on the overall mission performance.

Signed Chief Systems Engineer (CSE)

Validation: Proof that the user(s)is satisfied.

Was the right solution built?

cott_c20.qxd 6/30/05 3:55 PM Page 376


relegated to scrap or a storage warehouse because of user rejection.Proper validation management can avoid this undesirable outcome.

When considering the process of validation, recognize that ex-cept for the product level having just the ultimate or end user, thereare direct users, associate users, and ultimate users at each decom-position level and for each entity at that level, all of whom must besatisfied with the solution at that level. Starting at the highest sys-tem level, the ultimate user is also the direct user. At the outset, theultimate users should reveal their plans for their own validation sothat developers can plan for what the solution will be subjected toat delivery.

A user validation plan is valuable in documenting and communi-cating the anticipated process. Within the decomposition process, aseach solution concept and architecture is developed, the ultimateusers should be consulted as to their satisfaction with the evolutionof the architecture. In the Agile iterative development process thecustomer is an integral part of the development team, so there is po-tentially continuous feedback. In large system projects and tradi-tional development, a customer representative resident with thedevelopment team can provide ongoing feedback.

The approved concepts become baselined for further decompo-sition and rejected concepts are replaced by better candidates. Thisprocess is called in-process validation and should continue in accor-dance with decomposition of the architecture until the users de-cide that the decisions being made are transparent to their use ofthe system.

This ongoing process of user approval of the solution elaborationand maturation can reduce the probability of user dissatisfaction atthe end to near zero. Consequently, this is a very valuable way toachieve and maintain user satisfaction throughout the developmentprocess and to have no surprise endings. Within the decompositionprocess, validation management becomes more complex. At any levelof decomposition, there are now multiple users (Figure 20.8). Fig-ure 20.9 presents a different view, but with the same message.

The end user is the same. However, there are now direct usersin addition to the end user, and there are associate users who mustalso be satisfied with any solution proposed at that level of decom-position. Consider, for instance, an electrical energy storage devicethat is required by the power system within the overall solution. Thedirect user is the power subsystem manager, and associate users arethe other disciplines that must interface with the storage device’spotential solutions. If a chargeable battery is proposed, then thesupport structure system is a user, as is the thermodynamic system,

cott_c20.qxd 6/30/05 3:55 PM Page 377


among others. In software, a similar situation exists. Software ob-jects have defined characteristics and perform certain specifiedfunctions on request, much like the battery in the prior example.When called, the software object provides its specified service justas the battery provides power when called. Associate users are anyother element of the system that might need the specified serviceprovided by the object. All direct and ultimate users need to approvebaseline elaboration concepts submitted for approval. This in-processvalidation should ensure the integration of mutually compatible ele-ments of the system.

In eXtreme and Agile programming processes, intense user col-laboration is required throughout the development of the project toprovide ongoing validation of project progress. Ultimate user valida-tion is usually conducted by the user in the actual user ’s environment,pressing the solution capability to the limit of user expectations. Uservalidation may incorporate all of the verification techniques that fol-low. It is prudent for the solution developer to duplicate these condi-tions prior to delivery.

Figure 20.8 Three types of users.

Baselinesto be

VerifiedBaselines

to be Verified

Time and Baseline Maturity

Core of the “Vee”Plans, Specifications, and

Products are under Progressive Configuration

Management

Baselinesto be

Verified

ApprovedBaseline

Associate UsersIn-process ValidationD. Is the proposed baseline acceptable?

Direct UserIn-process ValidationD. Is the proposed baseline acceptable?

End UserIn-process ValidationD. Is the proposed baseline acceptable?

Baselinesto be

VerifiedBaselines

to be Verified

Baselinesto be

Considered

Planned Integration,

Verification, and Validation



Baselines being Considered

Baselines being Considered

A. How to combine the entities?B. How to prove the solution is built right?C. How to prove the right solution is built?





cott_c20.qxd 6/30/05 3:55 PM Page 378


ANOMALY MANAGEMENT—DEALING WITH THE UNEXPECTED

Anomalies are deviations from the expected. They may be failuresymptoms or may just be unthought-of nominal performance. Ineither case, they must be fully explained and understood. Anomaliesthat seriously alter system performance or that could cause unsafeconditions should be corrected. Any corrections or changes should befollowed by regression testing to confirm that the deficiency hasbeen corrected and that no new anomalies have been introduced.

The management of anomalies should be responsive to the pastexperience lessons learned. Four are offered for consideration:

1. Extreme care must be exercised to not destroy anomaly evi-dence during the investigation process. An effective approach isto convene the responsible individuals immediately on detect-ing an anomaly. The group should reach consensus on the ap-proach to investigate the anomaly without compromising theevidence in the process. The approach should err on the side ofcare and precaution rather than jumping in with uncontrolledtroubleshooting.

2. When there are a number of anomalies to pursue, they shouldbe categorized and prioritized as Show Stopper, Mission Com-promised, and Cosmetic. Show Stoppers should be addressedfirst, followed by the less critical issues.

Figure 20.9 Three roles of the specification owner.

cott_c20.qxd 6/30/05 3:55 PM Page 379


3. Once the anomaly has been characterized, a second reviewshould determine how to best determine the root cause and thenear- and long-term corrective actions. Near-term correctiveaction is designed to fix the system under verification. Long-term corrective action is designed to prevent the anomaly fromever occurring again in any future system.

4. For a one-time serious anomaly that cannot be repeated no mat-ter how many attempts are made, consider the following:• Change all the hardware and software that could have caused

the anomaly.• Repeat the testing with the new hardware and software to

achieve confidence that the anomaly does not repeat.• Add environmental stress to the testing conditions, such as

temperature, vacuum, vibration, and so on.• Characterize the anomaly and determine the mission effect

should it recur during any phase of the operation. Meet withthe customer to determine the risk tolerance.

IV&V: THE OUNCE OF DISASTER PROTECTION

Integration, verification, and validation are the “proof of the pud-ding.” If done well, only successful systems would be completed anddeployed since all deficiencies would have been discovered and re-solved. Unfortunately, deficient IV&V has allowed far too many de-fective systems to reach the operations period where they havecaused death, injury, financial loss, and national embarrassment. Wecan all do better.

cott_c20.qxd 6/30/05 3:55 PM Page 380

381

21IMPROVINGPROJECTPERFORMANCE

The preceding chapters focused on ensuring project success byenabling and empowering the project team. This chapter looks

beyond project success toward building a learning organization thatcan sustain project success as the performance bar keeps rising. AsIrving Berlin put it, “The toughest thing about success is that you’vegot to keep on being a success.” Successful organizations cannotstand still.

The next section explores performance improvement by examin-ing the criteria upon which success is usually based. Subsequentsections explore opportunities for propelling performance upward.

PROJECT SUCCESS IS ALL ABOUT TECHNICAL,COST, AND SCHEDULE PERFORMANCE

Technical, schedule, and cost performance are not naturally com-patible. They are opposing forces, in dynamic tension, as the bowedtriangle in the margin illustrates. Achieving balance among thethree requires compromise based on knowledge of the project’s pri-orities and performance health. In system development, the techni-cal content of the project drives the cost and schedule.

The technical performance factors are the verification factorsdefined in Chapter 20, including quality (the degree to which thedelivered solution meets the baselined requirements) and the ap-propriate “ilities.” Regarding schedule and cost performance, it’s

People ask for the secret tosuccess. There is no secret,but there is a process.

Nido Quebin

cott_c21.qxd 7/5/05 3:30 PM Page 381


instructive to examine the bigger picture, our complex system de-velopment legacy, and the reasons for the performance trends.

The U.S. aerospace industry provides us with a rich and variedlegacy of complex system development projects. The first opera-tional U.S. fighter jet, the P-80, was developed from concept to firstf light (in 1945) in 143 days.1 The U-2 went from concept to firstf light (in 1955) in just eight months. The SR-71, which was still oneof the most advanced aircraft in the world in 2000, 43 years after itsfirst f light, was developed from concept to its first f light (in 1962)in 32 months. The SR-71 also pushed the state of the art in manyareas, including the structural use of titanium.

The Corona project, America’s first reconnaissance satellite,took three years and 11 months from project start to the first totallysuccessful f light (in 1960); this span includes 13 launches beforeachieving full success. The Corona program started before any man-made objects had been put into orbit, so everything from concept toreliability was first of a kind. These four projects share a commontrait in that all had a national mandate and resources (which had tobe continuously justified) to get the job done right.

The P-80, U-2, and SR-71 were all developed in the Lockheedskunk works.2 The Corona was developed in a skunk works-like envi-ronment, with Kelly Johnson, founder of the skunk works, as an ad-visor.3 While Lockheed may be the only organization that supportedskunk works operations for an extended time (50 years), David Aron-stein discusses three other independent aerospace skunk works op-erations (two American, one German) that embodied the same rulesand outstanding successes.4 The skunk works concepts were alsocommon and effective in the computer industry. IBM, ControlData, and Intel all maintained significant skunk works operations.

The skunk works environment and principles can improve theperformance of any project, especially complex system develop-ments by addressing:

• Organizational commitment.• Tailored systems engineering and project management processes.• A small, empowered, and cohesive team.

It is critically important for projects to practice the basic principles,especially those that don’t have the highest enterprise support en-joyed by a skunk works. As a small part of a larger organization,skunk works are usually able to handpick the top talent and garnerother precious resources as needed.

The very isolation that benefits a skunk works can be its undo-ing. In the case of one Intel skunk works project, the resulting prod-

cott_c21.qxd 7/5/05 3:30 PM Page 382

IMPROVING PROJECT PERFORMANCE 383

uct concept turned out to be a solution looking for a problem (alsoknown as the “silver platter syndrome”). We know of one Lockheedgroup that undertook a study of the origin of the stone axe in theAmazon Basin.

One of the consequences of the successes of the process modelsof the 1960s is that they led, in the 1970s and 1980s, to more rigid,untailored processes. As noted by Cialdini,5 Ralph Waldo Emersonin his essay “Self-Reliance” said, “A foolish consistency is the hob-goblin of small minds” [italics added]. There are many instances inthe experience of the authors and our colleagues where an unthink-ing adherence to process led to wasted time and money. In the 1970sand 1980s, projects typically stretched out many years and costsgrew significantly (Figure 21.1).

Lest we think that these problems are unique to aerospace orto collocated teams, there are many examples from commercialexperience as well. In one instance, a project team in a major U.S.corporation, working in a dispersed environment (over ten sites),shortened key internal processes from 30 days to 2 days; the overallproject span decreased from a predicted 5 to 6 years to a completionin 18 months. The secret: improved communication and interactionthrough collocation of the key project team members. Breaking the

Figure 21.1 Project spans for major defense acquisition programs.

Average Duration from Project Start to Initial Operational Capability

Durationin Months

Project Timeframe

1950 1960 1970 1980 1990

50

75

100

2000

Based on data from the Acquisition Reform Benchmarking Group 20

cott_c21.qxd 7/5/05 3:30 PM Page 383


mold of inefficient practices is key. The advances in the Internetand the evolving use of distributed, collaborative engineering con-cepts and tools can facilitate similar effective team interaction,even when they are not physically collocated. The ability to have in-formal and frequent technical dialogue is the essence of collocation,which is one of the powerful principles of a skunk works.

In another instance, a major corporation desired to introduce a“hot, new idea” for a food product. At the time the idea was pro-posed, they were well ahead of the competition and could have cap-tured a majority of a very lucrative business. However, it took eightyears for them to get this high-priority product to market, which islonger than it took to build the Golden Gate Bridge in San Franciscoor to build the world’s first satellite. The problem was that they hadno process.

In the early 1990s, the U.S. Department of Defense (DoD)mandated that its standards and specifications be replaced by com-mercial ones—even though commercial counterparts were nonexis-tent in most cases. The objective was to break down barriersbetween the DoD and commercial suppliers. A side benefit is that itforced rethinking of existing paradigms and developing newprocesses from scratch. That is also one of the challenges posed bythe “better, faster, cheaper” legacy. NASA has demonstrated that“better, faster, cheaper” (BFC) can lead to dramatic success as evi-denced by the Mars Pathfinder mission.6 The key is that any processmust be tailored to the project at hand, and that systems engineeringmust thoughtfully orchestrate the tailoring. In earlier chapters, wecited several examples of BFC gone wrong. Many of the NASA proj-ect failures have been traced to concentration on “cheaper” budgetsand shorter schedules to the exclusion of technical performance andreconciling technical, cost, and schedule performance.

An example of the consequences of inappropriate tailoring ofthe project cycle is found in the Lewis spacecraft launched by NASAon August 23, 1997. All contact with the spacecraft was lost threedays later. There were specific engineering and operational causes ofthe failure.7 However, from a process standpoint, one of the primarycauses was the abandonment of informal peer reviews two yearsprior to f light. (Note that this was also a root cause of the Theracfailure cited in Chapter 13.) The contractor reduced the numberand scope of internal reviews to save costs and could do so becausethe customer did not require them. From the perspective of ourmodel, they did inadequate off-core risk management. The lack ofpeer reviews on the Lewis spacecraft allowed the risks to gounchecked all the way into orbit.

cott_c21.qxd 7/5/05 3:30 PM Page 384


Planning for Complexity: Another Ounce of Prevention

At any level of complexity, the management process must be up tothe task and carefully followed. The processes should be as simple asthe situation allows. Management rigor increases with the projectsize, risk, or complexity as illustrated in Figure 21.2. In general,more complex or higher-risk projects require tighter controls, suchas requirements traceability and more rigorous baseline manage-ment. Furthermore, as size and risk increase, so do the needs formore extensive planning and documentation.

Ship of Gold: A Case Study of Systems Engineering and

Project Management Working Seamlessly

Kinder ’s book, Ship of Gold in the Deep Blue Sea (www.shipofgold.com) provides a fascinating case study of a project that succeeded

Figure 21.2 Plan and process rigor increases with project size, risk, or complexity.

User NeedsUse Cases

User NeedsUse Cases

CONOPS &Use CasesCONOPS &Use Cases

SystemRequirements

SystemRequirementsRisk Mgmt

PlanRisk Mgmt

Plan

Items toPurchase1.2.3..

Project SizeSmall

Low

High

Large

Ris

k o

r C

om

ple

xity

Task List1.2.3...

User NeedsUser Needs

ConceptSelectionConceptSelectionConceptSelection

SystemDesignSystemDesign

SystemSpec

SystemSpec

SystemSpec

SolutionConceptSolutionConcept

System/SegSpecs

System/SegSpecs

System/SegSpecs

Risk Mgmt Plan

Risk Mgmt Plan

Risk Mgmt Plan

Interface Spec

Interface Spec

Interface Spec

CONOPSCONOPS

Use Cases

User NeedsUser NeedsUser Needs

ConceptSelectionConceptSelectionConceptSelection

CONOPSCONOPSCONOPS

Risk Mgmt Plan

Risk Mgmt Plan

Risk Mgmt Plan

System/SegSpecs

Including Interface

Specs

System/SegSpecs

Including Interface

Specs

Use Cases

User NeedsUser Needs

Task Management

Agile methods may be effectivePlan

& Process

Rigor

cott_c21.qxd 7/5/05 3:30 PM Page 385


because it applied the principles we have been discussing.8 The proj-ect provides a vivid illustration of the power of business and techni-cal integration and the rewards of viewing risks as opportunities inwork clothes. The book is a thought-provoking story of the recoveryof gold from a ship, the Central America, that sank in the deep ocean(8,000 feet or 2,440 meters). Treasure hunters typically work in anundisciplined fashion with no detailed project plan. In stark contrast,Tommy Thompson, the entrepreneur and project manager, ran themultiyear recovery project in a very businesslike and structured way,as carefully described by Kinder. There were few guidelines fromprior projects as to how to proceed and there were many obstacles to success that demanded the highest technical, cost, and scheduleperformance:

• The challenge of finding the ship, with no precise recorded lo-cation at the time it sank in one of the nineteenth century’sworst hurricanes.

• The challenge of designing recovery equipment when deep-seaexperts insisted, “it cannot be done.”

• Expert opinion in the mid-1980s, when this project took place,was that deep-sea recovery would cost hundreds of millions ofdollars with little chance of success. Thompson’s project costless than $15 million. To achieve this, the project had to be man-aged as a business venture. Investors expected a clear account-ing for their funds and a positive return on their investment.

• The project required secrecy and precise scheduling since otherventures were actively trying to beat Thompson to the gold.

Although Thompson did not use our terminology, he intuitivelyrecognized the need for an incremental development with periodicdecision gates. His intuitive process was tailored to his specific ob-jectives and he practiced the principles of our model: an integratedproject management and systems engineering process applied effec-tively without drowning in administrative details.

Toward More Accurate Planning

Plans are only as good as the information and assumptions on whichthey are based and, therefore, must be updated as the informationchanges and becomes more accurate and as the planning horizon becomes better understood. Cost estimates are critical planning in-puts, yet are notoriously inaccurate at the project inception, espe-cially for the software tasks. Appendix D provides a softwaredevelopment cost estimating process that has proven effective in

cott_c21.qxd 7/5/05 3:30 PM Page 386


Project success depends onthe team members’ attitude asmuch as on the leader.

addressing this problem. The process is now being successfully ap-plied to complex system developments. But as the next section em-phasizes, it is important to recognize differences betweenestimates and budgets and to resolve those differences to improveboth schedule and cost performance.

SUSTAINING PERFORMANCE IMPROVEMENT

Measuring performance determines where improvements are needed.Improving performance requires organizational commitment.

Institutionalizing Best Practices

Professional organizations have taken a more scientific approach tounderstanding project success and failure. They evaluate work prac-tices and use them to develop and apply capability maturity and pro-cess improvement models. The SEI Capability Maturity ModelIntegrated, which incorporates systems engineering to assess thework practice maturity of software and systems development teams,is discussed in more detail in the following section. The model isbased on the theory that more effective people, processes, tools, andmeasurement lead to higher performance and probability for projectsuccess. The PMI Organizational Project Management MaturityModel (OPM3) is a standard for organizational assessment and pro-cess improvement that has three interlocking elements: Knowledge,Assessment, and Improvement. INCOSE is crafting a maturitymodel for systems engineering for use in assessing organizational ca-pability in the systems engineering domain. While these capabilitymodels assess and measure the presence of practices within an orga-nization, they may overlook the team members’ underlying resis-tance to the best practices.

Exposing the Hidden Enemies

A negative attitude and lack of confidence in process managementoften turns out to be a self-fulfilling prophecy:

At a software engineering course for aspiring managers, the partici-pants were asked: “If your team of programmers developed airplaneonboard f light control software, and one day when you were f lying,you found out before takeoff that this plane was one of thoseequipped with your software, how many of you would get out?”

cott_c21.qxd 7/5/05 3:30 PM Page 387


All except one person raised their hands. The course instructorasked the only one left whose hand was not raised, “What would youdo?” She said, “Stay in my seat—if my team wrote the software forthis plane, it wouldn’t move, let alone take off.”

While this true story is told with tongue in cheek, it comes closeto characterizing the attitudes of many frustrated team members inthis era of “vaporware” and getting to market at any cost. In an at-tempt to understand why some teams succeed and others do not, ex-perts have studied the magic of the natural-born leaders. Thesestudies produced project manager attribute models similar to thosewe referenced in Chapter 18. Although relevant and important, thisleadership approach alone, based on the characteristics of the lead-ers in the studies, does not yield teams that are consistently success-ful. This approach fails to consider the importance of the process,tools, and the team members’ attitudes toward essential projectmanagement techniques.

Teams within organizations known for their expertise in projectmanagement would sometimes violate basic best practices resultingin failures of the worst kind as described in previous chapters.When we became aware that most of these project failures were notcaused by the problems of advanced technology, but rather by thefailure to implement fundamental and basic project managementtechniques, we looked for root causes, or the “ultimate why.”

In each of these cases, a fundamental project management prac-tice was overlooked, ignored, or circumvented. In every case, theproperly applied project management technique would have pre-vented the project failure.

We set out to discover what caused project teams to ignoreproven practices. Fortunately, our business causes us to routinely in-terface with substantial numbers of skilled project personnel includ-ing government agencies and contractors, commercial hardware andsoftware companies, and graduate students, at several universities,pursuing project management careers.

We typically survey participants entering our training programs.The survey collects the participant’s candid attitudes about “howthey value” a selected group of important project management tech-niques prior to receiving training. The summary of responses (Fig-ure 21.3) from approximately 20,000 participants represent thepercentage of “positive” responses for some of the most importanttechniques. Our premise with this questionnaire is that personnelwho are negative, neutral, or have no opinion toward a techniquecannot be expected to pursue and support the technique in the proj-

Sustained performanceimprovement depends onwinning over the hidden ene-mies of project management.

No competent projectmanager would think of man-aging a project without theseimportant techniques,effectively practiced.

cott_c21.qxd 7/5/05 3:30 PM Page 388


ect environment. The “somewhat positive” person may support thetechnique if implemented by others, but will usually not be the ini-tiator or orchestrator. The only person who is a possible candidatefor championing the technique and cultivating its effectiveness inthe project environment is the person who checks “positive.” Andeven if positive, the person might not have the leadership skills re-quired to instill a technique in a resistant climate.

The survey results are sobering on two accounts—the widerange of group results and the low averages. The negative biases car-ried into the room when the survey was taken are alarming, espe-cially considering that clients send only their best project personnelto a week or two of advanced project management training. The 45percent averages for project business management, change control,and requirements traceability means that less than half of the20,000 participants felt decidedly positive toward these techniques.Inadequate attention to one or more of these specific techniques

Figure 21.3 Management methods survey form and summary of results.

cott_c21.qxd 7/5/05 3:30 PM Page 389


caused the failure of the Intelsat commercial satellite, the Chal-lenger disaster, and the Denver airport delay and cost overrun.

Further analysis reveals that the main factors contributing tothe nearly 85 percent dynamic range for most factors is the corre-sponding knowledge of—and experience with—the technique andthe management level of the respondent. The perceived value ofproject management techniques diminishes at lower levels of the or-ganization hierarchy (Figure 21.4).

Fortunately, this trend can be reversed with proper training andpositive experience with the techniques. In early applications of thesurvey, we administered it both before and after training withoutdiscussing the reasons for the survey. The results showed a positiveattitude increase to 70 percent or higher for most techniques as a re-sult of understanding the use and the application of the technique.This attitude improvement demonstrates the power of training andof being informed. It is important for project leaders to measure theattitudes of their team at project start-up by applying this survey.Armed with this knowledge, selectively seek to improve the under-standing of the techniques that received low scores.

PROCESS IMPROVEMENT DONE RIGHT

What makes one organization successful in its process improvementefforts while others f lounder for years expending millions of dollarswithout getting any benefits? It is very tempting to say management

Figure 21.4 How three management levels value important techniques.

0

10

20

30

40

50

60

70

80

90

10

Pro

ject

Man

agem

ent

Executive Management

Middle Management

Lower Management

% Positive

Pro

ject

Bus

ines

sM

anag

emen

t

Sys

tem

Eng

inee

ring

Pro

ject

Pla

nnin

g

Cha

nge

Con

trol

Red

Team

s

Des

ign

Rev

iew

s

Req

uire

men

tsTr

acea

bilit

y

cott_c21.qxd 7/5/05 3:30 PM Page 390


commitment, but that doesn’t tell the whole story. That commitmenthas to be made for the right reasons. This means tying the process im-provement program to real business goals that are focused on bottom-line performance. Whether the desired performance is profit, cycletime, or quality improvements, the organization that understands itsproblems and starts its process improvement focused on fixing thoseproblems is the one that will generally succeed.

Among the several established process improvement frame-works, three have demonstrated significant value in the project envi-ronment and beyond: ISO 9000, Six Sigma, and the SEI-CMMI.Each of these frameworks provides a platform for continuous processimprovement, and each has different strengths, purposes, and goals.

ISO 9000 is a series of international standards that identifythe minimum activities that an organization must have in place inorder to control quality. An ISO 9000 Quality Management Systemis a framework that includes systematic methods, documentedprocesses, and defined responsibilities. The ISO 9000 approach en-compasses:

• A quality system that describes how the company fulfills the re-quirements for each element of a given standard.

• Practices consistent with documented quality policies andprocedures.

• Maintenance of quality records.• Performance of regular quality audits.

ISO 9000 is very broad and addresses all aspects of the enterprise,from administration to manufacturing.

Six Sigma improves performance by focusing on those processaspects that are critical to quality from the customer perspective. Amajor Six Sigma goal is to eliminate process variation. Six Sigma usesa project methodology known as DMAIC (Define, Measure, Ana-lyze, Improve, and Control) to allow project efforts to bring measur-able and repeatable results. Six Sigma views businesses as beingcomposed of processes that start with customer needs and end withdelighted customers using the organization’s product or service.

The SEI-CMMI framework has been discussed earlier. Itevolved from the need to assess an organization’s software develop-ment capability and process maturity into a comprehensive frame-work for establishing and improving processes critical to complexsystem development. Because of its specific alignment with systemdevelopment projects, this chapter focuses on the SEI-CMMI pro-cess improvement framework.

cott_c21.qxd 7/5/05 3:30 PM Page 391


Effective Process Improvement Needs the Right Motivation

Consider a company that is having profitability problems and has de-termined that one problem is realistic cost estimates. It decides tostart a process improvement program to get better at cost estimatingand, hopefully, be more profitable. They decide to use the continu-ous representation of the CMMI and pick the project planning (PP)process area to guide its efforts. Using the best practices in the PPprocess area, the company discovers that its real problem isn’t esti-mating—it’s not recognizing the difference between estimates andbudgets and the importance of reconciling the differences. It makessome minor, but critical, changes to its planning process and startsseeing its bottom line improve. This encourages it to look at otherprocess areas that seem to address other problems. Eventually, itimplements all of the Maturity Level 2 process areas, which are tiedto the basic management practices we have been discussing in thisbook. The company undergoes a CMMI appraisal and becomesrated at Maturity Level 2.

Contrast the previous experience with Company XYZ, a govern-ment contractor. It would like to expand its business with some newgovernment contract opportunities that require it to be rated atCMMI Maturity Level 2 in order to compete. It immediately adoptsa sweeping process improvement program to become level 2 ratedwithin three months. Company XYZ doesn’t understand the issuesinvolved with culture change and the time it takes to progressthrough the forming/storming/norming/performing stages of build-ing effective teams. The SEI statistics show that it takes from 6 to 18months to move up one level with the median being 12 months. Athree-month program is doomed to fail. This is not to imply thatbeing rated at any given maturity level is an invalid reason for initi-ating a process improvement program. However, for Company XYZto reap the performance improvement benefits of a process im-provement program requires a broader commitment: a goal to man-age processes better to ensure profitable delivery within theschedule, which necessitates getting to Maturity Level 2 as a meansrather than as the end.

It’s All about Performance Improvement

The principles and recommendations covered in this book are dis-tillations of the cumulative experiences of successful project prac-tioners. Many organizations have attempted to discover how thesesuccessful managers and engineers were able to succeed in the face

cott_c21.qxd 7/5/05 3:30 PM Page 392


of gloomy industry trends described in books such as EdwardYourdon’s Death March.9 The premise in many of these books ishow difficult it is to design and build modern, technologicallycomplex systems. Yet, few of these projects and teams used a disci-plined approach that combined all the best practices covered inthis book.

The situation was so endemic to the industry 25 years ago thatthe DoD chartered the SEI to improve the capabilities and develop-ment maturity of U.S. defense contractors. The SEI performed asurvey of successful contractors and discovered that they had anumber of common characteristics referred to as best practices. Notsurprisingly, it was rare that a single organization implemented allthe best practices, yet there was a direct correlation between suc-cess and the number of best practices in use. The DOD needed amethod to assess the extent to which this collection of best practiceswas implemented in order to determine the relative risk of awardinga contract. The resulting SEI-CMMI and its evolution are describedin Appendix B.

Readers familiar with the CMMI model reading this book forthe first time will be struck by how closely all of the discussed con-cepts are ref lected in the CMMI. Conversely, readers of the CMMIfor the first time who are familiar with this book will see how im-plementing the concepts in this book will make implementing theCMMI easier.

Overcoming the “Band-Aid” Approach to

Performance Improvement

Most organizations implementing the CMMI start with a gap as-sessment consisting of an internal assessment to identify theirstrengths and weaknesses relative to the model. The gap assess-ment usually results in a list of items that are either not imple-mented or are only partially implemented, along with arecommendation for correction. The usual management approachis to prioritize this list and start creating new processes to fill inthe gaps. This naturally results in a “band-aid” approach to imple-menting the CMMI. Each gap or weakness gets a band-aid to fixthe immediate problem, and there’s a mix of existing processes andsmall fixes with little thought to integrating all the processes to-gether for efficiency. After the organization has achieved its initialgoals and has started working toward higher levels of maturity, itusually finds it can combine the “band-aid” fixes into fewer, moreefficient processes. It is not uncommon to see shrinkage of greater

It is not uncommon to seeshrinkage of greater than 50percent in the total page countof a Maturity Level 3 organiza-tion from their Maturity Level2 processes.

cott_c21.qxd 7/5/05 3:30 PM Page 393


than 50 percent in the total page count of a Maturity Level 3 orga-nization from its Maturity Level 2 processes.

As an example of this phenomenon, consider Generic Practice2.6 (GP 2.6) from the CMMI. This GP is found in each of the 25process areas contained in the model and it states:

GP 2.6 Manage Configurations

Place designated work products of the project planning process underappropriate levels of configuration management.

The primary intent of this practice is to ensure that project teamsidentify all the artifacts they will create (work products) and de-scribe how they will be controlled. The range of control can includethe lowest level of no control, the intermediate levels of saving theartifacts in a file structure or repository or putting version numberson them, all the way to formal configuration management withchange control boards. A typical and concise way to show compli-ance with GP 2.6 is a table that identifies the specific work productsand the level of control to be used for each. Such a table might looklike this for the project planning process area:

Work Product Level of Control

Meeting announcements No controlMeeting minutes/agendas File—date stamp and save in a repositoryProject estimates and Plan Version—unique identificationWork breakdown structure Configuration Management—baseline

control with board approval

This type of table or similar information is usually found in the Proj-ect Plan. A similar table might be found in a Configuration Manage-ment Plan with different work products. Other tables might be foundin other types of plans or documents as the priorities of closing thegaps dictate. In the worst case, a project team could accumulate 25versions of this basic table, one for each process area in the model.

However, most organizations soon realize that this is relativelystatic information across project teams and they can combine all thetables into one super table in a template given to their project teams.Table 21.1 is an example of one such template.

As the table is put into practice on various project teams, theywill notice project-specific items that need to be added. Ongoingfeedback should ensure that, over time, the basic template will ex-pand to the point that every possible work product is included. Atthat point, project managers can select the ones that are applicable

cott_c21.qxd 7/5/05 3:30 PM Page 394

395

Table 21.1 Configuration Management Process Improvement Template

Work Product Type of CM Location Comments

Miscellaneous artifactsStaff meeting agenda FileStaff meeting minutes FileE-mails discussing issues/action items, etc. FileLine management organization charts VersionOrganizational ID of roles and responsibilities Version

Project Status Meetings Also called MMRs, QMR, PSRs…Regular review presentation packages FileMinutes of reviews FileAgendas for regular reviews File

PlansProject plan VersionProject schedules CM Control May be included in project planProject estimates VersionProject budgets CM Control May be in Work AuthorizationsOrganization charts VersionConfiguration management plans VersionQuality assurance plans VersionVerification/validation plans VersionTraining plans VersionWork authorizations CM Control

Requirements artifactsUser statement of need FileUser requirements VersionUser operational concept CM ControlSystem requirements specification CM ControlComponent-level requirements specification CM ControlLower-level requirements specifications CM ControlRequirements traceability matrix VersionTechnical analyses VersionChange requests FileCR log FileCCB minutes File

Review artifactsPresentation packages FileRIDs and logs FileRFAs and logs FileAttendance sheets FileMinutes File

Design artifactsArchitecture drawings/specifications CM ControlComponent-level design documents CM ControlWiring diagrams CM ControlTechnical data packages VersionAlgorithm descriptions VersionMake/buy decision analyses VersionProduct integration plans/procedures Version

Product artifactsSoftware code modules CM ControlSoftware make/build instructions Version These may be under CM controlVerification/validation plans/procedures CM ControlVerification/validation reports FileTest databases Version

cott_c21.qxd 7/5/05 3:30 PM Page 395


to their project and delete the others. A task that might have takenseveral hours is now reduced to a few minutes. The reader is chal-lenged to find the obvious missing work products from the sampletable provided.

To illustrate this shrinkage effect even further, there is a prac-tice in the project planning process area that covers planning fordata management. This practice states:

PP SP 2.3 Plan for Data Management

Plan for the management of project data.

Similarly, there is a practice in the Project Monitoring and Con-trol process area that tracks progress against the Data ManagementPlan. It states:

PMC SP 1.4 Monitor Data Management

Monitor the management of project data against the project plan.

It is a simple matter to add a few columns to the work producttable to show when the work products will be created, where they’llbe stored, who will get copies, and any other information the projectdeems necessary to satisfy both these practices. In essence, this onetable can fulfill the requirements for 27 practices (GP 2.6 in 25 pro-cess areas plus the PP and PMC SPs shown previously).

Mapping the CMMI to the Five Essentials

The CMMI process areas are typically seen as being independent byorganizations starting out in process improvement and this can leadto a band-aid approach in their implementation. However, the wheeland axle model can be used to illustrate how these process areas areinterrelated. Further to the previous discussion about mature orga-nizations growing out of the band-aid stage, the wheel and axlemodel can be used to illustrate a composite view of all the processareas in the staged Maturity Level 2 representation of the CMMI.This mapping is discussed further in Appendix B.

Sustaining Performance Improvements with a Process

Improvemet Program

The concept of shrinkage that we’ve been describing also occurs inthe Maturity Level 3 process areas. Most germane to this discussionare how well the six engineering process areas are included withinthe Vee model. The engineering process areas include:

cott_c21.qxd 7/5/05 3:30 PM Page 396


• Requirements Development (RD).• Requirements Management (REQM from the level 2 Maturity

Level).• Technical Solutions (TS).• Product Integration (PI).• Verification (VER).• Validation (VAL).

While the process areas themselves are not a process and don’tnecessarily imply a time sequence, they map perfectly to the Vee(Figure 21.5).

The message of starting at the upper left leg of the Vee by elic-iting requirements and then planning the project incorporates theRD process area, as well as the first specific goals from PI, VER,and VAL. The first Specific Goal from these three process areas ad-dresses early planning for how the resulting products or systems willbe integrated, verified, and validated at the opposite side of the Vee.

Continuing down the left leg of the Vee through stepwise re-finement of requirements into concept and architecture down tobuild-to design and implementation shows how the practices withinRD and TS are intended to f low together and result in product im-plementations of the requirements. The off-core activities describ-ing how the Vee accommodates investigations at any time shows how

Figure 21.5 Six engineering process areas and Vee model.

cott_c21.qxd 7/5/05 3:30 PM Page 397


a REQM process is to be incorporated into the overall product cycleat any point.

Continuing up the right leg of the Vee illustrates the process ofintegrating subentities into higher-level entities and eventually intothe complete system as required by the PI process area. The Veedemonstrates how verification and validation are accomplished ateach level of integration.

Thus, in a single model, the Vee illustrates how the engineeringprocess areas are interrelated and can be combined into one com-prehensive process that incorporates 40 specific practices from thesix process areas (not counting the generic practices).

The importance of understanding the entire picture and beingable to relate the component processes to each other should not beunderestimated. It’s typical for organizations to have a large numberof process descriptions when starting out as they apply the band-aids to their gaps, only to see the number shrink back as process im-provement takes hold and the individual process descriptions arecombined with artifacts supporting multiple practices as describedearlier with the work products table.

Use of our five-essentials model and the Vee can help organiza-tions starting out in process improvement to avoid some of the earlyinefficiencies in establishing processes. With the big picture inmind, it will be easier to avoid the temptation to apply band-aid fixesto CMMI process gaps. The models also allow the organization totailor the big picture approach to their business goals and objectsearly and further reduce the effort to implement CMMI.

PUTTING IT ALL TOGETHERTO MASTER COMPLEX SYSTEMS

Chapter 2 employed systems thinking to view the bigger picture ofthe project environment. That chapter concluded by looking at thewaves of the future—the convergence of project management, sys-tems engineering, and process improvement. In Parts II and III, wepresented management process models, principles, and techniquesas an integrated set, without regard to their specific domain. In PartIV we have covered advanced principles of systems engineering andidentified the synergies between process improvement and thewheel and axle process model. It is in the convergence of these threedomains at the enterprise level that the real potential for perfor-mance improvement lies.

Being able to internalize theoverall project managementprocess removes the need tofollow the individual steps onfaith or by edict.

cott_c21.qxd 7/5/05 3:30 PM Page 398


Complexity Made Simple

Overwhelming complexity is often cited as the reason project man-agement processes defy our intuition. But complexity alone does notpreclude intuition. Intuition develops from observing and under-standing key principles. For example, the behavior of a gyroscope isnot intuitive to most of us. But to an inertial guidance specialist, gy-roscopes are second nature.

Intuition is developed by observing the environment, under-standing the driving characteristics, and learning reasonable rangesfor them. As an example, consider the plight of the main characterin an old movie. As part of the plot he was to pretend that his sisterhad just given birth. A woman asked him how much the newbornweighed. Caught by surprise, he suggested the baby weighed 20pounds. The woman reacted in horror, “Oh, no!” Our hero quicklycorrected his mistake, “Oh, of course I meant 20 ounces.” Thewoman reacted in horror, “Oh, no!” If you don’t have sufficient intu-ition to get within an order of magnitude, you are in the wrong posi-tion. Take heart—intuition can be developed if you work at it andconcentrate on the essentials.

Managing a project without some intuition is like looking at aroad map through a drinking straw. Generating that intuition is per-haps the most important contribution of our Vee models and thewheel and axle. The obvious correctness of the models instills con-fidence in the process. A team that understands the value of a cred-ible process, and follows it because the members believe in it, willbe far less likely to omit an important step or to perform a practiceincorrectly.

BEYOND SUCCESS: SUSTAINING A HIGH PERFORMANCE CULTURE

The investments and efforts made to revitalize the project environ-ment, or to create one, can pay high dividends to the entire organiza-tion. One project team can be the catalyst for culture changes thatcan represent the enterprise’s most significant competitive advantagein this technology-driven, time-compressed era. Whereas technologyis surprisingly easy to clone, a well-integrated, high-performanceproject culture is an invaluable proprietary asset for sustaining highperformance well into the future.

Project management is thebest training ground forgeneral management.

cott_c21.qxd 7/5/05 3:30 PM Page 399

cott_c21.qxd 7/5/05 3:30 PM Page 400

401

Appendix A

Web Site for Formsand Templates

Most of the forms and templates that appear in this book, plusothers, together with related white papers, references, and

links to other online resources are available on our web site. Go towww.csm.com/vpm3e and log on using the three-letter passwordVee (case sensitive).

cott_z01bappa.qxd 7/1/05 3:49 PM Page 401

402

Document and Project Deliverable Templates

Competency and Attitude

Assessments

SW Planning and

Estimating

Spreadsheets

cott_z01bappa.qxd 7/1/05 3:49 PM Page 402

403

Appendix B

THE PROFESSIONALAND STANDARDSENVIRONMENT

This appendix brief ly characterizes the professional societies,regulatory bodies, and standards organizations that inf luence

project practitioners, the project vocabulary, and the solution space.For further details, refer to Part 3 of Communicating Project Man-agement and to www.csm.com/vpm3e, which also provides links tofurther references and to each organization’s web sites.

THE PROFESSIONAL ENVIRONMENT

The table on page 404 summarizes three organizations that, throughcontinued growth in scope, inf luence, and collaboration, are ex-pected to shape the future of the project management and systemsengineering professional environment:

INCOSE—International Council on Systems Engineering.PMI—Project Management Institute.SEI—Software Engineering Institute.

INCOSE expanded to international scope in 1995 and launchedits certification program in August 2004. INCOSE works with, andthrough, international standards organizations rather than publish-ing its own standards. INCOSE has collaborated with the Electron-ics Industries Alliance (EIA) on several broad standards, including

cott_z02bappb.qxd 7/1/05 3:46 PM Page 403

404 APPENDIX B

EIA /IS-731 Systems Engineering Capability Model, a source stan-dard for the SEI CMMI Product Suite.

Holding a PMI PMP certification is the de facto basis for judg-ing an individual’s knowledge about project management, espe-cially in the United States. PMI publishes A Guide to the ProjectManagement Body of Knowledge (PMBOK® Guide), to identify anddescribe that subset of the body of knowledge in project manage-ment that is “generally recognized as good practices on most proj-ects most of the time.”

INCOSE PMI® SEI

Scope andimpact

Over 5,000 membersfrom over 30 countries.Collaborative agreementsinclude AmericanInstitute of Aeronauticsand Astronautics, EIA,IEE, ISO, and SEI.

Over 100,000 membersfrom 125 countries.Cooperative agreementsinclude the ConstructionManagement Associationof America and IIE.

SEI-authorizedappraisers haveevaluated thousands oforganizations (2/3commercial) and tens ofthousands of projectswith productivity gainsof 20% to 28% whenadvancing from Level 1to Level 3.

Professionalcredentials andcertification

Certified SystemsEngineering Professional(CSEP) introduced inAugust 2004.

Project ManagementProfessional (PMP®)certification, maintainedby earning PDUs.

SEI authorizes LeadAppraisers to rateorganizations as tomaturity and capabilityusing a five-level model.

Competencymodel orframework

Collaborated on EIA/IS731 Systems EngineeringCapability Model(SECAM)

OPM3 expressesenterprise maturity interms of Project,Program, and Portfolio.

Capability MaturityModel Integration(CMMI®) Product Suiteaddresses hw/sw andsystems engineeringdisciplines

Best practices Systems EngineeringHandbookSysML in development

A Guide to the ProjectManagement Body ofKnowledge (PMBOK®

Guide)

Standard CMMIAppraisal Method forProcess Improvement(SCAMPISM)

Practice standards, suchas those for workbreakdown structures

EIA-632, Processes forEngineering a System

Representativestandards


APPENDIX B 405

The SEI is a research and development center sponsored bythe U.S. Department of Defense and operated under contract toCarnegie Mellon University. The SEI mission is to advance thepractice of software engineering and to make predictable the ac-quiring, developing, and sustaining of software-intensive systems,from design through operation.

The integrated systems engineering/hardware/software CMMI®

Product Suite was introduced in August 2000 to replace the SoftwareCapability Maturity Model (SW-CMM) in use since 1987. The SEIauthorizes CMMI Lead Appraisers through a formal program oftraining, mentoring, observation, and performance criteria.

One view of the genealogy of the SEI CMMI Product Suitefollows:

It illustrates one of the major collaborative and integrative ef-forts among the professional and standards organizations involved inproject management and systems engineering.

A large number of professional organizations and societiesshare their lessons learned, develop their own best practices, andoffer various forms of support and mentoring to their members.They range in size from the Agile Alliance to the 28 separate pro-fessional societies that make up the half-million-member Instituteof Electrical and Electronics Engineers (IEEE). Several others areidentified in Chapter 2.

IPD-CMM

Mil Std499, A, B

EIA / ANSI632

IEEE / EIA12207

SE-CMM

EIA / IS632

INCOSESECAM EIA 731

SECM

IEEE1220

ISO15288

ISO / IEC12207

ISO15504DoD

2167A

Mil Std498DoD

7935A

SW-CMM

EIA632

CMMI

CMMI Environment


406 APPENDIX B

REGULATORY BODIES ANDSTANDARDS ORGANIZATIONS

The regulatory and standards bodies identified next are three of themost inf luential in the project solution space:

Electronics Industries Alliance (EIA).International Organization for Standardization (ISO).U.S. Department of Defense (DoD).

The EIA is the primary industry association representing the U.S.electronics community and its six trade associations. The EIAhas an affiliate relationship with the Internet Security Alliance, acollaborative effort with the SEI’s CERT Coordination Center(CERT/CC). Two standards have a broad and continuing inf luenceon the solution space. EIA 632 standard and the International Or-ganization for Standardization (ISO) 15288 standard, while compli-mentary with different roles and details, have greatest impact whencombined.

The ISO is a worldwide, nongovernmental federation ofnational standards bodies established in 1947. ISO 9000 is the in-ternationally recognized standard and reference for quality man-agement in business-to-business dealings. The ISO standards thatmost directly affect the project solution space include:

• ISO 15288 System Engineering—System Life Cycle processes.• ISO12207SoftwareEngineering—SoftwareLifeCycleprocesses.• ISO/IEC TR 15504—Software process assessment (published

in 1998): A series of nine standards covering the capabilitymodel, performing assessments, assessor competency, and pro-cess improvement.

Historically, the U.S. Department of Defense (DoD) has beendirectly involved in the solution space with standards such as MilStd 498/499 and DoD 2167A /7935A. In more recent years, DoD in-f luence has shifted to acquisition policy, such as requiring contrac-tors to be rated at a specified CMMI level and /or conformance withDoD 5000 management principles and requirements generation.

The DoD acquisition processes and procedures are directed andguided by three key documents:

1. DoD Directive (DoDD) 5000.1,2. DoD Instruction (DoDI) 5000.2, and3. Defense Acquisition Guidebook (DAG).


APPENDIX B 407

The Defense Acquisition System Directive (DoDD 5000.1)identifies management principles for all DoD programs. The De-fense Acquisition System Instruction (DoDI 5000.2) establishes amanagement framework for translating needs and technology oppor-tunities into acquisition programs/systems. The Defense AcquisitionGuidebook (DAG) is non-mandatory and provides guidance on pro-cedures for operation of the acquisition system and is based on anintegrated management framework formed by three primary deci-sion support systems: the Requirements Generation System, the De-fense Acquisition System, and the Planning, Programming, andBudget System (PPBS).

DoDI 5000.2 states that “Evolutionary acquisition is the pre-ferred DoD strategy for rapid acquisition of mature technology forthe user. An evolutionary approach delivers capability in incre-ments, recognizing, up front, the need for future capability im-provements. The objective is to balance needs and availablecapability with resources, and to put capability into the hands of theuser quickly. The success of the strategy depends on consistent andcontinuous definition of requirements, and the maturation of tech-nologies that lead to disciplined development and production of sys-tems that provide increasing capability towards a materiel concept.”

In the DoD vernacular, “evolutionary” is an acquisition strategythat defines, develops, produces or acquires, and fields an initialhardware or software increment (called a phase or block) of opera-tional capability. Evolutionary acquisition is based on technologiesdemonstrated in relevant environments, time-phased requirements,and demonstrated capabilities for deploying manufacturing or soft-ware. Evolutionary acquisition provides capabilities to the users inincrements. The capability is improved over time as technology ma-tures and the users gain experience with the systems. The first in-crement can be provided in less time than the “final” capability.Each increment will meet a useful capability specified by the user;however, the first increment may represent only 60 percent to 80percent (or less) of the desired final capability. Each increment isverified and validated to ensure that the user receives the neededcapability.

The two basic evolutionary approaches are referred to asSpiral Development and Incremental Development, an unfortunateand confusing choice of terms since the well-known Spiral Model isapplicable to both. In the DoD Spiral Development, the “end-state requirements are not known at program initiation.” The finalfunctionality cannot be defined at the beginning of the program,and each increment of capability is defined by the maturation of


408 APPENDIX B

the technologies matched with the evolving needs of the user. Inthe case of Incremental Development, the final functionality canbe defined at the beginning of the program, with the content ofeach increment determined by the maturation of key technologies.

The DoD Spiral Development closely corresponds to our Incre-mental /Evolutionary Method (with multiple deliveries) defined inChapter 19, which may be modeled using the Spiral, but dependingon other characteristics of the project, may best be modeled withthe Waterfall or Vee.

The DoD Incremental Development closely corresponds to ourIncremental /Linear Method, which again, can be represented byany or all of the defined models.


409

Appendix C

The Role ofUnified ModelingLanguage™in SystemsEngineering

James Chism, Chairman,INCOSE Object Oriented Systems Engineering

Methodology (OOSEM) Working Group

Large complex systems must be structured in a way that enablesscalability, security, and robust execution under stressful condi-

tions, and their architecture must be defined and communicatedclearly enough so that they can be built and maintained. A well-designed architecture benefits any program, not just the largestones. Large applications are mentioned first because structure is away of dealing with complexity, so the benefits of structure (and ofmodeling and design) compound as application size grows large. TheOMG’s Unified Modeling Language™ (UML®) helps you specify,visualize, and document models of software systems, including theirstructure and design, in a way that meets all of these requirements.1

That’s great for software engineers, but does it help with systemsengineering?

To develop any complex system requires a team of engineersworking at the system level to analyze the needs of the stakeholders,

cott_z03bappc.qxd 7/1/05 3:46 PM Page 409

410 APPENDIX C

define all the requirements, devise the best concept from several al-ternatives and architect the system to the component level. The sys-tem team must also provide to the designers all of the models andvisualizations that describe the architecture down to the lowest de-composed level. David Oliver in his book Engineering Complex Sys-tems with Models and Objects2 states: “These descriptions must beprovided in the representations, terminology, and notations used bythe different design disciplines. They must be unambiguous, com-plete and mutually consistent such that the components will inte-grate to provide the desired emergent behavior of the system.” Sohow does one use UML that was originally designed primarily forsoftware personnel to help the systems engineer?

UML is a graphical language for modeling software systems and itwas adopted as V1.1 by the Object Management Group (OMG) in1997. Since then UML has become a de facto standard of the soft-ware community and the language has continued to improve throughV2.0 as of 2004. It is a robust language with built-in extension mecha-nisms capable of addressing many needs. UML is supported by theOMG that has a well-defined technology adoption process and broaduser representation that should assist in future development of thelanguage. So how does this help the systems engineer and what iswrong with the current structured approach to systems engineering?

First, there are many systems being developed that use the Ob-ject Oriented (OO) approach for software development. As such,the current structured approach to systems sngineering poses adefinite communication blockage between the SE and the softwaredevelopers due to the visualizations used by the traditional ap-proach. Basically, there is the lack of a common notation, seman-tics, and terminology as well as a definite tool incompatibility. Thisgap needs to be bridged to take full advantage of the OO approachand make full use of UML. So in addition to the structure language(UML), you need a systems engineering method consistent withthat language and additional systems engineering notation to beeffective.

In November 2000, the INCOSE Object Oriented Systems En-gineering Methodology (OOSEM) Working Group was establishedto help further evolve the methodology. The working group is spon-sored by the INCOSE Chesapeake Chapter and led by Jim Chism.

The OOSEM working group goals are to:

• Evolve the object-oriented systems engineering methodology.• Establish requirements and proposed solutions for extending

UML to support systems engineering modeling.


APPENDIX C 411

• Develop education materials to train systems engineers in theOO systems engineering method.

OOSEM includes the following development activities:

• Analyze needs.• Define system requirements.• Define logical architecture.• Synthesize candidate allocated architectures.• Optimize and evaluate alternatives.• Validate and verify the system.

These activities are consistent with the typical systems engi-neering Vee Model and process that can be recursively and itera-tively applied at each level of the system hierarchy. Fundamentaltenets of systems engineering, such as disciplined managementprocesses (i.e., risk, configuration management, planning, and mea-surement) and the use of multidisciplinary teams, must be applied tosupport each of these activities to be effective.

OOSEM utilizes a model-based approach to represent the variousartifacts generated by these activities as opposed to a document-driven approach with traditional systems engineering. As such, it en-ables the systems engineer to apply a very disciplined approach to thespecification, design, and verification of the system, and ensures con-sistency between the requirements, design, and verification artifactsthat are understood by the OO software developer. The added rigorof the model-based approach helps to analyze the system and surfacetechnical issues early and communicate the issues in a precise man-ner. The modeling artifacts can also be refined and reused in otherapplications to support product line and evolutionary developmentapproaches. However, the OOSEM Working Group as well as othersdetermined that even UML 2.0 did not contain sufficient robustnessto encompass the needs of systems engineering to support analysis,requirements, specification, design, and verification of complex sys-tems. As a result, in addition to the features of OOSEM, SandyFriedenthal and others are working with the OMG and INCOSE todevelop a Systems Engineering Modeling Language (SysML) to en-hance the use of UML by Systems Engineers.

So what is SysML? “SysML will customize UML 2 to support thespecification, analysis, design, verification, and validation of complexsystems that may include hardware, software, data, personnel, proce-dures, and facilities” according to the SysML partners (OMG doc#ad /03-11-02). That effort began on September 13, 2001, with ameeting of an OMG chartered group called the Systems Engineering


412 APPENDIX C

Domain Special Interest Group (SE DSIG). The goals of that groupwere to:

• Provide a standard SE modeling language to specify, design, andverify complex systems,

• Facilitate integration of systems, software, and other engineer-ing disciplines, and

• Promote rigor in the transfer of information between disciplinesand tools.3

In addition to the following UML 2.0 diagrams: activity dia-gram, assembly diagram, class diagram, behavior diagram, structurediagram, object diagram, package diagram, sequence diagram, statemachine diagram, timing diagram, use case diagram; the SysMLpartners are recommending the addition of the following diagramtypes: parametric diagram and requirements diagram. The activitydiagram and the assembly diagram will require extension to enhancetheir use for systems engineering. The design approach for SysML isto reuse a subset of UML and create extensions as necessary to sup-port the specific requirements of the UML based on the SE RFP.

“The parametric diagram provides a mechanism for integratingengineering analysis, such as performance and reliability analysis,with other SysML models. It also provides an effective mechanismto identify critical performance parameters and their relationshipsto other parameters, which can be tracked throughout the systemlife cycle.”4

In addition to these SysML attributes that will be added, newfeatures of UML 2.0 will include parts, ports, and components thatwill allow an added capability to recursively decompose systemsinto their constituent components as well as to decompose behaviorsin the activity and sequence diagrams. It is expected that SysMLwill be formally adopted by OMG in 2005.

How does OOSEM enhance the UML role for Systems Engi-neering? As an example, we have chosen the topic “Analyze Needs,”since this initiates the systems engineering effort on a project. Wethen provide a comparison table of the traditional representations tothe OOSEM visualizations used (UML diagrams).

ANALYZE NEEDS

This activity characterizes the problem space by defining the as-issystems and enterprise, their current deficiencies and potential im-


APPENDIX C 413

provement areas, and the to-be enterprise model, mission/enterpriseuse cases, and associated mission requirements.

An enterprise model depicts an overall enterprise and its con-stituent systems, as well as the enterprise actors (entities external tothe enterprise). The constituent systems include the system to bedeveloped or modified as well as other systems that support the en-terprise. The as-is enterprise is analyzed to determine its limitationsusing causal analysis techniques. The to-be enterprise model isestablished based on proposed changes to the as-is enterprise toaddress the deficiencies. The mission objectives for the enter-prise/mission are used as a basis for deriving top-level mission usecases. The use cases and mission scenarios capture the key function-ality for the enterprise. Measures of effectiveness are identifiedto support the enterprise/mission objectives, and used as a basis fortrade-off and analysis.

Analyze Needs

OOSEM Visualization Used Traditional SE Representation

As-is operational depictionAs-is usersAs-is enterprise modelAs-is scenariosAs-is system requirementsAs-is system designCausal analysisReuse candidatesTo-be operational depiction Mission needs statement, concept of

operationsTo-be enterprise model (operational, full life cycle)Mission scenarios OV-1; system threads; work flows

System use cases Functional flow decomposition,business scenarios; work flows

Mission time line Mission time line

Mission parametric and Mission analysis via simulation andtrade-off analysis mission scenarios. Trade-off analysis

Requirements traceability Requirements traceability to originalmatrix (RTM) documents with decomposition

typically done in requirements tool(DOORS, CORE, POPKIN, etc.)


414 APPENDIX C

OTHER AREAS OF SYSML APPLICATION

In addition to the SE process “Analyze Needs,” there are five otherareas that have been elaborated. Space restrictions limit us to listingthe SE process areas covered in SysML:

• Analyze needs (covered earlier).• Define system requirements.• Define logical architecture.• Synthesize candidate allocated architectures.• Optimize and evaluate alternatives.• Verify and validate the system.

SUMMARY

The OOSEM approach combines traditional systems engineering ap-proaches with object-oriented techniques and the application of theUML modeling language. It is not a pure OO method as used by thesoftware community, but is a hybrid between structured and OOtechniques. Some of the features that have been incorporated intoOOSEM to enhance traditional systems engineering methodologies:

• Use of UML and OO concepts for a model-based approach.• Use of enterprise model to support specification of mission re-

quirements and constraints.• Use of causal analysis techniques to determine limitations of as-

is enterprise and system.• Elaborated context diagram for capturing black box system re-

quirements.• Control function for specifying control requirements.• Store requirements specified at the system level.• Requirements variation analysis.• Logical decomposition and logical architecture versus func-

tional decomposition.• Formalizing the use of partitioning criteria for developing the

architecture.• Verification system development approach.

While the role of UML enhances the discipline with semanticsand a modeling language it is necessary but not sufficient. TheOOSEM approach, the use of SysML and the upgraded tools thatneed to include all of these methods and languages will make the ap-proach sufficient. As a result the role of UML becomes the founda-tion of a structured and disciplined approach to systems engineeringmodeling.


415

Appendix D

A Summary ofthe Eight PhaseEstimating Process

Ray Kile, Chief Systems Engineerfor The Center for Systems Management and

developer of the REVIC parametriccost estimating model.

The Eight Phase Estimating Process (Kile, 1987) was developedinitially to provide structure to a training course for organiza-

tions desiring to use the REVIC model, but it soon proved far moreuseful as a means of elaborating the risk inherent in a cost estimate.Subsequently, the Eight Phase Estimating Process provided a num-ber of key practices that are currently documented in the CMMI.

PHASE 1: THE DESIGN BASELINE PHASE ANDWORK BREAKDOWN STRUCTURE

The Design Baseline Phase starts as soon as the systems engineers,or equivalent, have determined a candidate architecture and designfor the proposed system. The requirements have been gathered andallocated to the components within the candidate architecture and acomplete Work Breakdown Structure (WBS) has been developed forthe project. The output product from the Design Baseline Phase is atable or listing of the components along with the required function-ality of each and the WBS. The products from this phase should bereviewed by the appropriate level of management and placed underconfiguration control.

cott_z04bappd.qxd 7/1/05 3:47 PM Page 415

416 APPENDIX D

PHASE 2: THE SIZE BASELINE PHASE

Once the Design Baseline has been established, the next task is todevelop the size estimates for the components of the system. Whileestimating the size, risk information can be captured in the form ofeither ranges in the estimate or as a standard deviation using meth-ods like PERT. It should be noted that the term size is used in thegeneric sense as a measure of the volume of the work. For softwarecomponents within the WBS, size might naturally be expressed interms of lines of code, function points, number of objects, numberof modules, number of change requests, and so on. Hardware com-ponents can express size as weight, volume, component complexity,and others. Systems may express size as number of components,number of interfaces, performance requirements, and others. Eachtype of component has a different method for estimating and thesize measure should be interpreted as the input attributes to the es-timating method. The resulting size statements should also be re-viewed by management and placed under configuration control.


APPENDIX D 417

PHASE 3: THE ENVIRONMENT BASELINE PHASE

The next step is to specify the Environment Baseline. The environ-ment referred to are the total conditions that will prevail during thedevelopment of the system being built. This includes both the hard-ware and software tools and training that will be provided by the or-ganization, as well as the skills and experience of the personnel whowill be assigned the task. Every parametric estimating methodologyhas a set of parameters that are used to adjust the estimates for dif-ferences in the environment. During the Environment BaselinePhase, all the information collected to date will be used along withknowledge about the organization that will develop the system to es-tablish the appropriate settings for these parameters.

You may think that this phase could have been accomplished atany point in time since organizations normally remain relatively sta-ble in terms of their tools, training, and personnel. However, the sizeof the product to be developed will have a definite impact on theenvironment for several reasons. First the organization’s ability tohandpick personnel and staff a project with experts and highly expe-rienced personnel is far easier for a small project requiring only 5 to10 personnel than for a large project needing 50 to 100 or more per-sonnel. Similarly, the number of tools and ability to provide special-ized training becomes diluted with size. Thus, size estimation mustoccur before the environment can be firmly established.

PHASE 4: THE BASELINE ESTIMATE PHASE

By the time we have reached the Baseline Estimate Phase, we nowhave all the inputs necessary to run our parametric effort /cost andduration models and manual estimating methodologies. Each set ofinput types (sizes, environments) have been independently gener-ated, reviewed, and approved to form the associated baselines. Eachbaseline is linked to the products of previous phases and is traceableback to the original requirements. In this phase, we use the inputparameters in conjunction with the estimating methodologies andsee for the first time the predicted effort and duration for the vari-ous components of the project. It is also at this point in the processthat an effort /cost or duration problem will become apparent. In thepast, the typical response was to somewhat arbitrarily change thesize or environmental parameters to make the estimates match man-agement’s expectations. In our disciplined process we now introducea rule to preclude this break in the chain of traceability.


418 APPENDIX D

Rule 1: Never change the output of a given estimating

process phase without a corresponding change to the

inputs of that phase.

To illustrate the rule, consider the situation where we have just de-termined that we have a budget overrun. In order to reduce the costand follow Rule 1, we must first change one of the inputs to thephase. In other words, we must change the environment or the sizeinformation. We now introduce another rule.

Rule 2: Always try to change the previous phase’s products

first before proceeding up the process chain.

This rule says that we should back up the process chain one phaseat a time when we need to make changes to the outputs of any par-ticular phase. For the example given, where we have a cost prob-lem, we should go to the previous phase first to try to effect achange. We dutifully revisit the environment and see if there isanything we can change to improve the situation. Perhaps we de-cide that if we can handpick staff we can raise the productivityand reduce costs. We must then document the rationale for thechange and reaccomplish the management review to establish anew Environment Baseline. When we then reenter the BaselineEstimate Phase and reaccomplish the estimating methodologywith the new environmental settings, we may find that the im-provement in productivity now meets the cost constraint.

In accordance with Rules 1 and 2, we may have found that we hadno justification for changing any of the Environmental Baseline para-meters without a corresponding change to the Size Baseline, so weproceed back to the Size Baseline Phase. However, here we find thatthe size information in the baseline is directly traceable to the designcomponents and their required functionality. Following Rule 1, wecan’t arbitrarily change the size estimates based on wishful thinking,and must go all the way back to the Design Baseline Phase. In thiscase, in order to reduce the cost to meet the budget, we must eithereliminate a required function or down-scope the means of satisfyingthe requirement. In each case, we must capture the rationale for thechanges and maintain a document trail for subsequent analysis.

PHASE 5: THE PROJECT ESTIMATE PHASE

All parametric models and estimating methodologies come withspecific assumptions about both what development life cycle phases


APPENDIX D 419

(e.g., design, code, verification) and types of activities (e.g., systemsengineering, project management, testing) are included. When thecharacteristics of your project do not match those assumed by themodel adjustments will have to be made. The purpose of the ProjectEstimate Phase is to add those things to the estimate that are not in-cluded in the methodology’ assumptions and to take those things outof the estimate that the methodology assumes but are not in theproject’s scope.

Some examples illustrate the problem. Most parametric estimat-ing models don’t include the up-front systems engineering time re-quired to perform system level requirements analysis. If this work isto be included in the project, we must add the effort and duration re-quired to the model’s estimates. Also, many models were calibratedfrom government projects that had a large amount of documentation.Our project may not require that much documentation and we willhave to reduce the effort (and duration). Another example of activitiesmismatch is the inclusion, or not, of line management in the effort pre-dictions. Most models include the first line project manager, but donot include any other management type labor. Finally, most modelsdon’t include the costs associated with establishing or maintaining de-velopment facilities, or other costs such as travel and materials.

PHASE 6: THE RISK ANALYSIS PHASE

In the Risk Analysis Phase, we will take all the risk information col-lected and try to determine in both a quantitative and qualitativemanner what risks are inherent in this project associated with the es-timate. This phase is usually run in parallel with the next phase, theBudgeting Phase, and the risk analysis should also consider the riskinherent when management decides to price the system differentlyfrom the estimate. Note that this risk analysis is not the same as atechnical risk assessment leading to a risk management plan, althoughthe risks identified and mitigation actions planned should be includedin all project plans including the project’s risk management plan.

Various methods of sensitivity analysis can be performed in-cluding Monte Carlo methods, use of standard deviations to get esti-mate spreads, and simply varying the input parameters to give thebest and worse case estimates. However the risk information is gen-erated, the goal is to make the quantitative and qualitative informa-tion support managers who must trade off desire to get the projectagainst the possibility of an overrun in budget or schedule.

Once management has decided on the budget for this system, therisk analysis takes a slightly different form. We can now go through


420 APPENDIX D

the estimate inputs and determine what changes would be needed toproduce the system for the proposed price. For example, we might saythat in order to meet the proposed price we would have to have theauthority to handpick all the staff. Or we might say that we need toreduce the size by eliminating or reducing some functionality. This in-formation should then be documented in a risk memorandum andused by the project team in their risk management planning.

PHASE 7: THE BUDGETING PHASE

The purpose of the Budgeting Phase is to use the available estimateand risk information to arrive at an acceptable budget and schedulefor the project. Management has two conf licting goals during thisphase. The first goal is to win the project or get approval to proceed.The second goal is to ensure there won’t be an overrun of budget orschedule. As management tries to optimize probability of getting ap-proval for the project by lowering the budget, they are simultaneouslyincreasing the probability of an overrun. Similarly, if managementwants to ensure there won’t be an overrun by raising the budget to in-clude some management reserve, they are reducing the probability ofgaining approval.

Once management has decided on the budget, the risk analysisactivities in phase 6 are reengaged to determine the risk inherent inthe difference between the project estimate and the project budget.Management should carefully consider the risks and ensure that ap-propriate risk planning and mitigation are included in the project’splans and schedules.

PHASE 8: DYNAMIC DATA COLLECTION PHASE

The purpose of the Dynamic Data Collection Phase is to close theloop by gathering data for calibration of the estimating methodologyfor future estimates. This includes both the gathering of data fromthe current project as it is progressing to help manage the project andadding completed project data to a database used for re-calibratingthe methodology. This phase also continuously tracks the impact oneffort, cost, and duration as risks become reality.

For ongoing projects, data collection can be used to calibrate themethodology on the f ly. Actual experience on the project through amajor milestone can be used to predict the remaining effort or dura-tion in a manner analogous to using actual cost data to calculate theCost and Schedule Performance Indexes for Earned Value projects.


421

Appendix E

Overview ofthe SEI-CMMI

Ray Kile, Chief Systems Engineerfor The Center for Systems Management

As described in Chapter 21, the U.S. Department of Defense(DoD) initiated the development of the SEI’s Capability Matu-

rity Model (CMM) that evolved to the CMMI. The CMM organizedthe industry’s best practices into a framework for assessing the ex-tent to which they were implemented by an individual organizationas a means for the organization to guide its performance improve-ments. After initial successes with the CMM, the DoD recognizedthat the management disciplines imposed by the CMM were equallyapplicable to systems development, but many organizations were ig-noring it because of the heavy software-only f lavor. Other disciplinemodels such as the Federal Aviation Administration’s iCMM® andthe Systems Engineering CMM (SE-CMM) were merged into theresulting Capability Maturity Model Integration (CMMI). The newmodel greatly expands the engineering aspects of the original modelwhile retaining all the original management practices.

Process Improvement

1. The continuous adjustment of process steps to improve both ef-ficiency and results.

2. A program of activities designed to improve the performanceand maturity of the organization’s processes, and the results ofsuch a program. [SEI]

cott_z05bappe.qxd 7/1/05 3:48 PM Page 421

422 APPENDIX E

These definitions describe a general approach to improving any pro-cess. A distinction should be clearly made between a general processimprovement program and the CMMI model. Many organizations havechosen to pursue process improvements in business and manufactur-ing areas and are geared toward reducing costs, shortening productioncycles, and many other goals expressed by management. These im-provement programs all start with the existing status quo and attemptto improve the condition of interest. The CMMI model starts with adifferent premise. It is a collection of best practices gathered from in-dustry and government organizations over the years that ref lect a setof characteristics that good organizations should have. The CMMIrepresents a set of initial conditions that the organization can compareitself against in order to decide upon a prioritized set of actions to“improve.” In essence, they are the initial desired end state. However,merely satisfying a best practice doesn’t end it, since the model onlydescribes the “what” that should be done and not the “how.” Organi-zations typically find that their initial approach to implementing apractice from the model may not be the most efficient in terms of ef-fort, cost, schedule, or quality and continue with their process im-provement programs long after reaching an initial rating. There arevarious approaches available to describe how to run a process im-provement program, including the SEI’s IDEAL model, which can bedownloaded from the SEI’s web site at www.sei.cmu.edu.

CAPABILITY MATURITY MODELINTEGRATION (CMMI)

The purpose of CMMI is to provide guidance for improving an orga-nization’s processes and its ability to manage the development, acqui-sition, and maintenance of products and services. The CMMI placesproven practices into a structure that helps an organization assess itsorganizational maturity and process area capability, establish priori-ties for improvement, and guide the implementation of these improve-ments. (Source: SEI)

The CMMI model supports two basic views of improvementthrough its representations, Staged and Continuous. Each represen-tation contains the same process areas and best practices; however,the organization and approach are different. An organization that isexperiencing problems in a given area can look to the Continuousrepresentation and work on individual process areas that have po-tential for fixing its problems. For example, an organization that ishaving problems with cost and schedule overruns might look to the


APPENDIX E 423

Project Planning process area. There it will find recognized bestpractices that describe how to estimate the scope of its projectsalong with the cost and schedule estimates, reconcile the differ-ences between those estimates and externally imposed budget /schedule constraints, and clearly document the resulting plans.

The Staged representation, on the other hand, provides a prede-fined road map for addressing the organization as a whole and orga-nizes the process areas in stages that ref lect a well defined group ofproject and organizational characteristics. The first stage ref lectsprojects planning how to do the work, documenting those plans, per-forming the project according to those plans, and putting the feed-back mechanisms in place to recognize when it’s going astray.

In the Staged approach, an organization works on seven processareas to reach the second maturity level, 14 more to get to the thirdlevel, and two more for each of the fourth and fifth levels, a total of25 process areas if the organization pursued it all the way. In theContinuous approach, the organization may chose to work on onlyone process area at a time, get it’s processes in good shape accordingto that process area’s best practices and then move on to anotherprocess area, or not.

The emphasis in the staged approach is reaching a specified Ma-turity level, while the emphasis in the Continuous approach is reach-ing a specified capability level for a individual process area. This issummarized in the two diagrams that follow. In the Staged approach,there are five maturity levels and the organization has either reachedthe maturity level or not, there is no credit for partial fulfillment.The Continuous approach shows that the organization can have dif-ferent goals for individual process areas.

CMMI Model – Two Representations

STAGED (by Maturity Level)

0

1

2

3

4

5

Process Areas

Cap

abili

ty L

evel

Provides flexibility for organizations tochoose which processes to emphasizefor improvement, as well as how muchto improve each process.

1

2

3

4

5

Maturity Level

Provides predefined road map fororganizational improvement, based onproven grouping of processes andassociated organizational relationships.

CONTINUOUS (by Process Areas)


424 APPENDIX E

CONTINUOUS REPRESENTATION

Continuous representation: A capability maturity model structurewherein capability levels provide a recommended order for approach-ing process improvement within each specified process area.

The diagram that follows shows the structure of each process areawithin the Continuous representation:

Each process area contains a number of specific and genericgoals. The specific goals express a desired capability that addressesthe implementation of the process area. Within the model, the goalsare the only required items. To satisfy the intent of any goal, we ex-pect the organization would implement certain practices. For exam-ple, within Project Planning the first specific goal states:

Estimates of project planning parameters are established andmaintained.

To satisfy that goal, we would expect that certain things wouldhave to be done; establishing the scope of the project, determiningthe project’s life cycle that will be used, estimating costs and sched-ules, and so on. These things become the specific practices.

The Generic Goals express a desired capability that addressesthe organization’s infrastructure that needs to be in place to supportprojects. These Generic Goals are identical in each of the 25 processareas, although they may be interpreted slightly differently. For ex-ample, the second generic goal states:

The process is institutionalized as a managed process.

CMMI Continuous Representation

Process Area 2Process Area 2 Process Area NProcess Area NProcess Area 1Process Area 1

SpecificPractices

SpecificPractices Generic

Practices

GenericPractices

CapabilityLevels

CapabilityLevels

. . .

SpecificGoals

SpecificGoals Generic

Goals

GenericGoals


APPENDIX E 425

We expect that a managed process is one that is required by man-agement (a policy), has a plan, has adequate resources to accomplish,has someone specifically assigned the responsibility to do it, hastrained people performing it, has considered the impacts on stake-holders, controls its work products, is monitored and corrective ac-tions taken when deviations of actual to planned are noted, isobjectively evaluated, and is continuously reviewed by management.These expectations are ref lected in the Generic Practices.

For any given process area, the extent to which the SpecificGoals and Generic Goals are fully satisfied determines the organiza-tion’s Capability Level for that process area. Any individual processarea can range in capability from levels 1 through 5 (process areasstart at level 0) by satisfying all specific goals (capability level 1) andthen the generic goals (generic goals 1 and 2 for capability level 2,generic goals1, 2, and 3 for capability level 3, etc.).

STAGED REPRESENTATION

Staged representation: A model structure wherein attaining the goalsof a set of process areas establishes a maturity level; each level buildsa foundation for subsequent levels.

Within the Staged representation, the process areas, specific goals,and generic goals are identical. There are some minor differences inthe number of specific practices for some of the process areas, butnot enough to significantly affect the description. The difference asshown in the diagram that follows is that there are preselectedgroupings of process areas within a given Maturity Level:

CMMI Staged Representation

Maturity Level

Process Area NProcess Area 1

GenericPractices

GenericGoals

SpecificPractices

SpecificGoals

Process Area 2

CommitmentTo Perform

DirectingImplementation

Ability toPerform

VerifyingImplementation

Common Features

. . .


426 APPENDIX E

Everything else is the same. The separation of the generic prac-tices into common feature groupings is intended to clarify how thepractices relate to the organization’s commitment and ability to per-form the process area, as well as how it directs the implementationand subsequently verifies the implementation was done correctly.The generic goals are identical to the Continuous representation,however in the Staged representation there is no need to have anyindividual process area satisfy the generic goals for level 4 or 5.Once all the process areas within a given maturity level have beensatisfied through capability level 3, the organization is said to havereached Maturity Level 3.

This discussion has covered the high-level concepts of theCMMI model. Interested readers should go to the Software Engi-neering Institute’s web site, www.sei.cmu.edu/cmmi, and downloadthe full model for more details.


427

Glossary

One HundredCommonlyMisunderstoodTerms

This glossary contains terms that are often misunderstood within the project management andsystems engineering domains. It also includes important terms that appear throughout this book.

Communicating Project Management, a companion to this book, published by John Wiley & Sons,2003, contains over 1,900 definitions, some with illustrations.

affinity diagram A problem-solving techniquefor relating ideas, issues, or other items that resultfrom brainstorming. The affinity diagram is formedby categorizing the items (often in the form of“sticky notes” or index cards) in order to serve as acatalyst for breakthrough ideas and to reveal rela-tionships.

agile development A software developmentmethod that focuses on individuals and interactionsover processes and tools, working software overcomprehensive documentation, customer collabora-tion over contract negotiation, and responding tochange over following a plan.

analytical hierarchy process (AHP) A decisionprocess based on pair-wise comparison of decisioncriteria followed by applying a mathematical processto calculate the relative importance of each crite-rion. Then scoring alternatives, again using pair-wise comparison, against those criteria to determinethe best overall candidate.

architecture The framework and interrelation-ships of elements of a system. Typically illustratedby both a pictorial and a decomposition diagramdepicting the segments and elements and their inter-faces and interrelationships.

artifact A product or result. Can be samples,models, documents, white board sketches, and evenoral descriptions.

baseline The gate-controlled step-by-step elabo-ration of business, budget, functional, performance,and physical characteristics, mutually agreed to bybuyer and seller, and under formal change control.Baselines can be modified between formal decisiongates by mutual consent through the change controlprocess. Typical baselines are Contractual Baseline,Budget Baseline, Schedule Baseline, User Require-ments Baseline, Concept Baseline, System Specifi-cation Baseline, Design-to Baseline, Build-toBaseline, As-Built Baseline, As-Tested Baseline, andAs-Fielded Baseline.

cott_z06bgloss.qxd 6/30/05 4:16 PM Page 427

428 GLOSSARY

baseline budget The buyer/seller agreed-to bud-get and budget management approach that is underformal change control. Can include the fundingsource, time-phased budget, total funding, timephased funding profile, management reserve, andmethod for handling funding needs beyond thefunding limit.

baseline—business The buyer/seller agreed-tobusiness requirements and business approach thatare under formal change control. Can include theAcquisition Plan, Contract, Subcontracts, ProjectMaster Schedule, Implementation Plan, SystemEngineering Management Plan, Contract Deliver-able(s) List, and the Contract DocumentationRequirements List.

baseline—technical The buyer/seller agreed-totechnical requirements and technical approach thatare under formal change control. Can include theUser Requirements Document, User CONOPS, Sys-tem Requirements Document, Concept DefinitionDocument, System CONOPS, System Specifica-tions, “Design-to” specifications, “Build-to” docu-ments, and “As-built,” “As-tested,” “As-accepted,”and “As-operated” configurations.

best practices Processes, procedures, and tech-niques that have consistently been demonstrated tocontribute to achieving expectations and that aredocumented for the purposes of sharing, repetition,and refinement.

beta test The testing, evaluation, and construc-tive feedback to the developers of a new product bya select group of potential users prior to productrelease.

black box testing Verification of entity inputsand outputs only.

cohesion The degree of interactivity and interde-pendence among solution elements.

concept evaluation criteria The musts, wants,and weights used to judge alternative concepts.

configuration item (CI) A hardware, software,or composite entity at any level in the system hierar-chy designated for configuration management. CIshave four common characteristics: defined function-ality; replaceable as an entity; unique specification;

formal control of form, fit and functionality. EachCI should have an identified manager and may haveCI-unique design reviews, qualification certifica-tion, acceptance reviews, and operator and mainte-nance manuals. See lowest configuration item (LCI).

consent-to meeting A meeting, with all partiesdirectly involved in a decision, held to criticallyexamine readiness to proceed. Not all consent-tomeetings are decision gates, but all decision gatesare consent-to meetings.

Constructive Cost Model (COCOMO) Nonpro-prietary software cost and schedule estimatingmodel originally developed by Barry Boehm (Soft-ware Engineering Economics, 1981). Produces anestimate of the number of man months required todevelop common software products at three levelsof complexity: basic, intermediate, and detailed.

Critical Chain Method Eli Goldratt’s theory ofconstraints (TOC) based planning approach thatmoves most individual task contingencies to the endof the critical path and applies resource availabilityas a driving factor in schedule achievement and crit-ical path determination. The process surfacesresource constraints that must be addressed toachieve schedule.

Critical Design Review (CDR) The series ofdecision gates held to approve the build-to andcode-to documentation, associated draft verificationprocedures, and readiness and capability of fabrica-tors and coders to carry out the implementation. Allhardware, software, support equipment, and toolingshould be reviewed in ascending order of unit tosystem. More appropriately called Production Guar-antee Review since proof is required that the fabri-cation and coding called for can actually be carriedout and that it will yield results that meet thedesign-to specifications. The evidence provided istypically samples of the critical processes to demon-strate credibility and repeatability.

decision gate A preplanned management event inthe project cycle to demonstrate accomplishments,approve and baseline results, and approve theapproach for continuing the project. (Also known asa control gate.)


GLOSSARY 429

decision tree A decision analysis technique con-sisting of a diagram showing sequence of alterna-tives considered and those selected.

decomposition and definition The hierarchical,functional, and physical system partitioning intohardware assemblies, software components, andoperator activities that can be scheduled, budgeted,and assigned to a responsible individual for thedevelopment of the associated design-to, build-to,and verification documentation.

decomposition diagrams—HW and SW Thenoun levels of the WBS that illustrates the struc-tured decomposition and integration of a system.

delivery method The choice between holding allsystem increments and versions of increments untilfull integration and delivery (single delivery) or thefielding of partial capability through staged deliveryof increments and versions of increments and devel-oping capability over time (multiple delivery).Bridges and tunnels require single delivery whilelight rail systems and software often use multipledeliveries.

development method The selection of unified,incremental, linear, and /or evolutionary development.

development model The selection of the Water-fall, Spiral, or Vee, as the model for managing thedevelopment process. Selection depends on theapproach to risk management and other factors.

development tactics The selection of the devel-opment model(s) and methods, together with thedelivery method, for a development project.

dispersion ratio The ratio of total equivalentheadcount charging to a project for a specific perioddivided by the number of different individualscharging in the same period. An important metric toreveal the extent of part-time individuals workingon a project. A value of 1 would indicate no part-time personnel while a value of 0.5 would indicatethat the average person is only working half-time onthe project.

evolutionary development A developmentmethod in which successive versions are produced torespond to discoveries surfaced by the previous ver-sions. Applied when requirements are uncertain and /

or when technology experimentation is required. Thealternative method is linear development.

failure mode, effects, and criticality analysis(FMECA) An analysis of the potential failuremodes, the resulting consequences, the criticality ofthe consequences, and actions to reduce the proba-bility of serious failures (i.e., single point cata-strophic failures).

fishbone diagram An analysis tool that providesa systematic way of evaluating effects and thecauses that create or contribute to those effects.The fishbone diagram assists teams in categorizingthe many potential causes of problems or issues inan orderly way. The problem/issue to be studied inthe “head of the fish.” The succeeding “bones” ofthe “fish” are the major categories to be studied: the 4 Ms: Methods, Machines, Materials, Man-power; the 4 Ps: Place, Procedure, People, Policies;the 4 Ss: Surroundings, Suppliers, Systems, Skills.Dr. Kaoru Ishikawa, a Japanese quality control sta-tistician, invented the fishbone diagram.

House of Quality A mapping technique for relat-ing the ability of design features to satisfy priori-tized requirements. A matrix of cells, appearing likea house, has rows containing the requirements andcolumns containing the design features. The inten-sity of the cell hue indicates the degree of require-ments satisfaction. The plus and minus symbols inthe cells of the triangular house roof highlightstrong or weak correlation in the satisfaction ofrequirements by multiple design features.

increment One of a series or group of plannedadditions or contributions.

incremental development A hardware/softwaredevelopment method that produces a partial imple-mentation and then gradually adds preplanned func-tionality or performance in subsequent add-onincrements. The alternative method is unifieddevelopment.

independent verification and validation(IV&V) The process of proving compliance tospecifications and user satisfaction by using person-nel that are technically competent and manageriallyseparate from the development group. The degreeof independence of the IV&V team is driven by


430 GLOSSARY

product risk. In cases of highest risk, IV&V is per-formed by a team that is totally independent fromthe developing organization.

Integrated Definition for Functional Modeling(IDEF0) A multiple page (view) model of a sys-tem that depicts functions and information or prod-uct f low. Boxes illustrate functions and arrowsillustrate information and product f low. Alpha-numeric coding is used to denote the view:IDEF0—system functional model; IDEF1—informational model; IDEFX—semantic data model;IDEF2—dynamic model; IDEF3—process andobject state transition model.

linear development A method for developing asystem solution that is well understood and accom-plished in a single pass as opposed to that requiringexperimentation and multiple versions to achieve asatisfactory solution. The alternative method is evo-lutionary development.

logic diagram A diagram depicting the sequentialand parallel interrelationships (functions or data)between entities or activities. Often used to showsystem functionality, software functionality, hard-ware system interactions, and project managementserial and parallel sequences and interactions. Behav-ior diagrams, functional f low diagrams, data f low dia-grams, and project schedule networks are examples.

lowest configuration item (LCI) The lowestarchitecture entity from the perspective of theresponsible developer. For instance, the car batterywould be an LCI for the car designer. The batterycase would be an LCI for the battery developer.

mock-up A physical or virtual demonstrationmodel, built to scale, to verify proposed design fit,critical clearances, and operator interfaces. In soft-ware, screen displays are modeled to verify contentand layout.

model A representation of the real thing used todepict a process, investigate risk, or to evaluate anattribute, such as a technical feasibility model (risk)or a physical fit model (attribute). Models may bephysical or computer based, for example, thermalmodel, kinetic model, finite element model.

model—advanced development model A termfor a research model that is built to prove a concept.

model—engineering model A technical demon-stration model constructed to be tested in a simu-lated or actual field environment. The model meetselectrical and mechanical performance specifica-tions, and either meets or closely approaches meet-ing the size, shape, and weight specifications. It maylack the high-reliability parts required to meet thereliability and environmental specifications, but isdesigned to readily incorporate such changes intothe prototype and final production units. Its func-tion is to test and evaluate operational performanceand utility before making a final commitment toproduce the operational units. Also called Engineer-ing Development Model.

model—hardware and software feasibilitymodel A hardware or software model constructedto prove or demonstrate technical feasibility. Tech-nical feasibility should be proven at the PreliminaryDesign Review.

model—interface simulation A hardware orsoftware interface simulation model used to verifyphysical and functional interface compatibility.

model—manufacturing demonstration A sam-ple to demonstrate the results of a critical process.The objective is to confirm the ability to reliablymanufacture using the process and to achieve therequired results. Results are often provided as evi-dence at the Critical Design Review.

model—mock-up A physical demonstrationmodel, built to scale, used to verify proposed designfit, critical clearances, and operator interfaces.Mock-up verification results should be available atthe Critical Design Review.

model—preproduction model Entity built toreleased drawings and processes, usually under engineering surveillance, to be replicated by routinemanufacturing. Provides manufacturing with amodel to demonstrate what is intended by the documentation.

model—production model A productiondemonstration model, including all hardware, soft-ware, and firmware, manufactured from productiondrawings and made using production tools, fixtures,and methods. Generally, the first article of the pro-duction unit run initiated after the Production


GLOSSARY 431

Readiness Review (PRR). A prototype model, alsobuilt from production drawings, may precede thePRR to provide confidence to authorize fabricationof the production model.

model—requirements understanding A soft-ware or hardware model developed by a provider todemonstrate the understanding of a buyer ’s problemor to help in resolving what the buyer wants.

model—risk reduction All models are used toreduce the risk in some area of concern.

model—technical demonstration model Anexperimental device constructed and operated in alaboratory environment to demonstrate applicationof a scientific or engineering principle. Sometimescalled a “Breadboard Model.” A more elaboratemodel, sometimes called a “Brassboard” is usedwhere certain physical properties, such as dimen-sions, are critical to performance as in RF devices.

model—test simulator A functional replicationof the system used to verify that the test equipmentand test facility is configured properly to test thereal system.

Monte Carlo analysis A technique to estimatethe likely range of outcomes from a random processby simulating the process a large number of timeswith random values. When applied to static PERTscheduling it helps predict how the real schedulemight behave. Random durations are applied to eachactivity in the network and the probability is calcu-lated for each activity on a critical path. In a com-plex schedule it provides insight into whichactivities should receive special attention to ensurethey occur as planned. Also referred to as MonteCarlo Simulation.

N2 diagram or chart A graphical depiction ofthe functions within a system, together with theone-way interactions between each function orderedin a matrix, with function or entities on the centerdescending diagonal cells. Since functions occupyeach diagonal cell, the total number of cells is equalto the square of the number of function, hence thename. Interface functions and constraints are shownin the cells that correlate to both interfacing entitiesand the graphic is read clockwise. For example, cellA1 would output to cell B2 and cell B1 would con-

tain the interface functions. Blank cells indicate thatthere are no interfaces between those two entities.

optimizing process A quantitatively managedprocess that is improved based on an understandingof the common causes of variation inherent in theprocess. A process that focuses on continuallyimproving the range of process performance throughboth incremental and innovative improvements.

pairwise comparison The process of rankingitems by comparing all pairs and, through mathe-matical analysis, determining the relative ranking.See Analytical Hierarchy Process.

Pareto Chart A column chart where columns aretypes of defects and column height is frequency ofoccurrence. Used to pinpoint where correctiveaction should be applied to most effectively improvequality by reducing the greatest number of defects.Also called Pareto Diagram.

pedigree The documented heritage of material orcomponents usually tracing from the raw material tothe finished entity.

Preliminary Design Review (PDR) The seriesof decision gates held to approve the concepts,design-to specifications, associated verificationplans, and approaches to developing build-to andcode-to documentation for all configuration items(CIs). All hardware, software, support equipment,facilities, personnel, and tooling should bereviewed in descending order of system to assem-bly. More appropriately called Performance Guar-antee Review since it must be proven that thespecified performance is achievable. This isusually done by laboratory tests, analytical models,or field tests.

preplanned product improvement (PPPI)Provisions that anticipate and provide for futureincreased capability. This may require the prede-cessor versions to have excess capability orspecial provisions to accommodate subsequentenhancements.

process performance baseline A documentedcharacterization of the actual results achieved byfollowing a process, which is used as a benchmarkfor comparing actual process performance againstexpected process performance. [SEI]


432 GLOSSARY

project business management The functionthat commonly manages cost, schedule, legal, con-tracts, subcontractors, human resources, safety, andsecurity. The function works closely with systemsengineering to keep the technical, business, andbudget baselines congruent.

project products list (PPL) A matrix summaryof what entities and services must be provided toaccomplish the project including quantities requiredfor each form of the entity. Example: mock-up, fieldtest unit, deliverable, spare, and so on. The PPLforms the basis for planning, estimating, assigning,material ordering, and so on.

project products list fact sheets (PPLFS) Anarrative description of each entry of the projectproducts list. The narrative should be written by themost knowledgeable expert and should include suffi-cient information to facilitate planning, estimating,and scheduling.

project work authorizing agreement (PWAA)The work release system document that defines andauthorizes work tasks to be performed for a project.The PWAAs and subcontracts are the end product ofimplementation planning. The PWAA should containthe following five elements: task description (inputrequired, task to be performed, and output resultingfrom successful completion); time-phased budget;schedule, with appropriate intermediate milestones,and if appropriate, detailed work packages to enableearned value reporting; signature of the task leaderindicating commitment to do the task within thetime and budget constraints; signature of the proj-ect manager indicating that the task is authorized.

prototype—hardware A specification-compliant,production readiness demonstration model devel-oped under engineering supervision that representswhat manufacturing should replicate. All designengineering and production engineering must becomplete, and the assembly must be under configu-ration control.

prototype—software A term, currently withmultiple meanings. A “rapid prototype” is usually asoftware requirements demonstration model, whichprovides a simulated representation of the softwarefunctionality and operator interface. The model

facilitates early buyer-developer agreement on thedesign approach. A software prototype may also be atechnical demonstration model. Except with “Evolv-ing Prototypes,” the code is usually discarded oncethe model has served its purpose.

qualification Proving that the design will survivein its intended environment with margin. The processincludes testing and analyzing hardware and softwareconfiguration items to prove that the design will sur-vive the anticipated accumulation of acceptance testenvironments, plus its expected handling, storage, andoperational environments, plus a specified qualifica-tion margin. Qualification testing usually includestemperature, vibration, shock, humidity, softwarestress testing, and other selected environments. Qual-ification by similarity may be used if the item inquestion is sufficiently similar to a qualified item andthe use is also sufficiently similar so as to not invali-date the previous qualification evidence and decision.

qualification certificate A configuration itemspecific document that defines the extent of thequalification of the CI. It provides subsequent usersdetails of the qualification environments and history.

quality function deployment (QFD) The map-ping of requirements satisfaction to product entitiesand features resulting in a requirements satisfactioneffectiveness map. For instance, the hefty chromegear shift lever with hand stitched leather knob in ahigh priced sports car has little to do with the shift-ing capability of the transmission but has a largeimpact on the look and feel of the sports car. Simi-larly the “thunk” sound of the doors closing radiatesquality while having little contribution to strengthor safety. The QFD House of Quality effectivenessmap reveals where the various desirable attributesare being realized.

red team Objective peer or expert review of doc-umentation and presentation material to identifydeficiencies and recommend corrective action. Ared team review is usually used to evaluate andscore proposals before submittal, but is applicable toany documentation and presentation material. A redteam is not the forum for a debate and the docu-ment owner decides which of the red team recom-mendations will be implemented.


GLOSSARY 433

regression test Tests to ensure that imposedcorrective actions to correct a deficiency have notinadvertently altered other functions. May requirecomplete retesting to achieve the requiredconfidence.

requirements Needs or necessities; somethingdemanded or obligatory. For clarification purposes,a descriptor should always precede requirements;for example, user requirements, system require-ments, operational requirements, contract require-ments, and test requirements.

requirements traceability verification matrix(RTVM) A document that maps the parent-childrelationships of requirements and the results ofverification.

schedule performance index (SPI) In theearned value system, the schedule efficiency indexof the ratio of actual schedule achievement (BCWPor the earned value) to the planned scheduleachievement (BCWS or planned value) for a speci-fied period. SPI = BCWP/BCWS. An SPI of 1.0indicates that schedule progress is according to plan.An SPI of less than 1.0 indicates that the rate ofprogress is behind plan. An SPI of more than 1.0indicates progress rate is ahead of plan.

scope The sum of products, services, and resultsto be provided. The PMI PMBOK® Guide definesProject Scope as the work that must be performedto deliver a product, service, or result with thespecified features and functions.

significant variance A variance from the planthat exceeds the predefined threshold and thereforerequires variance analysis complete with plannedcorrective action.

Six Sigma A quality program developed byMotorola that focuses on meeting six-sigma qualitythat equates to only allowing 3.4 defects per millionopportunities.

skunk works A collocated project environmentusually isolated from other operations and /or dis-tractions, to shorten communication paths andto keep highly skilled functional contributors close to one another and to the project activitycenters.

spiral—evolutionary The DoD nomenclaturefor development that produces and fields solutionsthat are later enchanced by added or replacedincrements.

Spiral model A software development modelauthored by Dr. Barry Boehm in 1980 to promotethe management of requirements, feasibility, andoperational risk prior to proceeding with traditionalphased software development. The model alsoencourages user and stakeholder involvement inearly risk resolution. Although developed for thesoftware profession the model is also applicable tohardware development.

stakeholder Anyone that can affect or beaffected by the project.

stubs and drivers Temporary software productscreated to simulate unavailable parts of the systemduring development and testing.

system A combination of any or all of hardware,software, facilities, personnel, data, and services toperform a designated function with specifiedresults. The highest member of the example systemdecomposition hierarchy.

system concept of operations (CONOPS) Adescription of how the selected solution isexpected to operate. It typically includes a narra-tive description, data f low diagrams, primary oper-ation plan, secondary operations, and timelines. Aday in the life of the system. Also known as SystemCONOPS (1).

system decomposition hierarchy A set ofranked terms defining the composition of a system.The number of levels will be determined by thecomplexity of the system. The INCOSE Handbookdefines these seven decomposition levels from high-est to lowest: system, segment, element, subsystem,assembly, subassembly, part.

system integrity Congruency of the business,budget, and technical baselines. A developing systemhas integrity when its baselines are in agreement orcongruent and results from establishing a balanceamong the three aspects (business, budget, and tech-nical) at the outset of the project and maintainingthat balance as changes occur to any baseline.


434 GLOSSARY

system of systems (1) A set or arrangement ofinterdependent systems that are related or con-nected to provide a given capability. (2) Anarrangement of independent systems that can bearranged and interconnected in various ways to pro-vide different capabilities.

Systems Modeling Language (SysML) A general-purpose notational language for specifying, describ-ing, and visualizing complex systems. SysML buildson UML.

technical aspect of the project cycle The tech-nical management approach to achieving the projectsolution shown as an aspect of the project cycle andoften depicted in a Vee format to illustrate decom-position on the left and integration on the right.

unified development The development methodfor a single entity, such as a concrete foundation orspacecraft structure, that is not divided into incre-ments. The alternative method is incremental devel-opment.

Unified Modeling Language (UML) A general-purpose notational language for specifying, describ-ing, and visualizing complex software, especiallylarge, object-oriented projects. UML builds on pre-vious notational methods such as Booch, OMT, andOOSE.

user concept of operations (CONOPS 2) Theuser ’s planned use of any solution in the operationalenvironment. It may include the physical environ-ment, operational environment, operating scenarios,

and requirements for logistics, provisioning, andmaintenance. This document should be created earlyin the project cycle during the User RequirementsDefinition Phase.

validation Proof that a developed system meetsactual user needs and that the user is satisfied.

Vee model (Dual) A system development modelauthored by Dr. Kevin Forsberg and Hal Mooz toillustrate integrated architecture and entity solutiondevelopment.

verification Proof of compliance with specifica-tions. Verification may be determined by test,inspection, demonstration, or analysis.

verification, validation, and test (VV&T) Themethods to prove that the solution meets both spec-ification and user requirements. This commonacronym is misleading in that “test” is a method ofverification.

Waterfall model A software development modelauthored by Dr. Win Royce in 1969 to promote asequentially phased software development process.The model promotes knowing the requirementsbefore designing and designing before coding, andso on. The objective was to provide a repeatableprocess to the then undisciplined (generally ad hoc)software development environment. Although devel-oped for the software profession the model is alsoapplicable to hardware development.

white box testing Verification of an entity’sinternal behavior as well as inputs and outputs.


435

Notes

INTRODUCTION

1. Hans Hoffman, Search for the Real (Cambridge,MA: MIT Press, 1948).

CHAPTER 1

1. Society of Satellite Professionals Journal (June/July 2004).

2. Hal Mooz, Kevin Forsberg, and Howard Cotter-man, Communicating Project Management(Hoboken, NJ: Wiley, 2003).

CHAPTER 2

1. A Guide to the Project Management Body ofKnowledge (PMBOK® Guide) Project Manage-ment Institute (Philadelphia, PA: 2004).


CHAPTER 3

1. Gary Kinder, Ship of Gold in the Deep Blue Sea(New York: Vintage Books, 1998), p. 92.

2. Ibid.3. Henri Fayol, General and Industrial Management

(New York: IEEE Press, 1984). A translation ofthe original French version published in 1916.

4. Michele Jackman (with Susan Waggoner), StarTeams, Key Players (New York: The National As-sociation for Female Executives Professional Li-brary, Holt and Company, 1991).

5. Gary Kinder, Ship of Gold in the Deep Blue Sea(New York: Vintage Books, 1998), p. 92.

6. Dennis Kinlaw, Superior Teams (Hampshire, En-gland: Gower Publishing Ltd., 1998).

7. Ibid.

CHAPTER 4

1. James Womack, Lean Thinking.

CHAPTER 5

1. Final Report of the Columbia Accident Investi-gation Board (Washington, DC: NASA, August2003), p. 187.


3. Stephen W. Littlejohn, Theories of Human Com-munication (Belmont: Wadsworth PublishingCompany, 1995).

4. Richard L. Lanigan, Phenomenology of Communi-cation: Merleau Ponty’s Thematics in Communi-cology and Semiology (Pittsburgh, PA: DuquesneUniversity Press, 1988).

5. Final Report of the Columbia Accident Investi-gation Board (Washington, DC: NASA, August2003), pp. 199–201.

6. Dianna Booher, Communicate with Confidence!(New York: McGraw-Hill, 1994), p. xvi.

7. Ibid.8. Philip J. Harkins and Warren G. Bennis, Pow-

erful Conversations: How High-Impact Lead-ers Communicate (New York: McGraw-Hill,1999).

9. Robert Kegan and Lisa Laskow Lahey, How theWay We Talk Can Change the Way We Work:

cott_z07bnotes.qxd 7/1/05 3:44 PM Page 435

436 NOTES

Seven Languages for Transformation (San Fran-cisco: Jossey-Bass, 2000).

10. Juanita Brown and David Isaacs, “Conversation asa Core Business Process,” The Systems Thinker(Cambridge, MA: Pegasus Communications, 1996/1997), pp. 1–6.

11. Brown and Isaacs, “Conversation as a Core Busi-ness Process.”

12. Dianna Booher, Communicate with Confidence!(New York: McGraw-Hill, 1994), p. xvi.

13. Report of the Presidential Commission on theSpace Shuttle Challenger Accident (1986),pp. 94–95.

14. Robert Slater, Jack Welch and the GE Way: Man-agement Insights and Leadership Secrets of theLegendary CEO (New York: McGraw-Hill,1999), p. 15.

15. William Duncan from his Foreword to Visualiz-ing Project Management, 2nd ed. (Hoboken, NJ:Wiley, 2000).

16. Final Report of the Columbia Accident Investi-gation Board (Washington, DC: NASA, August2003), p. 187.

17. John L. Beckley, The Power of Little Words (Fair-field, NJ: The Economics Press, 1984).

18. Simon Winchester, The Professor and the Mad-man (New York: HarperCollins, 1998).

19. Sybil Parker, ed., McGraw-Hill Dictionary ofMechanical and Design Engineering (New York:McGraw-Hill, 1984).

20. R. H. Thayer and M. Dorfman, eds., Tutorial:System and Software Requirements Engineering(Washington, DC: IEEE Computer SocietyPress, 1990), pp. 606–676.

21. A Guide to the Project Management Body ofKnowledge (Sylva, NC: Project Management In-stitute, 1996), pp. 159–171.

22. Report of the Presidential Commission on theSpace Shuttle Challenger Accident (1986), p. 95.

CHAPTER 6

1. Stephen R. Covey, The Seven Habits of HighlyEffective People (New York: Simon & Schuster,1989).

2. Michele Jackman (with Susan Waggoner), StarTeams, Key Players (New York: The National As-sociation for Female Executives Professional Li-brary, Holt and Company, 1991).

3. Peter F. Drucker, People and Performance: TheBest of Peter Drucker on Management (NewYork: Harper & Row, 1977).

4. Deborah S. Kezsbom, Donald Schilling, andKatherine A. Edward, Dynamic Project Manage-ment (New York: Wiley, 1988).

5. Dennis Kinlaw, Superior Teams (Hampshire, En-gland: Gower Publishing Ltd., 1998), pp. 201–233.

CHAPTER 7

1. NASA GPG 7120.5 System Engineering (Green-belt, MD: Systems Management Office, NASAGSFC, June 2004); NASA NPG 7120.5C Pro-gram and Project Management Processes and Re-quirements (Washington, DC: AE/Office ofChief Engineer, NASA HQ, March 2005).

2. DoDI 5000.2 Acquisition Management (DoD2004).

3. ISO 15288, “Systems Engineering: System LifeCycle Processes” (ISO/IEC 2002).

4. Michael Cusumano and Richard Selby, MicrosoftSecrets (New York: Simon & Schuster, 1995),pp. 192–207.

5. Frank Addeman, “Managing the Magic,” PMNetwork, The Professional Magazine of the PMI(July 1999), pp. 31–36.

6. Helena Russell, Partnership Pays: Project Man-agement the Øresund Way (Kent, UK: RouteOne Publishing, Ltd., 2000).

7. Jonathan S. Landay, staff writer, Knight RiderNewspapers, Sacramento Bee (December 16,2004), p. 1.

8. David McCullough, The Path Between the Seas(New York: Simon & Schuster, 1977), pp. 117–118.

9. David McCullough, The Path Between the Seas(New York: Simon & Schuster, 1977), p. 235.

10. Web site for Øresundsbro Konsortiet, www.oeresundsbron.com.

11. Eberhardt Rechtin and Mark W. Maier, The Artof Systems Architecting (New York: CRC PressLLC, 1997).

12. R. Stevens, P. Brook, K. Jackson, and S. Arnold,Systems Engineering: Coping with Complexity(Hertfordshire, England: Prentice Hall Europe,1998).

13. Winston W. Royce, “Managing the Developmentof Large Software Systems,” Proceedings, IEEEWESCON (August 1970), pp. 1–9.


NOTES 437

14. B. W. Boehm, “A Spiral Model of Software Devel-opment and Enhancement,” Tutorial: System andSoftware Requirements Engineering, eds. R. H.Thayer and M. Dorfman (Washington, DC: IEEEComputer Society Press, 1990), pp. 513–527.

15. Michael Cusumano and Richard Selby, MicrosoftSecrets (New York: Simon & Schuster, 1995),p. 192.

16. Craig Larman, Applying UML and Patterns: AnIntroduction to Object-Oriented Analysis andDesign and Iterative Development, 3rd ed.(Upper Saddle River, NJ: Prentice Hall, 2005),p. 27.

17. Jim Lovell and Jeffrey Kluger, Apollo 13(New York: Pocket Books, 1994), Epilogue,pp. 372–378.

18. Kevin Forsberg, “ ‘If I Could Do That, Then ICould . . . ’: System Engineering in a Researchand Development Environment,” The Five BestPapers: Proceedings of the National Council forSystem Engineering Symposium (St. Louis, MO,July 1995).

19. Final Report of the Columbia Accident Investi-gation Board (Washington, DC: NASA, August2003); Frank Kuznik, “Blundersat,” Air & Spacemagazine (Washington, DC: Smithsonian Institu-tion, December 1993/January 1994).

20. Ben R. Rich and Leo Janos, Skunk Works(Boston: Little, Brown & Company, 1994).

CHAPTER 8

1. William G. Pagonis (with Jeffery L. Cruik-shank), Moving Mountains (Boston: HarvardBusiness School Press, 1992), pp. 185–191.

2. Stephen R. Covey, The Seven Habits of HighlyEffective People (New York: Simon & Schuster,1989).

3. Ben R. Rich and Leo Janos, Skunk Works(Boston: Little, Brown & Company, 1994).

CHAPTER 9

1. “Advertisement and Specification for a Heavier-Than-Air Flying Machine,” U.S. Army SignalCorps Specification No. 486 (Washington, DC:Smithsonian Institution, December 1907).

2. Tom D. Crouch, The Bishop’s Boys: A Life ofWilbur and Orville Wright (New York: Norton,1990), p. 347.

3. John Locke, An Essay Concerning Human Under-standing (New York: Dover Publications, 1959).

4. Cynthia Monaco, “The Difficult Birth of theTypewriter,” American Heritage of Invention &Technology (Forbes Inc., Summer 1988),pp. 10–21.

5. Clayton M. Christensen, The Innovator’sDilemma (New York: Harper Business, 2000).

6. John R. Hauser and Don Clausing, “The Houseof Quality,” Harvard Business Review (May/June 1988), pp. 63–73.L. Guinta and N. Praizler, The QFD Book: TheTeam Approach to Solving Problems and Satisfy-ing Customers through Quality Function Deploy-ment (New York: AMACOM Books, 1993).

7. Bill Gates, Business @ the Speed of Thought(New York: Warner Books, 1999).


9. Richard E. Fairley and Richard H. Thayer, “TheConcept of Operations: The Bridge from Opera-tional Requirements to Technical Specifications,”Tutorial: Software Requirements Engineering,2nd ed., eds. R. H. Thayer and M. Dorfman (LosAlamitos, CA: IEEE Computer Society Press,1997), pp. 73–83.

10. Thomas L. Saaty, “Priority Setting in ComplexProblems,” IEEE Transactions on EngineeringManagement, vol. EM-30 (August 1983).

11. Charles H. Kepner and Benjamin B. Tregoe, TheNew Rational Manager (Princeton, NJ: PrincetonResearch Press, 1981).

12. “Introduction to Unified Modeling Lan-guage (UML),” Object Management Group(OMG), 2004. Web site http:/www.omg.org/gettingstarted /what_is_uml.htm; Craig Laran,Applying UML and Patterns, An Introduction toObject-Oriented Analysis and Design and Itera-tive Development, 3rd ed. (Upper Saddle River,NJ: Prentice Hall, 2005).

13. David Oliver, Timothy P. Kelliher, and James G.Keegan Jr., Engineering Complex Systems withModels and Objects (New York: McGraw-Hill,1997).

14. Sanford A. Friedenthal and Cris Kobryn, “Ex-tending UML to Support a Systems ModelingLanguage,” INCOSE Symposium Paper (2003).


438 NOTES

CHAPTER 10

1. Henry Miller, Tropic of Capricorn (New York:Grove Press, 1961), p. 176.


3. Suzanne K. Bishop, “Cross-Functional ProjectTeams in Functionally Aligned Organizations,”Project Management Journal (Sylva, NC: Proj-ect Management Institute, September 1999),pp. 6–12.


CHAPTER 11

1. James P. Lewis, Team-Based Project Manage-ment (New York: American Management Associ-ation, 1998), p. 71.

2. James P. Lewis, Team-Based Project Manage-ment (New York: American Management Associ-ation, 1998), pp. 22–28.

3. Tom I. Peters and R. H. Waterman Jr., In Searchof Excellence (New York: Harper & Row, 1974).

4. Harold Kerzner, Project Management (New York:Van Nostrand Reinhold, 1984).

5. Ibid.6. Ibid.7. Stephen R. Covey, The Seven Habits of Highly

Effective People (New York: Simon & Schuster,1989), pp. 50–51.


CHAPTER 12

1. Project Management Institute Practice Standardfor Work Breakdown Structures (Philadelphia,PA: Project Management Institute, 2000).

2. Sunny Baker and Kim Baker, The CompleteIdiot’s Guide to Project Management (New York:Alpha Books, Simon & Schuster Macmillian,1998), pp. 97–100.

CHAPTER 13

1. J. March and Z. Shapira, “Managerial Perspec-tives on Risk and Risk Taking,” Management Sci-

ence, vol. 33, no. 11 (November 1987),pp. 13–17.

2. Rita Mulcahy, Risk Management: Tricks of theTrade for Project Managers (Minneapolis: RMCPublications, 2003), p. 68.

3. Tom Kendrick, Identifying and Managing Proj-ect Risk (New York: AMACOM, 2003).


5. Robert T. Clemen, Making Hard Decisions(Boston: PWS-Kent Publishing Co., 1991).


7. Jon Krakauer, Into Thin Air (New York: Double-day Dell, 1997).

8. Kevin Forsberg and Hal Mooz, “Risk and Oppor-tunity Management and the Project Cycle,” Pro-ceedings of the National Council for SystemEngineering Symposium (July 1995).

9. Ben R. Rich and Leo Janos, Skunk Works (Boston:Little, Brown & Co., 1994).

10. Nancy G. Leveson and Clark S. Turner, “An In-vestigation of the Therac-25 Accidents,” IEEEComputer (July 1993), pp. 18–41.

11. Ibid.12. Mikel J. Harry, “The Nature of Six Sigma Qual-

ity,” (Motorola Inc., Government ElectronicsGroup, 1987).

CHAPTER 14

1. Aviation Week & Space Technology, “NASA, In-telsat Discuss Shuttle Rescue of SatelliteStranded in Useless Orbit” (March 26, 1990).

2. Henri Fayol, General and Industrial Manage-ment (New York: IEEE Press, 1984). A transla-tion of the original French version published in1916.

3. Ibid.4. Leonard J. Kazmier, Principles of Management

(New York: McGraw-Hill, 1969), p. 309.5. Peter F. Drucker, People and Performance: The

Best of Peter Drucker on Management (NewYork: Harper & Row, 1977), p. 498.

6. Callium Kidd and Thomas Burgess, The WileyGuide to Managing Projects (Hoboken: Wiley,2004), p. 502.


NOTES 439

CHAPTER 15

1. David McCullough, The Path between the Seas(New York: Simon & Schuster, 1977), pp. 183,185.

2. Michael Doyle and David Straus, How to MakeMeetings Work (New York: Berkley Publishing,1984).

3. Bill Gates, Business @ the Speed of Thought(New York: Warner Books, 1999).

CHAPTER 16

1. Thomas Fuller, Gnomologia, Adagies andProverbs, Wise Sentences and Witty Sayings,Ancient and Modern, Foreign and British(Whitefish, MT: Kessinger Publishing, 2003).


3. Ed Jorgensen, Jake Matijevic, and RobertShisko, “Mars Pathfinder Project MicroroverFlight Experiment: Risk Management End-of-Mission Report,” Jet Propulsion Lab Report JPLD-11181-EOM (September 23, 1998).

4. Edward R. Tufte, The Visual Display of Quanti-tative Information (Cheshire, CT: GraphicsPress, 1983).

5. Edward R. Tufte, Visual Explanations (Cheshire,CT: Graphics Press, 1997), pp. 38–53.

CHAPTER 17

1. Sherry Sontag and Chistopher Drew, BlindMan’s Bluff: An Untold Story of American Sub-marine Espionage (New York: Public Affairs,Perseus Books Group, 1998), pp. 88–120.

CHAPTER 18

1. Michael Useem, The Leadership Moment (NewYork: Three Rivers Press, 1998), pp. 3, 266.


3. Stephen R. Covey, The Seven Habits of HighlyEffective People (New York: Simon & Schuster,1989), p. 147.

4. G. Gemmill, H. Thamhaim, and D. L. Wileman,“The Power Spectrum in Project Management,”Sloan Management Review, vol. 12 (Fall 1970),pp. 15–25.

5. The Wilson Learning Corporation, Eden Prairie,MN.

6. Douglas McGregor, The Human Side of Enter-prise (New York: McGraw-Hill, 1960).

7. William G. Ouchi, Theory Z: How AmericanBusiness Can Meet the Japanese Challenge(Reading, MA: Addison-Wesley, 1981).

8. Frederick Herzberg, Bernard Mausner, and Bar-bara Snyderman, The Motivation to Work (NewYork: Wiley, 1959).

9. Alfie Kohn, Punished by Rewards (Boston:Houghton Miff lin, 1993).

10. P. Hersey and K. H. Blanchard, Management ofOrganizational Behavior: Utilizing Group Re-sources (Englewood Cliffs, NJ: Prentice Hall,1993).

11. The Wilson Learning Corporation, Eden Prairie,MN.

12. Consulting Psychologists Press, Inc., Palo Alto,CA.

13. Stephen R. Covey, The Seven Habits of HighlyEffective People (New York: Simon & Schuster,1989), p. 241.

14. David Keirsey and Marilyn Bates, Please Under-stand Me, Character & Temperament Types (DelMar, CA: Prometheus Nemesis Book Company,1984).

PART FOUR

1. Don Hammonds, “Hyundai Goes from Also-Ranto Most Reliable,” Pittsburgh Post-Gazette(March 26, 2005).

2. Joann Muller and Robyn Meredith, “Last Laugh:How Hyundai’s Carmaking Prowess Went fromPunchline to Powerhouse: And Is Shaking Upthe World’s Auto Industry,” Forbes (April 18,2005).

3. John G. Spooner, “Intel’s CEO Wants an Em-ployee Attitude Check,” ZDNet News (July 27,2004).

4. Joann Muller and Robyn Meredith, “Last Laugh:How Hyundai’s Carmaking Prowess Went fromPunchline to Powerhouse and Is Shaking Up theWorld’s Auto Industry,” Forbes (April 18, 2005).

CHAPTER 19

1. Kevin Forsberg and Hal Mooz, “The Relation-ship of System Engineering to the Project


440 NOTES

Cycle,” Proceedings of the National Council forSystem Engineering Symposium (Chattanooga,TN, October 1991), pp. 57–65.

2. Craig Larman, Applying UML and Patterns: AnIntroduction to Object-Oriented Analysis andDesign and Iterative Development, 3rd ed.(Upper Saddle River, NJ: Prentice Hall, 2005).

3. B. W. Boehm, “A Spiral Model of Software Devel-opment and Enhancement,” Tutorial: System andSoftware Requirements Engineering, eds. R. H.Thayer and M. Dorfman (Washington, DC: IEEEComputer Society Press, 1990), pp. 513–527.

4. Kevin Forsberg and Hal Mooz, “Application ofthe ‘Vee’ to Incremental and Evolutionary De-velopment,” Proceedings of the National Councilfor System Engineering Symposium (St. Louis,MO, July 1995).

CHAPTER 21

1. Ben R. Rich and Leo Janos, Skunk Works(Boston: Little, Brown & Co., 1994).

2. Ibid.3. David C. Aronstein and Albert C. Piccirillo,

Have Blue and the 117A (Reston, VA: AmericanInstitute of Aeronautics and Astronautics, 1997).

4. David C. Aronstein and Albert C. Piccirillo,Have Blue and the 117A (Reston, VA: AmericanInstitute of Aeronautics and Astronautics, 1997),Appendix C.

5. Robert B. Cialdini, Inf luence, the Psychology ofPersuasion (New York: William Morrow, 1993).

6. Craig Sholes and Natalie Chalfin, “MarsPathfinder Mission,” PM Network (January1999).

7. Lewis Spacecraft Mission Failure InvestigationBoard Final Report (Washington, DC: NASAHeadquarters, February 1998).

8. Gary Kinder, Ship of Gold in the Deep Blue Sea(New York: Vintage Books, 1998).

9. Edward Yourdon, Death March (Upper SaddleRiver, NJ: Prentice Hall, 2003).

APPENDIX C

1. “Introduction to Unified Modeling Language(UML)” (Object Management Group, 2004),http://www.omg.org/gettingstarted /what_is_uml.htm.

2. David Oliver, Timothy P. Kelliher, and James G.Keegan Jr., Engineering Complex Systems withModels and Objects (New York: McGraw-Hill,1997).

3. Sanford A. Friedenthal and Cris Kobryn, “Ex-tending UML to Support a Systems ModelingLanguage,” INCOSE Symposium Paper (2003).

4. Ibid.


Acceptance testing, 160, 372Accountability, 68, 161, 184. See also AuthorityAcquisition, 94–95Acquisition cycle, 30Acquisition Preparation Phase, 93Actual cost of work performed (ACWP), 306Aerospace industry, 382Affinity diagram, 427Agile Alliance, 4–5, 15, 352, 405Agility, 15–16, 114, 140, 352–354, 378Aircraft turnaround project, WBS, 220–222Allen, Judd, 38–39Allocated requirements, 151–152American Society for the Advancement of Project

Management (ASAPM), 15Amusement park exhibits/rides, project cycle for (Figure

7.3), 88Analysis (verification method), 367Analytical hierarchy process (AHP), 427Analytical style, 335Anomalies, 114–115, 370, 379–380Anscombe’s quartet (Figure 16.9a), 302Architecture Vee. See Vee Model, ArchitectureAronstein, David, 382Arrow Diagramming Method (ADM), 211Artifacts:

automatically generated electronic documentation, 353configuration management process improvement template,

395controlling, 267, 268lessons learned as, 42roles, 120–121, 359–360

Aspects of the project cycle, 99–102. See also Project cycle(one of five essentials)

budget, 30, 31, 99, 101–102, 115–116business, 30–31, 99–101, 115–116as layers, 30technical:

development tactics, 116–119modeling, 104–108periods and, 99

systems engineering and, 102–104technology insertion, 119–120

Assembly (in system decomposition), 109Attitudes/biases, 51–53, 73Attributes/competencies, 182–183Augustine’s Law, 269Authority. See also Accountability; Responsibility:

conf lict in, 194control, 256project manager, 46–47, 183–184, 187–189project team, 184

Barrett, Craig, 340Baseline(s):

budget, 268chain of requirements, 141–142change control, 267defined, 427Eight Phase Estimating Process:

Baseline Estimate Phase, 417–418Environment Baseline Phase, 417

elaboration:artifact role, 360hierarchical /nonhierarchical (Figure 19.14), 353

management, 120–121technical, 428 (see also Technical aspect of project cycle)

Bath Iron Works in Maine, 157–158Behavior:

diagrams, 66, 164leader (Figure 18.3), 328personal, and communication styles, 51relationship, 328requirements, 151–152task, 328team, 25

Bennis, Warren, 54, 320Berlin, Irving, 381Berlo, David (SMCR Model), 49, 50, 51Best practices, 12, 387, 428“Better, faster, cheaper” (BFC), 127, 384“Better” as enemy of “good enough,” 114

441

index

cott_z08bindex.qxd 7/5/05 8:37 AM Page 441

442 INDEX

Big bang approach, 359, 364Blackhawk helicopter, 103Boehm, Barry W., 107Boeing 777, 231Booher, Dianna, 54, 57Boston Big Dig, 89, 92, 101Bottom-up incremental integration approach, 364, 365Brainstorming, 331Brittleness, 373Budget:

aspect of project cycle, 30, 31, 101–102, 115–116baseline, 268cycle, 30underruns/overruns, 314

Budget at completion (BAC), 306Budgeted cost of work performed (BCWP), 306, 307–308Budgeted cost of work scheduled (BCWS), 306, 309Budgeting Phase, Eight Phase Estimating Process, 420Build-to (Critical Design Review, CDR) gates, 243, 351Burgess, Thomas, 269Burn rate slippages, 317–318Business:

aspect of project cycle, 30–31, 99–101, 115–116baseline control, 121, 267case, 3–7, 13, 14, 110corrective actions, 316status, 293–294

Business manager/management, 190–191, 390, 432BUYER project (COTS procurement support), 248–250Buyer/seller viewpoints (Figure 11.6), 195

Candidate concepts, 152, 315Capability Maturity Model Integrated (CMMI), 11–12,

275, 387–398, 421–426collaboration, 17continuous representation, 423, 424–425Eight Phase Estimating Process and, 415Generic Goals, 424, 425Generic Practices, 394, 425glossary, 27ISO certification levels and, 41mapping to the five essentials, 396process improvement, 421–422Product Suite, 16, 404, 405representations, 422–423staged representation, 423, 425–426ten management elements and, 135

Cards-on-the-wall (COW) technique, 73, 200, 209–210,215

Career paths, 40–41Car selection criteria, 149–150Celebrations, team, 80–81

CERT Coordination Center (CERT/CC), 406Certification:

professional, 16, 40, 41, 404quality, 373system, 375, 376

Champion, project, 185Change control, 120, 267, 269–271, 353, 390. See also

Configuration managementChange Control Board (CCB), 269–270Chartering the project, 187–189Check-and-balance system, 147Chism, James, 409Christensen, Clayton, 139CMM/CMMM. See Capability Maturity Model Integrated

(CMMI)Coaching, 327Code of conduct, 74–76Code-to-decision gate (CDR), 348Collaborate to Consensus (C2C), 60Collaboration, 17–18, 53, 330Collocated matrix, 174–176Commitment to project, 200, 201Commitment to project management. See Organizational

commitment (one of five essentials)Communication, project (one of five essentials), 21, 26–27,

48–68attitudes and biases, 51–53challenge of common vocabulary, 26–27feedback, 61isolation of stovepipes/silos, 61language/vocabulary, 62–68model (Figure 5.1), 49multiplication factors, 49participants, inf luence of, 50–53personal behaviors and communication styles, 51project environment, 60–61techniques, 53–60

constructive feedback, 53, 58–60dialog, 54–55glance management, 55–56meetings/to follow-up, 58observing/listening, 56–57polling, 57–58

in Wheel and Axle Model (Figure 3.3), 24Competencies/attributes, 182–183Competency models, 131, 185, 186. See also Capability

Maturity Model Integrated (CMMI)Competitors as stakeholders, 15Complexity, planning for, 341–360, 385, 398–399Component test (WBS dictionary excerpt), 207Compromise, 330, 331Computer aids/tools, 26, 46, 163–164, 219, 290, 417Computer Resources Working Group, 274–275


INDEX 443

Concept Definition Phase, 92–93, 121, 244–245Concept of operations (CONOPS), 13, 14, 141, 434Concurrent engineering, 191–192Configuration items (CIs), 104, 300, 342, 428Configuration management, 265–271, 395. See also

Change controlConf lict resolution methods, 330Confrontation/collaboration, 330Congruency, 5, 7, 260, 266Consensus:

Collaborate to Consensus (C2C), 60decision making, 79

Constructive challenge/confrontation, 52, 330Constructive feedback, 58–60Consultants, 191Context of implementation, 149Continuous Improvement Teams, 70Continuous Quality Improvement (CQI), 272–273Continuous representation, CMMI, 423, 424–425Contract(s), 120, 168, 239, 261, 262Contractors/subcontractors, 168, 191, 199, 218Control. See Project controlControl gates. See Decision gatesCopyrights/service marks, 2Corona project, 382Corrective action, 133, 312–318

closing the control loop (Figure 17.1), 314determining, 315–316, 317evaluating alternatives by weighted scoring (Figure 17.2),

317implementing, 317–318reasons for, 312–314, 315–316, 318

Cosmai, Robert, 340Cosmetic anomalies, 379Cost:

estimating/costing/pricing, 215–219guidelines for control, 261schedules, 208status, 294, 304variances/overruns, 306, 315

Cost as an independent variable (CAIV), 12, 149Cost Performance Index (CPI), 309, 310Cost-reimbursable contracts, r isk management, 239COTS (Commercial-Off-The-Shelf ) products, 152,

162–163, 247–252, 346Covey, Stephen, 72, 130, 191, 320, 325, 330CPM, 208–209, 215. See also PERTCredibility, 181Critical Design Reviews (CDRs), 67, 97, 428Critical path:

analysis, 22defined, 211example, vacation preparation (Figure 12.14), 213

selection of, 357–359shortening, 212–213

Crosby, Phillip, 374CSEP (Certified Systems Engineering Professional), 16, 41CSE system certification, 375, 376Cultural change, farming analogy, 38–39Culture, high performance, 38–42, 354, 399Customer(s), 379

in-plant representatives, 289–290review meetings, 288

Cycle. See Project cycle (one of five essentials)

Dashboard, 207–208Data:

collection phase, Eight Phase Estimating Process,420–421

control, 262mining, 141nonstandard input /output formats, 219

Deactivation Phase, 95, 96Decisional meetings, 284Decision gates:

build-to, 243, 351business aspect, 30–31conduct /resolution, 276–277confusing titles, 66–67constructive feedback and, 59criteria for definition of, 276Critical Design Review (CDR), 351decision options (acceptable, acceptable with

reservations, unacceptable, unsalvageable), 97, 277defined, 428design-to gates, 116, 243, 351importance of, 96–98phasing of, 351–352Preliminary Design Review (PDR), 66, 116, 351in project cycle templates (Figure 7.2), 87Systems Requirements Review (SRR), 98tailoring gated cycle, 127

Decision matrix, r isk (Table 13.1), 240Decision processes, alternative (Figure 6.3), 79Decision records, opportunity/risk (Figure 13.7), 241Decision styles, 78–80, 328Decomposition Analysis and Resolution (DAR), 109,

110–114, 144–159architecture selection, 156–159Architecture Vee and (Figure 9.8), 148context of implementation, 149defining problem to be solved and establishing weighted

evaluation criteria, 149–151defining required behavior and performance, 151–152definitions, 429developing candidate logical /physical solutions, 152


444 INDEX

Decomposition Analysis and Resolution (DAR) (Continued)overview diagram (Figure 9.6), 146selecting best solution, 152–155

f low chart (Figure 9.10), 153quality function deployment (QFD), 155–156sensitivity analysis (Figure 9.11), 154study process (Figure 9.12), 155

sources/techniques for determining requirements, 147–149Decomposition levels, 109Defense. See U.S. Department of Defense (DoD)Delegating, 327, 329De Lesseps, Ferdinand, 100–101, 278Deliverables, 202, 402Delivery methods, 354, 429Deming, W. Edwards, 374Demonstrations, 367Denver Airport, 92, 98, 196, 390Deployment Phase, 95Derived requirements, 151Design:

artifacts, 395drawings, 275margin verification, 371–373reviews, 97, 111, 113, 114, 348, 351, 390, 431verification, 370–371

Design Baseline Phase, Eight Phase Estimating Process, 415Design-to gates, 116, 243, 351. See also Preliminary Design

Reviews (PDRs)Development methods:

definitions, 429evolutionary, 116, 356, 357, 407–408, 429incremental, 117, 118, 358, 364, 407–408, 429linear, 117, 118, 200, 358, 430strategy/tactics, 116–119, 200, 429unified, 112, 434

Dialog, 54–55Disk drives, evolution of, 139–140DMAIC (Define, Measure, Analyze, Improve, Control), 391Documentation. See ArtifactsDoD. See U.S. Department of Defense (DoD)Driver style, 335Drucker, Peter, 168, 260, 320Dual Vee, 349, 350, 355, 434. See also Vee ModelDynamic Data Collection Phase, Eight Phase Estimating

Process, 420–421

Earned value, 26, 133, 197, 305–308Earned Value Management (EVM) systems, 133, 305–308Einstein, Albert, 11, 19Electrical integration, 363Electronics Industries Alliance (EIA), 15, 269, 403–404, 406Emerson, Ralph Waldo, 383Engineering, systems. See Systems engineeringEngineering tests, 160

Entity development /solution, 341–352. See also Vee ModelEnvironment, project:

communication, 60–61leadership and, 323–327organizational commitment, 42–44requirements change (Figure 9.3), 143

Environmental testing, 160Environment Baseline Phase, Eight Phase Estimating

Process, 417ESL, 38Essentials of project management, five. See also specific

essentials:organizational commitment, 21, 25–26, 37–47project communication, 21, 26–27, 48–68project cycle, 22, 28–31, 84–128situational techniques/tools (ten management elements),

22, 31–33, 129–134 (see also specific elements)corrective action, 32, 133, 312–318opportunities and risks, 32, 132, 223–253organization options, 32, 33, 131, 167–180project control, 32, 132–133, 254–277project leadership, 32, 133–134, 319–337project planning, 32, 131–132, 196–222project requirements, 32, 130–131, 137–166project status, 32, 133, 292–311project team, 32, 131, 181–195project visibility, 32, 33, 133, 278–291

teamwork, 21, 27–28, 69–83Estimate at completion (EAC), 306, 307Estimated completion date (ECD), 299Estimate to complete (ETC), 306, 307Estimating:

costing/pricing process, 215–219Eight Phase Process, 415–420

Phase 1: Design Baseline Phase and Work BreakdownStructure (WBS), 415

Phase 2: Size Baseline Phase, 416Phase 3: Environment Baseline Phase, 417Phase 4: Baseline Estimate Phase, 417–418Phase 5: Project Estimate Phase, 418–419Phase 6: Risk Analysis Phase, 419–420Phase 7: Budgeting Phase, 420Phase 8: Dynamic Data Collection Phase, 420–421

Ethical / legal issues, 74–76European Commission, 264–265Evolutionary development, 116, 356, 357, 407–408, 429Evolution of typical project, 42–43Executive management review, 288Expected value (EV), 237Expenditure profile, typical (Figure 7.4), committed versus

spent, 90Expert reviews, 275–276Expressive style, 335Extreme Programming, 15, 140, 378


INDEX 445

Failure:project (reasons for), 41–42, 70–71, 123, 325–326testing:

mean time between failure (MTBF), 373unrepeatable (one-time anomalies), 370, 380 (see also

Anomalies)Failure Modes and Effects (and Criticality) Analysis

(FMEA and FMECA), 235, 429Failure review boards, 276Farming metaphor, 41Fast cycle time, 125–127Fayol, Henri, 19, 31, 32, 255Feasibility, hardware/software, 430Feedback, 53, 58–60, 61Financial management. See BudgetFirmware, 376First article testing, 160Flowcharts, 66Focus groups, 148Follower readiness, 329Forcing style (power/dominance), 330Ford, Henry, 69Ford automobiles, 127, 234, 376Forms/templates, web site for, 401–402Formality, 67–68Formal testing, 160, 369Frameworks, 11France, Anatole, 56Fuller, Thomas, 292Functional integration, 364Functional organizations, 45, 169–170

Gantt charts, 29, 211, 215Gates, control. See Decision gatesGates, Bill, 141, 290, 293Geostationary Operational Environment Satellite (weather

satellite), 126Glance Management, 55–56, 280–282Goals, 72, 166, 424, 425Government, U.S.:

Department of Defense (see U.S. Department of Defense(DoD))

Request for Proposal (RFPs), 42, 204Government Furnished Equipment, Services, and Material

(GFE), 215Government-Off-The-Shelf (GOTS), 162Graphical languages/tools, 26, 62, 66, 164. See also Systems

Modeling Language (SysML); Unified ModelingLanguage (UML)

Grove, Andy, 340Gruhl, Werner, 90–91

Hall, Rob, 241Hallucinator, 323

Hardware/software. See also Software:erroneous separation of (Figure 7.7), 106low-risk solutions, 162–163

Hardware Model Shop Development, 140Harley Davidson, 372Harris, Sydney, 56Harry, Mikel, 252Hazard analysis, 235Headcount:

report (Figure 16.7), 301variance, 287

Heating system example, 149, 152, 153, 158Heinlein, Robert A., 279Hersey situational leadership model (Figure 18.3), 328Herzberg, Frederick, 326–327Hidden enemies, 51, 387–390Historical templates, generalized, 236Home building/remodeling, 127–128, 147, 158House of Quality (quality function deployment, QFD),

140–141, 155–156, 429, 432Hubble Telescope, 159, 234, 312, 366Hyundai, 76, 339–340

Iacocca, Lee, 234IBM, 376, 382-ilities verification, 375Implementation:

context of, 149computer-based tools, 219cycle, 30planning, 198–200

Implementation Period, 94–95, 99Source Selection Phase, 94System Development Phase, 94Verification Phase, 94–95

Incremental development, 117, 118, 358, 364, 407–408,429

Informal testing, 160Informational meetings, 284, 285, 286Information center, project, 80Ingersoll-Rand air grinder, 127Inspection, 367Institute of Electrical and Electronics Engineers (IEEE),

15, 405Institute of Industrial Engineers (IIE), 15Insurance, earthquake, 223Integrated model, 19–33, 35–36

modeling integration of project management and systemsengineering, 19–20

purposes of the model, 20validation criteria, 20visualizing relationship among five essentials, 22–24Wheel and Axle Model, elaboration of, 25–31

Integrated project teams and product teams, 176–178


446 INDEX

Integration, verification, and validation (IV&V), 359,361–380

anomaly management, 379–380definitions, 361integration, 362–366risk and, 366validation, 376–378verification, 366–375

Integrity, system, 266, 433Intel Corporation, 326, 340, 382–383International Council on Systems Engineering (INCOSE),

15, 16, 20, 403–404Certified Systems Engineering Professional (CSEP)

certification program, 16current development, 25, 46, 387INCOSE Systems Engineering Handbook, 16, 36Object Oriented Systems Engineering Methodology

(OOSEM), 165, 410–411, 414overview table, 404web site, 164

International Organization for Standardization (ISO), 15, 86,87, 135, 269, 391, 406

International Project Management Association (IPMA), 15Internet, 141, 290, 313

web site for templates/forms, 401–402Interpersonal management role, 284Interpersonal Relations Model, 334–335Interpersonal traits, 330–331Intuition, 399Iridium Corporation, 3, 376ISO 9000, 391. See also International Organization for

Standardization (ISO)

Johnson, Kelly, 126, 382Jung, Carl, 181, 336

Kendrick, Tom, 232–233, 237Kepner-Tregoe Decision Analysis Methodology, 154–155,

186Kerzner, Harold, 187Kidd, Callium, 269Kile, Ray, 415, 421Kinder, Gary, 19, 385–386Kohn, Alfie, 327

Language/vocabulary, 62–68. See also Communication,project (one of five essentials)

Larman, Craig, 112, 352Leadership. See Project leadershipLearning organizations, 41, 264Legal /ethical issues, 74–76Lessons learned, 13, 14, 41–42, 236, 368–369Lewis, C. S., 85

Life cycle. See Project cycle (one of five essentials)Life testing, 160, 373Lighthouse anecdote, 324Linear development, 117, 118, 200, 358, 430Listening, 56–57Locke, John, 138Lockheed, 126, 131, 167, 168, 382, 383Logical integration, 364Love Canal, 96Lowest-configuration item (LCI), 102, 109, 342, 344, 345, 430Lowest replaceable unit (LRU), 104, 342

Macro level of project management, 225Malinowski, Len, 69Management:

executive, role of, 39–40executive management review, 288versus leadership, 320proactive, versus lip service, 39–40styles, 79 (see also Project leadership, styles)

Management by objectives (MBOs), 193, 262–263, 273, 326Management-by-walking-(or wandering)-around (MBWA),

56, 133, 281–282Management elements, ten, 22, 31–33, 129–134. See also

specific element:corrective action, 32, 133, 312–318opportunities and risks, 32, 132, 223–253organization options, 32, 33, 131, 167–180project control, 32, 132–133, 254–277project leadership, 32, 133–134, 319–337project planning, 32, 131–132, 196–222project requirements, 32, 130–131, 137–166project status, 32, 133, 292–311project team, 32, 131, 181–195project visibility, 32, 33, 133, 278–291

Management Methods Survey (Figure 21.3), 389Management /project information center, 80Management surveys, 263–264, 389, 390Manager. See Project managerMargin, qualification testing with, 160Margin management, 295–298Marketplace dynamics, 4–5, 192–193Maslow’s needs hierarchy, 330Material shortage list (Figure 16.6), 301Matrix organization, 169

collocated, 174–176conventional, 172–174, 176management operations, 179, 180typical (Figure 4.3), 44

Maturity Levels, 392, 425–426. See also Capability MaturityModel Integrated (CMMI)

McGregor, Douglas, 323–324Mean time between failure (MTBF), 373Measurement units, 368


INDEX 447

Mechanical integration, 363Meetings, 58, 77–78, 284–288, 326Micromanagement, 263–265Microsoft, 33, 87, 107, 141, 164, 252, 293, 356Milestone reports (Figures 16.3, 16.4), 299Military resource deployment, 173Miller, Henry, 167, 320Mission Compromised, 379Model(s):

definitions, 11, 430–431feasibility, hardware/software, 430five essentials, 19–33integrated, 19–33, 35–36

mastering complex systems with, 1–2project and systems engineering, 19–20purposes, 20validation criteria, 20visualizing relationship among five essentials, 22–24

Spiral (see Spiral Model)Vee (see Vee Model)visualizing the project environment, 8–18Waterfall (see Waterfall Model)Wheel and Axle (see Wheel and Axle Model)

Modeling language. See Systems Modeling Language(SysML)

Monte Carlo methods, 209, 236–237, 419, 431Motivation:

factors, positive/negative (motivational /maintenance),327

process improvement and, 392techniques of project leadership, 322–333

coaching, 327creating the environment, 323–327delegation, 327interpersonal traits, 330–331reinforcement, 331rewarding achievement, 332–333setting example, 331–332supervision maturity, 327–333training, 333vision, 322–323

Mt. Everest expedition (1996), 241Mulcahy, Rita, 230, 233Murray, James, 65Musts/wants (exercise), 166Myers-Briggs model, 336

N2 diagram, 362–363, 431NASA:

Apollo 13 disaster, 113cycle, 86, 87“faster, better, cheaper,” 100Lewis spacecraft, 384Mars Climate Orbiter, 276

Mars Pathfinder, 297, 384Microrover System, 297, 298Space Shuttle, 48, 51, 57–58, 60–61, 65, 74, 90–91, 113,

234, 281, 312, 390space station, 96, 101Study Period as percent of development cost (Figure 7.5),

91technology insertion projects, 126

NDI (Nondevelopment Items), 162, 247–252. See also COTS(Commercial-Off-The-Shelf ) products

Needs analysis, 412–413Negative personal biases, 51Network, project, 22, 126, 200, 208–214Nietzsche, Friedrich, 57Nit Management, 264Nondevelopment-Items (NDIs), 162, 247–252Nth article testing, 160

Oakland-San Francisco Bay Bridge, 89, 92Objectives/process/drivers, overview (Figure 12.3), 199Object Management Group (OMG), 141, 165–166, 410. See

also Unified Modeling Language (UML)Object Oriented (OO) approach, 410Object Oriented Systems Engineering Methodology

(OOSEM), 165, 410–411, 414Off-core studies, 110, 243Oliver, David, 164–165, 410Olympics, 122One-time anomalies or failures, 370, 380Operations, artifacts’ role in, 360Operations Period, 95–96, 99Opportunities/risks, 16–18, 32, 132, 223–253

agility and, 353causative and preventive actions, 238–239contingent actions, 238–239COTS/NDI, 247–252critical path and, 212Eight Phase Estimating Process, Risk Analysis Phase,

419–420identification of risks, 223, 230–236integration/verification, and risk philosophy, 366levels (macro/tactical), 225–226management of opportunity and risk actions (Figure

13.6), 238objectives:

opportunity management (Figure 13.1), 228risk management (Figure 13.2), 229

paradigm shift (gradual) in risk management, 223planning, 200, 239–240probability/impact assessment, 236–239product risk areas, 233–234project cycle and, 240–247project-value-driven opportunity and risk management,

226–230


448 INDEX

Opportunities/risks (Continued)requirements management and risk philosophy, 150–151risk decision, 151, 240solution, r isks of/to/by the, 233–234strategies:

for negative risks (avoid, transfer, mitigate), 239for positive risks (exploit /share/enhance), 239

Orchestra /musicians metaphor, 1–2, 20, 21, 26, 71, 181Øresund Bridge-Tunnel project, 93, 101Organization, defined, 168Organizational commitment (one of five essentials), 21,

25–26, 37–47career paths, 40–41culture, 25, 38–42executive management role, 39–40interpersonal relationships, 25learning organizations, getting to the ultimate “why,” 41lessons learned, 41–42project environment, 42–44project resources, 45–47staffing, 42team behavior, 25in Wheel and Axle Model (Figure 3.3), 24

Organizational isolation, 61Organizational position, and leadership, 321–322Organization options, 33, 131, 167–180

functional, 169–171, 176guidelines for simple projects and subprojects, 176integrated project teams and integrated product teams,

176–178matrix, 169

collocated, 174–176conventional, 172–174, 176management operations, 179, 180typical (Figure 4.3), 44

project, pure, 171–172, 176, 177strengths/weaknesses of common structures, 170, 171,

172, 174, 175symptoms of inappropriate organization, 178systems engineer and, 179

Ouchi, William, 324Outsourcing, 191

Pagonis, William G., 129Panama Canal, 92, 100–101, 129, 278Parametric estimating models, 418–419Parker, Chance, 340Participating leadership style, 329Peer reviews, 60, 251, 275–276Performance improvement, 381–399

case study (Ship of Gold in the Deep Blue Sea), 385–386

complexity made simple, 399cost performance, 381–382hidden enemies, exposing, 51, 387–390

institutionalizing best practices, 387mapping CMMI to the five essentials, 396motivation, 392overcoming “band-aid” approach, 393–394payoff, 18planning, improving accuracy of, 385, 386–387process improvement, 390–398schedule performance, 381–382sustaining, 387–390, 396–397, 399technical performance, 381

Performance measurement systems, 302–304. See alsoEarned value

Periods. See Project cycle (one of five essentials)Personal behaviors and communication styles, 51Personnel schedules, 208PERT, 29, 208–209, 215, 416Phases. See Estimating, Eight Phase Process; Project cycle

(one of five essentials)Planning. See Project planningPlan-violator meetings, 287PMBOK Guide (Project Management Institute’s A Guide

to the Project Management Body of Knowledge), 2, 12, 20, 36, 404

PMI. See Project Management Institute (PMI)PMP. See Project Management Professional (PMP)Polling techniques, 57–58Post-It Notes, 376Precedence Diagramming Method (PDM), 211Preliminary Design Reviews (PDRs), 66–67, 97, 111, 113,

114, 348Previously Developed Products, 162Pricing, 215–219Prioritization, 149Proactive style:

control, 32, 260, 277glance management, 55–56management, 39–40, 334prioritization, 149

Probability, assessing, 236–239Problem solving and commitment (Figure 12.4), 201Process:

as freedom, 339improvement, 390–398

Product(s):artifacts, 395planning, 200Project Product List Fact Sheets (PPLFS), 202, 204, 432Project Products List (PPL), 202, 203, 432

Product Breakdown Structure (PBS), 157, 158, 362–364Production Phase, 96Productivity improvement, 18Professional societies, 15, 403–405Project(s):

evolution, typical, 42–43facilities, 123


INDEX 449

failure, causes of, 41–42, 70–71, 123, 325–326production, 122research and development, 123“suicide run,” 5–6system development, 122system integration, 122tree analogy, 43–44types, 122–123

Project business management, 390, 432Project control, 32, 132–133, 254–277

configuration management and change control, 265–271

corrective action closing the control loop (Figure 17.1), 314

decision gates, conduct /resolution of, 276–277defined, 255elements common to all control systems, 255–256level of, 259–261proactive/reactive, 32, 260, 277process control, 255–258requirements, 260resistance to control systems, reasons for, 259self-control, 262techniques, 261–265

quality, 271–273technical, 261, 274–276

variance control (Figure 14.2), 257, 258Project coordinators, 289Project cycle (one of five essentials), 22, 28–31,

84–128amusement park exhibits and rides (Figure 7.3), 88aspects, 30–31, 99–102as axle (Figure 3.2), 23, 24baseline management, 120–121baseline template, 91budget aspect, 30, 31, 99, 101–102, 115–116business aspect, 30–31, 99–101, 115–116decision gates, importance of, 96–98defined, 22, 85format, 29, 85graph (Figure 3.4), 28names for, 30network and (Figure 7.16), 126opportunities/risks and, 240–247Period 1: Study Period, 89–93, 99

Acquisition Preparation Phase, 93Concept Definition Phase, 92–93expenditure profile, typical (Figure 7.4), committed

versus spent, 90System Specification Definition Phase, 93User Requirements Definition Phase, 92

Period 2: Implementation Period, 94–95, 99Source Selection Phase, 94System Development Phase, 94Verification Phase, 94–95

Period 3: Operations Period, 95–96, 99shortening, 125–127tailoring (steps/techniques), 122–125technical aspect, 99, 102–108

development tactics, 116–119modeling, 104–108systems engineering and, 102–104technology insertion, 119–120

templates (Figure 7.2), 87in Wheel and Axle Model (Figure 3.3), 24

Project Estimate Phase, Eight Phase Estimating Process,418–419

Project Information Center, 80, 282–283Project leadership, 24, 133–134, 185, 290–291, 319–337

inf luence categories, 321management versus leadership, 320motivational techniques, 322–333principles (Useem), 319project manager, 185 (see also Project manager)right-brain activity, 320styles, 329, 333–337visibility and, 290–291vision and, 320–323

Project management. See also Project manager:adversarial, 69defined, 6macro level, 225survey on perception of importance of, 390systems engineering, interdependency with, 6–7

Project Management Institute (PMI), 15, 16, 403, 404certification, 16, 41, 404Organizational Project Management Maturity Model

(OPM3), 387overview table, 404Project Management Body Of Knowledge (PMBOK

Guide), 2, 12, 20, 36, 404Project Management Professional (PMP), 16, 41, 404Project manager:

accountability, 184authority, 46–47, 183–184, 187–189as buyer of services provided by support managers, 195competency model (Table 11.1), 185, 186leadership, and personal factors, 321operating style, 334organization options and, 168–169professional certification of, 16responsibilities, 77, 168–169, 183–184selecting, 185–187technique versus styles, 334weekly review, 287–288

Project network, 22, 126, 200, 208–214Project office triad, 190Project opportunity cycle, 30Project organization, pure, 171–172. See also Organization

options


450 INDEX

Project performance. See Performance improvementProject planning, 131–132, 196–222

commitments, 200configuration management process improvement

template, 395dashboard, WBS tasks and, 207–208defined, 196deliverables, determining, 202development strategy and tactics, 200elements/process/techniques (Table 12.1), 200estimating, costing, pricing, 215–219exercise (WBS for aircraft turnaround project), 220–222implementation, 198–200improving, 386–387network /schedules, developing, 200, 208–214opportunity/risk tactics, 200, 239–240overview, objectives/process/drivers (Figure 12.3), 199payoff, 218process, 199–202products, 200resources, 200, 214–215schedules, 200, 208–214statusing and, 197survey on perceived importance of, 390tasks, 200, 202–207 (see also Work Breakdown Structure

(WBS))teamwork, 78total project plan consisting of multiple plans (Figure

12.1), 197updating/maintaining the plan, 219

Project Product List Fact Sheets (PPLFS), 202, 204, 432Project Products List (PPL), 202, 203, 432Project requirements, 32, 130–131, 137–166

accountability, 161artifacts, 395chain of requirements baselines, 141–142as critical issue, 3–7Decomposition Analysis and Resolution (DAR), 109,

110–114, 144–159derived, 151potential for low-risk hardware and software solutions,

162–163requirements management, 3–7, 142–143

chain of requirements baselines (Figure 9.2), 142complexity, 143, 144defined, 7importance of, 3–7intersection of project management and systems

engineering, 6–7marketplace dynamics demanding

responsiveness/agility, 4–5project cycle and, 142–143project management and, 5–7

project success and, 5requirements change and compliance management

(Figure 9.2), 142requirements change environment (Figure 9.3), 143tools, 163–164

requirements modeling language, 164–166 (see alsoSystems Modeling Language (SysML))

simultaneous discovery (requirements/solutions), 140system solutions and, 143–146terminology/definitions, 65, 433to-be-determined and to-be-resolved, 161–162traceability, 161, 368, 390, 433users/developers converging, 140–141Vee Model and, 143–146verification analysis and resolution (VAR) process, 144,

147, 159–160Project status, 32, 133, 292–311

agenda checklist (Figure 16.1), 296business, 293–294Configuration Item Status Report (Figure 16.5), 300cost, 294determining, 298–301earned value and planning, 305–308evaluating, 295headcount variance report (Figure 16.7), 301Material Shortage list (Figure 16.6), 301meetings, 395milestone reports, 299performance measurement systems, 302–304report example (Figure 16.15), 311reviews, major, 294–295schedule, 294technical, 293–294, 295–298terminology, 26–27, 197, 313Top Ten Problem Summary (Figure 16.8), 302trend interpretation, 308–311

Project /system integrity, 266, 433Project team, 32, 131, 181–195. See also Teamwork (one

of five essentials)attributes and competencies, 182–183chartering the project, 187–189concurrent engineering, importance of, 191–192managing major interfaces and interrelationships, 192–194matrix functions chart (Figure 11.5), 193project manager (see Project manager)staffing, 189–191

business manager, 190–191project office triad (Figure 11.3), 190systems engineer/technical manager, 189–190

Project visibility, 33, 133, 278–291decomposition (Figure 15.1), 279glance management, 280–282leadership and, 290–291


INDEX 451

meetings, 284–288 (see also Meetings)Project Information Center, 282–283techniques for enhancing, 288–290Tiger Teams, 283–284 (see also Tiger Teams)tools/devices, 290

Project Work Authorizing Agreements (PWAA), 194, 198,200, 218–219, 262–263, 271

Qualification, 65, 160, 373, 432Quality as process, 374Quality assurance (QA), 74, 271–272Quality controls and techniques, 271–273Quality function deployment (QFD), 140–141, 155–156, 432Quality verification, 372, 374. See also VerificationQuebin, Nido, 381

Recycling considerations, 96Redline limits, 368Red Teams, 51, 60, 70, 390, 432Regulatory bodies and standards organizations, 406–408. See

also Electronics Industries Alliance (EIA);International Organization for Standardization (ISO);U.S. Department of Defense (DoD)

Reinforcement, 81, 331Relationship behavior, 328Reliability testing/verification, 160, 373Replication and repair (artifact role), 360Request for Proposals (RFPs), 42, 64, 204Requirements. See Project requirementsRequirements Traceability and Verification Matrix (RTVM),

161, 368, 433Resources, project, 45–47

leveling and optimization, 213–214planning, 200, 214–215, 217

Respect, 72–73Responsibility. See also Accountability; Authority:

confusion of, 178matrix (Figure 12.17), 215, 217team, 184

REVIC parametric cost estimating model, 415Review(s):

artifacts, 395customer, 288design, 97, 111, 113, 114, 348, 351, 390, 431executive management, 288expert, 275–276failure review boards, 276meetings, 288peer, 60, 251, 275–276Red Team, 60status, 294–295System Concept Review, 67Systems Requirements Review (SRR), 98

test readiness, 369Tiger Team, 316weekly, project manager ’s, 287–288

Rewards/penalties, 76, 81, 321, 332–333Right-brain activity (leadership), 320Risk(s):

management (see Opportunities/risks)project types characterized by, 123

Risk Analysis Phase, Eight Phase Estimating Process,419–420

Role biases, 73Roles, clarifying, 194. See also ResponsibilityRoyce, Winston W., 106Rusk, Dean, 57Ruskin, John, 278

Sales channels as stakeholders, 15Sales/Support Phase, 95, 96San Francisco Bay Bridge, 89, 92, 149Scenario planning, 235–236Schedule(s):

compression/expansion effects (Figure 12.15), 214control, guidelines for, 261corrective action, 315–316, 318performance, 381–382planning, 200, 208–214status determination, 294, 298–301, 309variances/overruns, 306, 315–316, 318

Schedule Performance Index (SPI), 309, 310Scope, 65, 433Scorpion submarine, 234, 312–313SEI-CMMI. See Capability Maturity Model Integrated

(CMMI)Self-control, 262Selling leadership style, 329Sensitivity analysis, 154Shaw, George Bernard, 48Shedd, William, 223Shelfware, 361–362, 376Shimano American Corporation, 313Ship building industry, 157Ship of Gold in the Deep Blue Sea (Kinder), 19, 385–386Silos, 61Situational tools/techniques. See Management elements, tenSix Sigma, 135, 391, 433Size Baseline Phase, Eight Phase Estimating Process, 416Size of project, and success/failure, 123Skunk works, 126, 131, 167, 382, 383, 433SMCR (source/message/channel /receiver) model, 49, 50, 51Smoothing, 330Software:

brittleness, 373control, 273, 274–275


452 INDEX

Software (Continued)development, cost and estimating process, 386–387erroneous separation from hardware events (Figure 7.7), 106fault tolerance, 373quality verification, 374tools, 417 (see also Computer aids/tools)

Software Capability Maturity Model (SW-CMM), 16, 405Software Engineering Institute (SEI), 15, 16, 403, 404, 405,

406. See also Capability Maturity Model Integrated(CMMI)

Software Quality Assurance (SQA), 273Solar radiation and stock prices (Figure 16.9c), 303Solution(s):

entity, 341–352initiation (Figure 7.13a), 117risks by, 234risks of, 233–234risks to, 233space shrinking to trade space (Figure 2.5), 12, 13system, 9, 143–146

Solution trade space, 10–12Source Selection Phase (Implementation Period, project

cycle), 94Space shuttle. See NASASpecification owner, roles (Figure 20.9), 379Spiral development approach, 95, 407–408, 433Spiral Model, 108, 354, 355, 433

annotated (Figure 13.10), 245complexity chapter, 354, 355–356Figure 7.9, 108overlaid on the Vee (Figure 13.11), 246project cycle and, 107–108risk and, 245, 246–248, 348, 355Vee versus, 348 (see also Vee Model)

Staffing, 189–191Staged representation, 423, 425–426Stakeholder(s):

defined, 433diverging interests of, 6–7identifying, 12–15inf luence, and concurrent engineering, 192teamwork among, 27–28types, 14–15

Standards:professional environment, 403–405project environment boundaries (Figures 2.4, 2.5), 13, 14regulatory bodies and standards organizations, 406–408

Star Wars initiative, 243Status/statusing (terminology), 26–27, 197, 313. See also

Project statusStillman, Rona, 106Stovepipes, 61Structure. See Organization options; Work Breakdown

Structure (WBS)

Study Period, 89–93, 99Styles, leadership, 329, 333–337Subcontractors, 168, 191, 199, 218“Suicide run,” 5–6Superior team development inventory (STDI), 82Supervision maturity, 327–333Suppliers, 379Support, pure, 170, 171Surveys:

management, 263–264, 389, 390users, 148

SysML. See Systems Modeling Language (SysML)System concept of operations (CONOPS). See Concept of

operations (CONOPS)System Concept Review, 67System Development Phase, 94System integrity, 266, 433Systems engineering, 6–7

certification (CSEP), 16, 41defined, 6–7versus design engineering, 103failures, examples, 103integration with project management and process, 18organization options and, 179staffing (systems engineer/technical manager), 189–190survey results, 390technical aspect, importance to, 102–104

Systems Engineering Capability Model, 404. See alsoCapability Maturity Model Integrated (CMMI)

Systems Engineering Domain Special Interest Group (SEDSIG/SEDESIG), 166, 411–412

Systems Engineering Modeling Language. See SystemsModeling Language (SysML)

Systems Engineering Society of Australia (SESA), 15Systems Modeling Language (SysML), 62, 66, 141, 165–166,

411–412, 414, 434System solutions, 9, 143–146System Specification Definition Phase, Study Period, 93Systems Requirements Review (SRR), 98Systems thinking, 8–10, 398

Tailoring the project cycle, 122–125. See also Project cycle(one of five essentials)

Task behavior, 328Task descriptions, 207Task planning, 200, 202–209, 212, 307–308Task Responsibility Matrix (Figure 12.17), 215, 217Taur, Roger, 3Taylor, Chris, 95Teamwork (one of five essentials), 21, 69–83. See also

Project teamcelebrations/events, 80–81code of conduct, 74–76decision process/style, 78–80


INDEX 453

definitions, 20–21failure, reasons for, 70–71fundamentals of effective environment for, 71–77goals, 72indicators, positive/negative, 81–82kick-off meeting, 77–78orchestra /musicians metaphor, 1–2, 20, 21, 26, 71, 181planning and problem solving, 78project information center, 80reinforcement, 81rewarding achievement, 76, 81, 332–333steps (three) for achieving, 70team spirit and energy, 76–77techniques for building/sustaining, 77–88training, 81underperformers, 80in Wheel and Axle Model (Figure 3.3), 24

Technical aspect of project cycle, 30, 31for COTS and NDI components (Figure 13.13), 248defined, 434modeling, 104–116

circular model (Figure 7.6), 105Spiral Model, 107, 108, 354, 355–356 (see also Spiral

Model)Vee Models, 108–116, 354 (see also Vee Model)Waterfall Model, 106, 107, 354, 355–356

off-core opportunity and risk investigations (Figure 13.9),244

systems engineering and, 102–104technology insertion, 119–120

Technical baselines, 121, 267, 268Technical controls, 261, 274–276Technical development tactics, 116–119, 354–357. See also

Development methodsTechnical Performance Measurements (TPMs), 133, 295,

297, 381Technical shortcomings, corrective actions, 316Technical status, 293–294, 295–298Technology:

insertion (project cycle), 119–120language and trend toward emerging specialties, 26, 63visibility, 290

Telecommuting, 168Templates/forms, web site for, 401–402Ten management elements. See Management elements, tenTerminology baseline/database, 64, 65Testing, 367–368Test readiness review, 369Thamhain, Hans, 321Theory X /Y/Z, 323–325Therac-25 project, 250–252Thompson, Tommy, 386Threaded appropriate, 359, 364, 365Tiger Teams, 70, 283–284, 316, 318

Time, fast cycle, 125–127Time-off incentives, 332Time-phased networks, 211. See also Network, projectTime-phased resource requirements, 215To Be Determined (TBD), 161–162To Be Resolved (TBR), 161–162Tools/devices, 26, 46, 163–164, 219, 290Toothbrush, technical project cycle tailored for (Figure

7.15), 122Top-down incremental integration approach, 364, 365Top Ten Problem List, 288–289, 302Total Quality Management (TQM), 272–273Toys, hazards in, 313Traceability, requirements, 161, 368, 390, 417, 433Trade-off area, 9Trade-off studies, 10–12Trade space, 9Training, 81, 333, 388, 417Tree analogy, 43–44Trend interpretation, 308–311Tufte, Edward R., 304Typewriter/word processor, 138–139

Underperformers, 80Unified development, 112, 434Unified Modeling Language (UML), 26, 62, 66, 164–165,

352, 409–414, 434Unified Process, 112Unilateral decision making, 79Universities, and business/engineering, 16–17U.S. Department of Defense (DoD):

acquisition programs, project spans for (Figure 21.1),383

chartering SEI-CMM, 393, 421Defense Acquisition System Directive, 407project cycle, 86, 87, 88, 105standards, 15, 105, 204, 384, 406–408

Useem, Michael, 319, 320User(s):

developers converging with, 140–141reliance on wrong ones, 139types of, 378

User concept of operations. See Concept of operations(CONOPS)

User Requirements Definition Phase, 92, 242, 244User Requirements Document (URD), 141

Validation:criteria for integrated project management model, 20definitions, 64, 114, 434in-process, 352–354, 377versus verification, 114 (see also Verification)

Value-Added Tax (VAT), 101Vaporware, 388


454 INDEX

Variance(s):control, 257, 258corrective actions for, 312–314cost, 306headcount, 287, 301indication, 256performance measurement systems quantifying

seriousness of, 302–304schedule, 306

Vee Model, 108–116, 143–160agile development practicing in-process validation, 352–354Architecture, 109, 145, 341, 342business and budget aspects and, 115–116COTS and NDI and (Figure 13.12), 247Decomposition Analysis and Resolution (DAR), 109,

110–114, 144, 146–159Dual, 349, 350, 355, 434engineering processes and, 396–398Entity, 341–352five-essentials model and use of, 398opportunities/risks and, 241, 247requirements development, sequential facet of, 143–146system integration and verification, 114–115technical aspect of project cycle and, 108–116Verification Analysis and Resolution (VAR) process, 144,

145, 147, 159–160Velocity/adaptability, 352Vendors, 191Verification, 366–375

analysis method, 367artifacts’ role in, 360certification, 375, 376demonstration method, 367design, 370–371design margin (qualification), 371–373-ilities, 375inspection, 367lessons learned from past experience, 368–369methods, 367qualification certification, 373qualification testing, 160quality, 374testing, 160, 367–368

acceptance, 160, 372engineering, 160

environmental, 160first article, 160formal /informal, 160life, 160, 373Nth article, 160qualification, 160reliability, 160, 373

validation versus, 63Verification Analysis and Resolution (VAR) process, 144,

145, 147, 159–160Verification Phase, Implementation Period, 94–95Virtual teams, 168Visibility. See Project visibilityVision, 320–323Vocabulary, 26–27, 35. See also Communication, project (one

of five essentials)

Wall displays, 289Walt Disney Imagineering, 88Waterfall Model, 106, 108, 109, 354, 355–356, 434

Figure 7.8, 107Weighted evaluation/scoring, 149–155, 237, 317Welch, Jack, 59Wetware, 210Wheel and Axle Model, 19–33

axle (Figure 3.2), 24 (see also Project cycle (one of fiveessentials))

base and wheel and axle (Figure 3.3), 24 (see alsoEssentials of project management, five)

elaboration of, 25–31spokes (Figure 3.1), 23 (see also Management elements,

ten)Wilson Learning Corporation, 321, 334–335Windows, evolution of, 356Withdrawal (denial /retreating), 330Womach, James, 38Work authorizing agreements, 193, 207. See also Project

Work Authorizing Agreements (PWAAs)Work Breakdown Structure (WBS), 22, 191, 202–214, 216,

263, 364, 415Work packages, 207Wright Brothers, 137–138

Yourdon, Edward, 393
