Case study

List of Cases by Chapter

Chapter 1 Development Projects in Lagos, Nigeria 2 “Throwing Good Money after Bad”: the BBC’s

Digital Media Initiative 10 MegaTech, Inc. 29 The IT Department at Hamelin Hospital 30 Disney’s Expedition Everest 31 Rescue of Chilean Miners 32

Chapter 2 Tesla’s $5 Billion Gamble 37 Electronic Arts and the Power of Strong Culture

in Design Teams 64 Rolls-Royce Corporation 67 Classic Case: Paradise Lost—The Xerox Alto 68 Project Task Estimation and the Culture of “Gotcha!” 69 Widgets ’R Us 70

Chapter 3 Project Selection Procedures: A Cross-Industry

Sampler 77 Project Selection and Screening at GE: The Tollgate

Process 97 Keflavik Paper Company 111 Project Selection at Nova Western, Inc. 112

Chapter 4 Leading by Example for the London Olympics—

Sir John Armitt 116 Dr. Elattuvalapil Sreedharan, India’s Project

Management Guru 126 The Challenge of Managing Internationally 133 In Search of Effective Project Managers 137 Finding the Emotional Intelligence to Be a Real Leader 137 Problems with John 138

Chapter 5 “We look like fools.”—Oregon’s Failed Rollout

of Its ObamacareWeb Site 145 Statements of Work: Then and Now 151 Defining a Project Work Package 163 Boeing’s Virtual Fence 172 California’s High-Speed Rail Project 173 Project Management at 175 The Expeditionary Fighting Vehicle 176

Chapter 6 Engineers Without Borders: Project Teams Impacting

Lives 187 Tele-Immersion Technology Eases the Use of Virtual

Teams 203 Columbus Instruments 215 The Bean Counter and the Cowboy 216 Johnson & Rogers Software Engineering, Inc. 217

Chapter 7 The Building that Melted Cars 224 Bank of America Completely Misjudges Its Customers 230 Collapse of Shanghai Apartment Building 239 Classic Case: de Havilland’s Falling Comet 245 The Spanish Navy Pays Nearly $3 Billion for a Submarine

That Will Sink Like a Stone 248 Classic Case: Tacoma Narrows Suspension Bridge 249

Chapter 8 Sochi Olympics—What’s the Cost of National

Prestige? 257 The Hidden Costs of Infrastructure Projects—The Case

of Building Dams 286 Boston’s Central Artery/Tunnel Project 288

Chapter 9 After 20 Years and More Than $50 Billion, Oil is No Closer

to the Surface: The Caspian Kashagan Project 297

Chapter 10 Enlarging the Panama Canal 331 Project Scheduling at Blanque Cheque Construction (A) 360 Project Scheduling at Blanque Cheque Construction (B) 360

Chapter 11 Developing Projects Through Kickstarter—Do Delivery

Dates Mean Anything? 367 Eli Lilly Pharmaceuticals and Its Commitment to Critical

Chain Project Management 385 It’s an Agile World 396 Ramstein Products, Inc. 397

Chapter 12 Hong Kong Connects to the World’s Longest Natural

Gas Pipeline 401 The Problems of Multitasking 427

Chapter 13 New York City’s CityTime Project 432 Earned Value at Northrop Grumman 451 The IT Department at Kimble College 463 The Superconducting Supercollider 464 Boeing’s 787 Dreamliner: Failure to Launch 465

Chapter 14 Duke Energy and Its Cancelled Levy County Nuclear

Power Plant 478 Aftermath of a “Feeding Frenzy”: Dubai and Cancelled

Construction Projects 490 New Jersey Kills Hudson River Tunnel Project 497 The Project That Wouldn’t Die 499 The Navy Scraps Development of Its Showpiece

Warship—Until the Next Bad Idea 500

Project ManageMent achieving coMPetitive advantage

Jeffrey K. Pinto Pennsylvania State University

Boston Columbus Indianapolis New York San Francisco Hoboken Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto Delhi

Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo

F o u r t h E d i t i o n

To Mary Beth, my wife, with the most profound thanks and love for her unwavering support. And, to our children, Emily, AJ, and Joseph—three “projects” that are definitely

over budget but that are performing far better than I could have hoped!

VP, Product Management: Donna Battista Editor-in-Chief: Stephanie Wall Acquisitions Editor: Dan Tylman Program Manager Team Lead: Ashley Santora Program Manager: Claudia Fernandes Editorial Assistant: Linda Albelli VP, Marketing: Maggie Moylan Product Marketing Manager: Anne Fahlgren Field Marketing Manager: Lenny Raper Strategic Marketing Manager: Erin Gardner Project Manager Team Lead: Judy Leale Project Manager: Nicole Suddeth Operations Specialist: Carol Melville Cover Designer: Lumina Datamatics, Inc Cover Photo: f11photo/Fotolia

VP, Director of Digital Strategy & Assessment: Paul Gentile Manager of Learning Applications: Paul Deluca Digital Editor: Brian Surette Digital Studio Manager: Diane Lombardo Digital Studio Project Manager: Robin Lazrus Digital Studio Project Manager: Alana Coles Digital Studio Project Manager: Monique Lawrence Digital Studio Project Manager: Regina DaSilva Full-Service Project Management and Composition: Integra Printer/Binder: Edwards Brothers Cover Printer: Phoenix Color/Hagerstown Text Font: 10/12 Palatino

Credits and acknowledgments borrowed from other sources and reproduced, with permission, in this textbook appear on the appropriate page within text.

Microsoft and/or its respective suppliers make no representations about the suitability of the information contained in the documents and related graphics published as part of the services for any purpose. All such documents and related graphics are provided “as is” without warranty of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information, including all warranties and conditions of merchantability, whether express, implied or statutory, fitness for a particular purpose, title and non-infringement. In no event shall Microsoft and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of information available from the services. The documents and related graphics contained herein could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Microsoft and/or its respective suppliers may make improvements and/or changes in the product(s) and/or the program(s) described herein at any time. Partial screen shots may be viewed in full within the software version specified.

Microsoft® Windows®, and Microsoft Office® are registered trademarks of the Microsoft Corporation in the U.S.A. and other countries. This book is not sponsored or endorsed by or affiliated with the Microsoft Corporation.

Copyright © 2016, 2013, 2010, 2007 by Pearson Education, Inc. All rights reserved. Manufactured in the United States of America. This publication is protected by Copyright, and permission should be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, request forms and the appropriate contacts within the Pearson Education Global Rights & Permissions department, please visit

Many of the designations by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Library of Congress Cataloging-in-Publication Data

Pinto, Jeffrey K. Project management : achieving competitive advantage/Jeffrey K. Pinto.—Fourth edition. pages cm Includes index. ISBN 978-0-13-379807-4 (alk. paper)—ISBN 0-13-379807-0 (alk. paper) 1. Project management. I. Title. HD69.P75P5498 2016 658.4'04—dc23 2014036595

10 9 8 7 6 5 4 3 2 1

ISBN 10: 0-13-379807-0 ISBN 13: 978-0-13-379807-4



Preface xiii

Chapter 1 Introduction: Why Project Management? 1

Chapter 2 The Organizational Context: Strategy, Structure, and Culture 36

Chapter 3 Project Selection and Portfolio Management 76

Chapter 4 Leadership and the Project Manager 115

Chapter 5 Scope Management 144

Chapter 6 Project Team Building, Conflict, and Negotiation 186

Chapter 7 Risk Management 223

Chapter 8 Cost Estimation and Budgeting 256

Chapter 9 Project Scheduling: Networks, Duration Estimation, and Critical Path 296

Chapter 10 Project Scheduling: Lagging, Crashing, and Activity Networks 330

Chapter 11 Advanced Topics in Planning and Scheduling: Agile and Critical Chain 366

Chapter 12 Resource Management 400

Chapter 13 Project Evaluation and Control 431

Chapter 14 Project Closeout and Termination 477

Appendix A The Cumulative Standard Normal Distribution 509

Appendix B Tutorial for MS Project 2013 510

Appendix C Project Plan Template 520

Glossary 524

Company Index 534

Name Index 535

Subject Index 538



Preface xiii

Chapter 1 IntroduCtIon: Why ProjeCt ManageMent? 1 Project Profile: Development Projects in Lagos, Nigeria 2

Introduction 4

1.1 What Is a Project? 5 General Project Characteristics 6

1.2 Why Are Projects Important? 9 Project Profile: “Throwing Good Money after Bad”: the BBC’s Digital

Media Initiative 10

1.3 Project Life Cycles 13 ◾ Box 1.1: Project Managers in Practice 15

1.4 Determinants of Project Success 16 ◾ Box 1.2: Project Management Research in Brief 19

1.5 Developing Project Management Maturity 19

1.6 Project Elements and Text Organization 23 Summary  27  •  Key Terms  29  •  Discussion Questions  29 •  Case Study 1.1 MegaTech, Inc.  29  •  Case Study 1.2 The IT  Department at Hamelin Hospital  30  •  Case Study 1.3 Disney’s Expedition  Everest  31  •  Case Study 1.4 Rescue of Chilean Miners  32  •  Internet  Exercises  33  •  PMP Certification Sample Questions  34  •  Notes  34

Chapter 2 the organIzatIonal Context: Strategy, StruCture, and Culture 36

Project Profile: Tesla’s $5 Billion Gamble 37

Introduction 38

2.1 Projects and Organizational Strategy 39

2.2 Stakeholder Management 41 Identifying Project Stakeholders 42 Managing Stakeholders 45

2.3 Organizational Structure 47

2.4 Forms of Organizational Structure 48 Functional Organizations 48 Project Organizations 50 Matrix Organizations 53 Moving to Heavyweight Project Organizations 55

◾ Box 2.1: Project Management Research in Brief 56

2.5 Project Management Offices 57

2.6 Organizational Culture 59 How Do Cultures Form? 61 Organizational Culture and Project Management 63 Project Profile: Electronic Arts and the Power of Strong Culture in Design Teams 64

Summary  65  •  Key Terms  67  •  Discussion Questions  67  •  Case Study 2.1 Rolls-Royce Corporation  67  •  Case Study 2.2 Classic Case: Paradise Lost—The Xerox Alto  68  •  Case Study 2.3 Project Task Estimation and the Culture of “Gotcha!”  69  •  Case Study 2.4 Widgets ’R Us 70 •  Internet Exercises  70  •  PMP Certification Sample Questions  70  •  Integrated Project—Building Your Project Plan  72  •  Notes  74

Contents v

Chapter 3 ProjeCt SeleCtIon and PortfolIo ManageMent 76 Project Profile: Project Selection Procedures: A Cross-Industry Sampler 77

Introduction 78

3.1 Project Selection 78

3.2 Approaches to Project Screening and Selection 80 Method One: Checklist Model 80 Method Two: Simplified Scoring Models 82 Limitations of Scoring Models 84 Method Three: The Analytical Hierarchy Process 84 Method Four: Profile Models 88

3.3 Financial Models 90 Payback Period 90 Net Present Value 92 Discounted Payback 94 Internal Rate of Return 94 Choosing a Project Selection Approach 96 Project Profile: Project Selection and Screening at GE: The Tollgate Process 97

3.4 Project Portfolio Management 98 Objectives and Initiatives 99 Developing a Proactive Portfolio 100 Keys to Successful Project Portfolio Management 103 Problems in Implementing Portfolio Management 104

Summary  105  •  Key Terms  106  •  Solved Problems  107  •  Discussion Questions  108  •  Problems  108  •  Case Study 3.1 Keflavik Paper Company  111  •  Case Study 3.2 Project Selection at Nova Western, Inc.  112  •  Internet Exercises  113  •  Notes  113

Chapter 4 leaderShIP and the ProjeCt Manager 115 Project Profile: Leading by Example for the London Olympics—Sir John Armitt 116

Introduction 117

4.1 Leaders Versus Managers 118

4.2 How the Project Manager Leads 119 Acquiring Project Resources 119 Motivating and Building Teams 120 Having a Vision and Fighting Fires 121 Communicating 121

◾ Box 4.1: Project Management Research in Brief 124

4.3 Traits of Effective Project Leaders 125 Conclusions about Project Leaders 126 Project Profile: Dr. Elattuvalapil Sreedharan, India’s Project Management Guru 126

4.4 Project Champions 127 Champions—Who Are They? 128 What Do Champions Do? 129 How to Make a Champion 130

4.5 The New Project Leadership 131 ◾ Box 4.2: Project Managers in Practice 132

Project Profile: The Challenge of Managing Internationally 133

4.6 Project Management Professionalism 134

vi Contents

Summary  135  •  Key Terms  136  •  Discussion Questions  136  •  Case Study 4.1 In Search of Effective Project Managers 137 •  Case Study 4.2 Finding the Emotional Intelligence to Be a Real Leader 137 •  Case Study 4.3 Problems with John  138  •  Internet Exercises  141 •  PMP Certification Sample Questions  141  •  Notes  142

Chapter 5 SCoPe ManageMent 144 Project Profile: “We look like fools.”—Oregon’s Failed Rollout of Its Obamacare

Web Site 145

Introduction 146

5.1 Conceptual Development 148 The Statement of Work 150 The Project Charter 151 Project Profile: Statements of Work: Then and Now 151

5.2 The Scope Statement 153 The Work Breakdown Structure 153 Purposes of the Work Breakdown Structure 154 The Organization Breakdown Structure 159 The Responsibility Assignment Matrix 160

5.3 Work Authorization 161 Project Profile: Defining a Project Work Package 163

5.4 Scope Reporting 164 ◾ Box 5.1: Project Management Research in Brief 165

5.5 Control Systems 167 Configuration Management 167

5.6 Project Closeout 169 Summary  170  •  Key Terms  171  •  Discussion Questions  171  •  Problems  172  •  Case Study 5.1 Boeing’s Virtual Fence 172 •  Case Study 5.2 California’s High-Speed Rail Project  173  •  Case Study 5.3 Project Management at  175  •  Case Study 5.4 The Expeditionary Fighting Vehicle  176  •  Internet Exercises  178  •  PMP Certification Sample Questions  178  •  MS Project Exercises  179  •  Appendix 5.1: Sample Project Charter  180  •  Integrated Project— Developing the Work Breakdown Structure  182  •  Notes  184

Chapter 6 ProjeCt teaM BuIldIng, ConflICt, and negotIatIon 186 Project Profile: Engineers Without Borders: Project Teams Impacting Lives 187

Introduction 188

6.1 Building the Project Team 189 Identify Necessary Skill Sets 189 Identify People Who Match the Skills 189 Talk to Potential Team Members and Negotiate with Functional Heads 189 Build in Fallback Positions 191 Assemble the Team 191

6.2 Characteristics of Effective Project Teams 192 A Clear Sense of Mission 192 A Productive Interdependency 192 Cohesiveness 193 Trust 193 Enthusiasm 193 Results Orientation 194

Contents vii

6.3 Reasons Why Teams Fail 194 Poorly Developed or Unclear Goals 194 Poorly Defined Project Team Roles and Interdependencies 194 Lack of Project Team Motivation 195 Poor Communication 195 Poor Leadership 195 Turnover Among Project Team Members 196 Dysfunctional Behavior 196

6.4 Stages in Group Development 196 Stage One: Forming 197 Stage Two: Storming 197 Stage Three: Norming 198 Stage Four: Performing 198 Stage Five: Adjourning 198 Punctuated Equilibrium 198

6.5 Achieving Cross-Functional Cooperation 199 Superordinate Goals 199 Rules and Procedures 200 Physical Proximity 201 Accessibility 201 Outcomes of Cooperation: Task and Psychosocial Results 201

6.6 Virtual Project Teams 202 Project Profile: Tele-Immersion Technology Eases the Use

of Virtual Teams 203

6.7  Conflict Management  204 What Is Conflict? 205 Sources of Conflict 206 Methods for Resolving Conflict 208

6.8 Negotiation 209 Questions to Ask Prior to the Negotiation 209 Principled Negotiation 210 Invent Options for Mutual Gain 212 Insist on Using Objective Criteria 213

Summary  214  •  Key Terms  214  •  Discussion Questions  215  •  Case Study 6.1 Columbus Instruments  215  •  Case Study 6.2 The Bean Counter and the Cowboy  216  •  Case Study 6.3 Johnson & Rogers Software Engineering, Inc.  217  •  Exercise in Negotiation  219  •  Internet  Exercises  220  •  PMP Certification Sample Questions  220  •  Notes  221

Chapter 7 rISk ManageMent 223 Project Profile: The Building that Melted Cars 224

Introduction 225 ◾ Box 7.1: Project Managers in Practice 227

7.1 Risk Management: A Four-Stage Process 228 Risk Identification 228 Project Profile: Bank of America Completely Misjudges Its Customers 230

Risk Breakdown Structures 231 Analysis of Probability and Consequences 231 Risk Mitigation Strategies 234

viii Contents

Use of Contingency Reserves 236 Other Mitigation Strategies 237 Control and Documentation 237 Project Profile: Collapse of Shanghai Apartment Building 239

7.2 Project Risk Management: An Integrated Approach 241 Summary  243  •  Key Terms  244  •  Solved Problem  244  •  Discussion  Questions  244  •  Problems  244  •  Case Study 7.1 Classic Case: de Havilland’s Falling Comet  245  •  Case Study 7.2 The Spanish Navy Pays Nearly $3 Billion for a Submarine That Will Sink Like a Stone  248  •  Case Study 7.3 Classic Case: Tacoma Narrows Suspension Bridge  249  •  Internet  Exercises  251  •  PMP Certification Sample Questions  251  •  Integrated  Project—Project Risk Assessment  253  •  Notes  255

Chapter 8 CoSt eStIMatIon and BudgetIng 256 Project Profile: Sochi Olympics—What’s the Cost of National Prestige? 257

8.1 Cost Management 259 Direct Versus Indirect Costs 260 Recurring Versus Nonrecurring Costs 261 Fixed Versus Variable Costs 261 Normal Versus Expedited Costs 262

8.2 Cost Estimation 262 Learning Curves in Cost Estimation 266

◾ Box 8.1: Project Management Research in Brief 270 Problems with Cost Estimation 272

◾ Box 8.2: Project Management Research in Brief 274

8.3 Creating a Project Budget 275 Top-Down Budgeting 275 Bottom-Up Budgeting 276 Activity-Based Costing 276

8.4 Developing Budget Contingencies 278 Summary  280  •  Key Terms  281  •  Solved Problems  282  •  Discussion Questions  283  •  Problems  284  •  Case Study 8.1 The Hidden Costs of Infrastructure Projects—The Case of Building Dams 286 •  Case Study 8.2 Boston’s Central Artery/Tunnel Project  288  •  Internet  Exercises  290  •  PMP Certification Sample Questions  290  •  Integrated  Project—Developing the Cost Estimates and Budget  292  •  Notes  294

Chapter 9 ProjeCt SChedulIng: netWorkS, duratIon eStIMatIon, and CrItICal Path 296

Project Profile: After 20 Years and More Than $50 Billion, Oil is No Closer to the Surface: The Caspian Kashagan Project 297

Introduction 298

9.1 Project Scheduling 299

9.2  Key Scheduling Terminology  300

9.3 Developing a Network 302 Labeling Nodes 303 Serial Activities 303 Concurrent Activities 303 Merge Activities 304 Burst Activities 305

9.4 Duration Estimation 307

Contents ix

9.5 Constructing the Critical Path 311 Calculating the Network 311 The Forward Pass 312 The Backward Pass 314 Probability of Project Completion 316 Laddering Activities 318 Hammock Activities 319 Options for Reducing the Critical Path 320

◾ Box 9.1: Project Management Research in Brief 321 Summary  322  •  Key Terms  323  •  Solved Problems  323  •  Discussion Questions  325  •  Problems  325  •  Internet  Exercises  327  •  MS Project Exercises  328  •  PMP Certification  Sample Questions  328  •  Notes  329

Chapter 10 ProjeCt SChedulIng: laggIng, CraShIng, and aCtIvIty netWorkS 330

Project Profile: Enlarging the Panama Canal 331

Introduction 333

10.1 Lags in Precedence Relationships 333 Finish to Start 333 Finish to Finish 334 Start to Start 334 Start to Finish 335

10.2 Gantt Charts 335 Adding Resources to Gantt Charts 337 Incorporating Lags in Gantt Charts 338 ◾ Box 10.1: Project Managers in Practice 338

10.3 Crashing Projects 340 Options for Accelerating Projects 340 Crashing the Project: Budget Effects 346

10.4 Activity-on-Arrow Networks 348 How Are They Different? 348 Dummy Activities 351 Forward and Backward Passes with AOA Networks 352 AOA Versus AON 353

10.5 Controversies in the Use of Networks 354 Conclusions 356 Summary  356  •  Key Terms  357  •  Solved Problems  357  •  Discussion  Questions  358  •  Problems  358  •  Case Study 10.1 Project Scheduling at Blanque Cheque Construction (A)  360  •  Case Study 10.2 Project Scheduling at Blanque Cheque Construction (B)  360  •  MS Project  Exercises  361  •  PMP Certification Sample Questions  361  •  Integrated  Project—Developing the Project Schedule  363  •  Notes  365

Chapter 11 advanCed toPICS In PlannIng and SChedulIng: agIle and CrItICal ChaIn 366

Project Profile: Developing Projects Through Kickstarter—Do Delivery Dates Mean Anything? 367

Introduction 368

11.1 Agile Project Management 369 What Is Unique About Agile PM? 370

x Contents

Tasks Versus Stories 371 Key Terms in Agile PM 372 Steps in Agile 373 Sprint Planning 374 Daily Scrums 374 The Development Work 374 Sprint Reviews 375 Sprint Retrospective 376 Problems with Agile 376

◾ Box 11.1: Project Management Research in Brief 376

11.2 Extreme Programming (XP) 377

11.3 The Theory of Constraints and Critical Chain Project Scheduling 377 Theory of Constraints 378

11.4 The Critical Chain Solution to Project Scheduling 379 Developing the Critical Chain Activity Network 381 Critical Chain Solutions Versus Critical Path Solutions 383

Project Profile: Eli Lilly Pharmaceuticals and Its Commitment to Critical Chain Project Management 385

11.5  Critical Chain Solutions to Resource Conflicts  386

11.6 Critical Chain Project Portfolio Management 387 ◾ Box 11.2: Project Management Research in Brief 390

11.7 Critiques of CCPM 391 Summary  391  •  Key Terms  393  •  Solved Problem  393  •  Discussion Questions  394  •  Problems  394  •  Case Study 11.1 It’s an Agile World  396  •  Case Study 11.2 Ramstein Products, Inc. 397 •  Internet Exercises  398  •  Notes  398

Chapter 12 reSourCe ManageMent 400 Project Profile: Hong Kong Connects to the World’s Longest Natural

Gas Pipeline 401

Introduction 402

12.1 The Basics of Resource Constraints 402 Time and Resource Scarcity 403

12.2 Resource Loading 405

12.3 Resource Leveling 407 Step One: Develop the Resource-Loading Table 411 Step Two: Determine Activity Late Finish Dates 412 Step Three: Identify Resource Overallocation 412 Step Four: Level the Resource-Loading Table 412

12.4 Resource-Loading Charts 416 ◾ Box 12.1: Project Managers in Practice 418

12.5 Managing Resources in Multiproject Environments 420 Schedule Slippage 420 Resource Utilization 420 In-Process Inventory 421 Resolving Resource Decisions in Multiproject Environments 421 Summary  423  •  Key Terms  424  •  Solved Problem  424  •  Discussion Questions  425  •  Problems  425  •  Case Study 12.1 The Problems of Multitasking  427  •  Internet Exercises  428  •  MS Project  Exercises  428  •  PMP Certification Sample Questions  429  •  Integrated  Project—Managing Your Project’s Resources  430  •  Notes  430

Contents xi

Chapter 13 ProjeCt evaluatIon and Control 431 Project Profile: New York City’s CityTime Project 432

Introduction 433

13.1 Control Cycles—A General Model 434

13.2 Monitoring Project Performance 435 The Project S-Curve: A Basic Tool 435 S-Curve Drawbacks 436 Milestone Analysis 437 Problems with Milestones 438 The Tracking Gantt Chart 439 Benefits and Drawbacks of Tracking Gantt Charts 440

13.3 Earned Value Management 440 Terminology for Earned Value 441 Creating Project Baselines 442 Why Use Earned Value? 443 Steps in Earned Value Management 444 Assessing a Project’s Earned Value 445

13.4 Using Earned Value to Manage a Portfolio of Projects 450 Project Profile: Earned Value at Northrop Grumman 451

13.5 Issues in the Effective Use of Earned Value Management 452

13.6 Human Factors in Project Evaluation and Control 454 Critical Success Factor Definitions 456 Conclusions 458 Summary  458  •  Key Terms  459  •  Solved Problem  459  •  Discussion Questions  460  •  Problems  461  •  Case Study 13.1 The IT Department at Kimble College  463  •  Case Study 13.2 The Supercon- ducting Supercollider  464  •  Case Study 13.3 Boeing’s 787 Dreamliner: Failure to Launch  465  •  Internet Exercises  468  •  MS Project  Exercises  468  •  PMP Certification Sample Questions  469  •  Appendix 13.1: Earned Schedule*  470  •  Notes  475

Chapter 14 ProjeCt CloSeout and terMInatIon 477 Project Profile: Duke Energy and Its Cancelled Levy County Nuclear

Power Plant 478

Introduction 479

14.1 Types of Project Termination 480 ◾ Box 14.1: Project Managers in Practice 480

14.2 Natural Termination—The Closeout Process 482 Finishing the Work 482 Handing Over the Project 482 Gaining Acceptance for the Project 483 Harvesting the Benefits 483 Reviewing How It All Went 483 Putting It All to Bed 485 Disbanding the Team 486 What Prevents Effective Project Closeouts? 486

14.3 Early Termination for Projects 487 Making the Early Termination Decision 489 Project Profile: Aftermath of a “Feeding Frenzy”: Dubai and Cancelled

Construction Projects 490

xii Contents

Shutting Down the Project 490 ◾ Box 14.2: Project Management Research in Brief 492

Allowing for Claims and Disputes 493

14.4 Preparing the Final Project Report 494 Conclusion 496 Summary  496  •  Key Terms  497  •  Discussion Questions  497  •  Case Study 14.1 New Jersey Kills Hudson River Tunnel Project  497  •  Case Study 14.2 The Project That Wouldn’t Die  499  •  Case Study 14.3 The Navy Scraps Development of Its Showpiece Warship—Until the Next Bad Idea  500  •  Internet Exercises  501  •  PMP Certification Sample  Questions  502  •  Appendix 14.1: Sample Pages from Project Sign-off  Document  503  •  Notes  507

Appendix A The Cumulative Standard Normal Distribution 509

Appendix B Tutorial for MS Project 2013 510

Appendix C Project Plan Template 520

Glossary 524

Company Index 534

Name Index 535

Subject Index 538



Project management has become central to operations in industries as diverse as construction and information technology, architecture and hospitality, and engineering and new product development; therefore, this text simultaneously embraces the general principles of project management while addressing specific examples across the wide assortment of its applications. This text approaches each chapter from the perspective of both the material that is general to all disciplines and project types and that which is more specific to alternative forms of projects. One way this is accomplished is through the use of specific, discipline-based examples to illus- trate general principles as well as the inclusion of cases and Project Profiles that focus on more specific topics (e.g., Chapter 5’s treatment of IT “death march” projects).

Students in project management classes come from a wide and diverse cross section of uni- versity majors and career tracks. Schools of health, business, architecture, engineering, information systems, and hospitality are all adding project management courses to their catalogs in response to the demands from organizations and professional groups that see their value for students’ future careers. Why has project management become a discipline of such tremendous interest and applica- tion? The simple truth is that we live in a “projectized” world. Everywhere we look we see people engaged in project management. In fact, project management has become an integral part of practi- cally every firm’s business model.

This text takes a holistic, integrated approach to managing projects, exploring both technical and managerial challenges. It not only emphasizes individual project execution, but also provides a strategic perspective, demonstrating the means with which to manage projects at both the program and portfolio levels.

At one time, project management was almost exclusively the property of civil and con- struction engineering programs where it was taught in a highly quantitative, technical man- ner. “Master the science of project management,” we once argued, “and the ‘art’ of project management will be equally clear to you.” Project management today is a complex, “manage- ment” challenge requiring not only technical skills but a broad-based set of people skills as well. Project management has become the management of technology, people, culture, stake- holders, and other diverse elements necessary to successfully complete a project. It requires knowledge of leadership, team building, conflict resolution, negotiation, and influence in equal measure with the traditional, technical skill set. Thus, this textbook broadens our focus beyond the traditional project management activities of planning and scheduling, project control, and termination, to a more general, inclusive, and, hence, more valuable perspective of the project management process.

What’s NeW iN the foUrth editioN?

New features

• Agile Project Management • Project Charters • MS Project 2013 Step-by-Step Tutorials • Appendix—Project Execution Plan Template • New Project Managers in Practice Profiles • Risk Breakdown Structures • Extreme Programming • Updated Problems in Chapters • New Project Management Research in Brief: “Does Agile Work?” • All MS Project Examples and Screen Captures Updated to MS Project 2013 • All Project Management Body of Knowledge (PMBOK) Referencing Updated to

5th Edition • Quarterly Updates for All Book Adopters on Latest Cases and Examples in Project


Updated Project Profiles

Chapter 1 Introduction: Why Project Management? • Development Projects in Lagos, Nigeria • “Throwing Good Money after Bad”: The BBC’s Digital Media Initiative

Chapter 2 The Organizational Context: Strategy, Structure, and Culture • Tesla’s $5 Billion Gamble • Electronic Arts and the Power of Strong Culture in Design Teams

Chapter 3 Project Selection and Portfolio Management • Project Selection Procedures: A Cross-Industry Sampler

Chapter 4 Leadership and the Project Manager • Leading by Example for the London Olympics—Sir John Armitt • Dr. E. Sreedharan, India’s Project Management Guru

Chapter 5 Scope Management • “We look like fools.” Oregon’s Failed Rollout of Their Obamacare Website • Boeing’s Virtual Fence • California’s High-Speed Rail Project—What’s the Latest News? • The Expeditionary Fighting Vehicle

Chapter 6 Project Team Building, Conflict, and Negotiation • Engineers without Borders: Project Teams Impacting Lives

Chapter 7 Risk Management • The Building That Melted Cars • Bank of America Completely Misjudges Its Customers • Collapse of Shanghai Apartment Building • The Spanish Navy Pays Nearly $3 Billion for a Submarine That Will Sink Like a Stone

Chapter 8 Cost Estimation and Budgeting • Sochi Olympics—What’s the Cost of National Prestige? • The Hidden Costs of Infrastructure ProjectsThe Case of Building Dams

Chapter 9 Project Scheduling: Networks, Duration Estimation, and Critical Path • After 20 Years and More than $50 Billion, Oil Is No Closer to the Surface: The Caspian

Kashagan Project Chapter 10 Project Scheduling: Lagging, Crashing, and Activity Networks • Enlarging the Panama Canal

Chapter 11 Critical Chain Project Scheduling • Developing Projects through Kickstarter—Do Delivery Dates Mean Anything? • Eli Lilly Pharmaceutical’s Commitment to Critical Chain Project Scheduling

Chapter 12 Resource Management • Hong Kong Connects to the World’s Longest Natural Gas Pipeline

Chapter 13 Project Evaluation and Control • New York City’s CityTime Project • Boeing’s 787 Dreamliner: Failure to Launch (with update) • Earned Value Management at Northrop Grumman

Chapter 14 Project Closeout and Termination • Duke Energy and Its Cancelled Levy County Nuclear Power Plant • Aftermath of a “Feeding Frenzy”—Dubai and Cancelled Construction Projects • New Jersey Kills Hudson River Tunnel Project • The Navy Scraps Development of Its Showpiece Warship—Until the Next Bad Idea

oUr focUs

This textbook employs a managerial, business-oriented approach to the management of projects. Thus we have integrated Project Profiles into the text.

• Project Profiles—Each chapter contains one or more Project Profiles that highlight cur- rent examples of project management in action. Some of the profiles reflect on significant

xiv Preface

Preface xv

achievements; others detail famous (and not-so-famous) examples of project failures. Because they cover diverse ground (IT projects, construction, new product development, and so forth), there should be at least one profile per chapter that is meaningful to the class’s focus. There is a deliberate effort made to offer a combination of project success stories and project failures. While successful projects can be instructive, we often learn far more from examining the variety of reasons why projects fail. As much as possible, these stories of success and failure are intended to match up with the chapters to which they are attached. For example, as we study the uses of projects to implement corporate strategy, it is useful to consider Elon Musk’s $5 billion dollar decision to develop a “gigafactory” to produce batteries for his Tesla automobiles.

The book blends project management within the context of the operations of any successful or- ganization, whether publicly held, private, or not-for-profit. We illustrate this through the use of end-of-chapter cases.

• Cases—At the end of each chapter are some final cases that take specific examples of the material covered in the chapter and apply them in the alternate format of case studies. Some of the cases are fictitious, but the majority of them are based on real situations, even where aliases mask the real names of organizations. These cases include discussion ques- tions that can be used either for homework or to facilitate classroom discussions. There are several “classic” project cases as well, highlighting some famous (and infamous) examples of projects whose experiences have shaped our understanding of the discipline and its best practices.

Further, we explore both the challenges in the management of individual projects as well as broad- ening out this context to include strategic, portfolio-level concepts. To do this, we ask students to develop a project plan using MS Project 2013.

• Integrated Project Exercises—Many of the chapters include an end-of-chapter feature that is unique to this text: the opportunity to develop a detailed project plan. A very beneficial exercise in project management classes is to require students, either in teams or individu- ally, to learn the mechanics of developing a detailed and comprehensive project plan, in- cluding scope, scheduling, risk assessment, budgeting, and cost estimation. The Integrated Project exercises afford students the opportunity to develop such a plan by assigning these activities and illustrating a completed project (ABCups, Inc.) in each chapter. Thus, students are assigned their project planning activities and have a template that helps them complete these exercises.

And finally, we have integrated the standards set forth by the world’s largest governing body for project management. The Project Management Institute (PMI) created the Project Management Body of Knowledge (PMBOK), which is generally regarded as one of the most comprehensive frameworks for identifying the critical knowledge areas that project managers must understand if they are to master their discipline. The PMBOK has become the basis for the Project Management Professional (PMP) certification offered by PMI for professional project managers.

• Integration with the PMBOK—As a means to demonstrate the coverage of the critical PMBOK elements, readers will find that the chapters in this text identify and cross-list the corresponding knowledge areas from the latest, fifth edition of PMBOK. Further, all terms (including the Glossary) are taken directly from the most recent edition of the PMBOK.

• Inclusion of Sample PMP Certification Exam Questions—The Project Management Professional (PMP) certification represents the highest standard of professional qualifi- cation for a practicing project manager and is administered by the Project Management Institute. As of 2014, there were more than 600,000 PMPs worldwide. In order to attain PMP certification, it is necessary for candidates to undergo a comprehensive exam that tests their knowledge of all components of the PMBOK. This text includes a set of sample PMP certification exam questions at the end of most of the chapters, in order to give read- ers an idea of the types of questions typically asked on the exam and how those topics are treated in this book.

xvi Preface

other PoiNts of distiNctioN

The textbook places special emphasis on blending current theory, practice, research, and case studies in such a manner that readers are given a multiple-perspective exposure to the project management process. A number of in-chapter features are designed to enhance student learning, including:

• MS Project Exercises—An additional feature of the text is the inclusion at the end of several chapters of some sample problems or activities that require students to generate MS Project output files. For example, in Chapter 9 on scheduling, students must create an MS Project network diagram. Likewise, other reports can be assigned to help students become mini- mally adept at interacting with this program. It is not the purpose of this text to fully develop these skills but rather to plant the seeds for future application.

• Research in Brief—A unique feature of this text is to include short (usually one-page) text boxes that highlight the results of current research on the topics of interest. Students often find it useful to read about actual studies that highlight the text material and provide additional information that expands their learning. Although not every chapter includes a “Research in Brief” box, most have one and, in some cases, two examples of this feature.

• Project Managers in Practice—An addition to this text is the inclusion of several short profiles of real, practicing project managers from a variety of corporate and project settings. These profiles have been added to give students a sense of the types of real-world challenges project managers routinely face, the wide range of projects they are called to manage, and the satisfac- tions and career opportunities available to students interested in pursuing project manage- ment as a career.

• Internet Exercises—Each chapter contains a set of Internet exercises that require students to search the Web for key information and perform other activities that lead to student learn- ing through outside-of-class, hands-on activities. Internet exercises are a useful supplement, particularly in the area of project management, because so much is available on the World Wide Web relating to projects, including cases, news releases, and Internet-based tools for analyzing project activities.

• MS Project 2013 Tutorials—Appendix B at the end of the text features two in-depth tutorials that instruct students in the rudiments of developing a project schedule, resource leveling, and critical path development. A second tutorial instructs students in methods for updating the project plan, generating output files such as earned value metrics, and tracking ongoing project activities. These tutorials are not intended to substitute for fuller instruction in this valuable software, but they do provide a critical means for initial familiarization with the package.

• Project Execution Plan Template—Appendix C provides a template for developing a fully evolved project execution plan. Instructors using previous versions of this text noted the value in requiring that students be able to create a project plan and requested a more comprehensive template that could be employed. This template addresses the critical elements of project scope, as well as offers a method for putting these details in a logical sequence.

instructor resources At the Instructor Resource Center,, instructors can easily register to gain access to a variety of instructor resources available with this text in downloadable format. If assistance is needed, our dedicated technical support team is ready to help with the media supple- ments that accompany this text. Visit for answers to frequently asked questions and toll-free user support phone numbers.

The following supplements are available with this text:

• Instructor’s Solutions Manual • Test Bank • TestGen® Computerized Test Bank • PowerPoint Presentation

Preface xvii


In acknowledging the contributions of past and present colleagues to the creation of this text, I must first convey my deepest thanks and appreciation for the 30-year association with my origi- nal mentor, Dr. Dennis Slevin of the University of Pittsburgh’s Katz Graduate School of Business. My collaboration with Denny on numerous projects has been fruitful and extremely gratifying, both professionally and personally. In addition, Dr. David Cleland’s friendship and partnership in several ventures has been a great source of satisfaction through the years. A frequent collaborator who has had a massive influence on my thinking and approach to understanding project manage- ment is Professor Peter W.G. Morris, lately of University College London. Working with him has been a genuine joy and constant source of inspiration. Additional mentors and colleagues who have strongly influenced my thinking include Samuel Mantel, Jr., Rodney Turner, Erik Larson, David Frame, Francis Hartman, Jonas Soderlund, Young Kwak, Rolf Lundin, Lynn Crawford, Graham Winch, Terry Williams, Francis Webster, Terry Cooke-Davies, Hans Thamhain, and Karlos Artto. Each of these individuals has had a profound impact on the manner in which I view, study, and write about project management. Sadly, 2014 saw the passing of three of these outstanding project management scholars—Hans Thamhain, Sam Mantel and Francis Hartman. I hope that my efforts help, in some small part, to keep their vision and contributions alive.

Over the years, I have also been fortunate to develop friendships with some professional project managers whose work I admire enormously. They are genuine examples of the best type of project manager: one who makes it all seem effortless while consistently performing minor miracles. In par- ticular, I wish to thank Mike Brown of Rolls-Royce for his friendship and example. I would also like to thank friends and colleagues from the Project Management Institute, including Lew Gedansky, Harry Stephanou, and Eva Goldman, for their support for and impact on this work.

I am indebted to the reviewers of this text whose numerous suggestions and critiques have been an invaluable aid in shaping its content. Among them, I would like to especially thank the following:

Kwasi Amoako-Gyampah— University of North Carolina, Greensboro Ravi Behara—George Mason University Jeffrey L. Brewer—Purdue University Dennis Cioffi—George Washington University David Clapp—Florida Institute of Technology Bruce DeRuntz—Southern Illinois University at Carbondale Ike Ehie—Kansas State University Michael H. Ensby—Clarkson University Lynn Fish—Canisius College Linda Fried—University of Colorado, Denver Mario Guimaraes—Kennesaw State University Richard Gunther—California State University, Northridge Brian Gurney—Montana State University, Billings Gary Hackbarth—Iowa State University Mamoon M. Hammad—George Washington University Scott Robert Homan—Purdue University John Hoxmeier—Colorado State University Alex Hutchins—ITT Technical Institute Richard Jensen—Hofstra University Robert Key—University of Phoenix Homayoun Khamooshi—George Washington University Dennis Krumwiede—Idaho State University George Mechling—Western Carolina University Julia Miyaoka—San Francisco State University

xviii Preface

LaWanda Morant—ITT Technical Institute Robert Morris—Florida State College at Jacksonville James Muller—Cleveland State University Kenneth E. Murphy—Willamette University John Nazemetz—Oklahoma State University Patrick Penfield—Syracuse University Ronald Price—ITT Techincal Institute Ronny Richardson—Southern Polytechnic State University John Sherlock—Iona College Gregory Shreve—Kent State University Randall G. Sleeth—Virginia Commonwealth University Kimberlee Snyder—Winona State University Jeff Trailer—California State University, Chico Leo Trudel—University of Maine Oya Tukel—Cleveland State University Darien Unger—Howard University Amy Valente—Cayuga Community College Stephen Whitehead—Hilbert College

I would also like to thank my colleagues in the Samuel Black School of Business at Penn State, the Behrend College. Additionally, my thanks goes to Dana Johnson of Michigan Technological University for preparing the PowerPoints for this edition, and Geoff Willis of University of Central Oklahoma for preparing the Test Bank. Extra-special thanks go to Kerri Tomasso for her help in preparing the final manuscript and for her integral role in permissions research and acquisitions. I am espe- cially indebted to Khurrum Bhutta, who accuracy checked this edition. I am very grateful for his time and effort, and any errors that may remain are entirely my own.

In developing the cases for this edition of the textbook, I was truly fortunate to develop wonderful professional relationships with a number of individuals. Andrea Finger and Kathleen Prihoda of Disney were wonderfully helpful and made time in their busy schedules to assist me in developing the Expedition Everest case for this text. Stephanie Smith, Mohammed Al-Sadiq, Bill Mowery, Mike Brown, Julia Sweet, and Kevin O’Donnell provided me with invaluable information on their job responsibilities and what it takes to be a successful project manager.

Finally, I wish to extend my sincere thanks to the people at Pearson for their support for the text during its development, including Dan Tylman, editor, and Claudia Fernandes, program manager. I also would like to thank the Pearson editorial, production, and marketing staffs.


The textbook team and I would appreciate hearing from you. Let us know what you think about this textbook by writing to [email protected] Please include “Feedback about Pinto” in the subject line.

If you have questions related to this product, please contact our customer service department online at

Finally, it is important to reflect on an additional salient issue as you begin your study of project management: Most of you will be running a project long before you are given wider management responsibilities in your organizations. Successful project managers are the lifeblood of organizations and bear the imprint of the fast track. I wish you great success!

Jeffrey K. Pinto, Ph.D. Andrew Morrow and Elizabeth Lee Black Chair

Management of Technology Samuel Black School of Business Penn State, the Behrend College

[email protected]


1 ■ ■ ■

Introduction Why Project Management?

Chapter Outline Project Profile

Development Projects in Lagos, Nigeria introduction 1.1 What is a Project?

General Project Characteristics 1.2 Why are Projects imPortant?

Project Profile “Throwing Good Money after Bad”:

The BBC’s Digital Media Initiative 1.3 Project life cycles Project managers in Practice

Stephanie Smith, Westinghouse Electric Company

1.4 determinants of Project success Project Management Research in Brief Assessing Information Technology (IT) Project


1.5 develoPing Project management maturity

1.6 Project elements and text organization

Summary Key Terms Discussion Questions Case Study 1.1 MegaTech, Inc. Case Study 1.2 The IT Department at Hamelin

Hospital Case Study 1.3 Disney’s Expedition Everest Case Study 1.4 Rescue of Chilean Miners Internet Exercises PMP Certification Sample Questions Notes

Chapter Objectives After completing this chapter, you should be able to:

1. Understand why project management is becoming such a powerful and popular practice in business.

2. Recognize the basic properties of projects, including their definition. 3. Understand why effective project management is such a challenge. 4. Differentiate between project management practices and more traditional, process-oriented

business functions. 5. Recognize the key motivators that are pushing companies to adopt project management

practices. 6. Understand and explain the project life cycle, its stages, and the activities that typically occur

at each stage in the project. 7. Understand the concept of project “success,” including various definitions of success, as well

as the alternative models of success.

2 Chapter 1 • Introduction

8. Understand the purpose of project management maturity models and the process of bench- marking in organizations.

9. Identify the relevant maturity stages that organizations go through to become proficient in their use of project management techniques.

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Definition of a Project (PMBoK sec. 1.2) 2. Definition of Project Management (PMBoK sec. 1.3) 3. Relationship to Other Management Disciplines (PMBoK sec. 1.4) 4. Project Phases and the Project Life Cycle (PMBoK sec. 2.1)

The world acquires value only through its extremes and endures only through moderation; extremists make the world great, the moderates give it stability.1

Project Profile

Development Projects in lagos, Nigeria

Lagos is the capital of Nigeria and home to an estimated 15–20 million people, making its population larger than London or Beijing. As the largest and fastest-growing city in sub-Saharan Africa (estimates are that 600,000 people are added to Lagos’ population each year), Lagos is in desperate need of developing and maintaining infrastructure to support its population, while supporting its claim as a high-technology hub on the African continent. Considering that about 85% of the world’s population resides in the developing world and transitioning economies, and nearly two-thirds of that population is below the age of 35, the need for infrastructure to support critical human needs is im- mense. About 70% of the city’s population is believed to live in slums, while a 2006 United Nations report estimated that only 10% of households in the Lagos Metropolitan area were directly connected to a municipal water supply. In spite of these problems, Nigeria is Africa’s biggest economy, driven by economic growth in Lagos, home to film and fashion industries, financial markets, and consumer goods manufacturers.

The list of critical items on the list for urban improvement is large. For example, for a city of more than 15 million, electricity is scarcely to be found. Lagos power stations only generate a mere 2,000 megawatts of electricity—less than half of that available for a single city block in midtown Manhattan! “We have about two hours, maybe, of public power a day,” says Kola Karim, CEO of Nigeria’s Shoreline Energy International. “It’s unbearable.” Everywhere in the city people are using gasoline or diesel generators to supply power when the inevitable rolling blackouts resume.

Additionally, Lagos is critically short on housing. To overcome this shortage people of Lagos resort to living in shanty towns, one such shanty town is Makoko. Makoko is situated on the mainland’s Lagos lagoon. Home to several hundred thousand inhabitants, Makoko lacks access to basic services, including clean drinking water, electricity, and waste disposal, and is prone to severe environmental and health hazards. Consisting of rickety dwellings on stilts perched over the foul-smelling lagoon, Makoko is one of the many chaotic human settlements that have sprouted in Lagos in recent years. As these cities spread out and move too close to major bridges or electrical towers, the govern- ment periodically sends in troops to demolish portions of the floating village.

How did the city get to this point? A big reason was a lack of forethought and development planning. In metro- politan Lagos there are 20,000 people per square kilometer with thousands more arriving each day. Given the physical constraints of the city, originally built on a narrow strip of land and bordering the ocean, there is just not enough space to absorb the new inhabitants. Urban planning, as we know it today, simply did not exist and the city swelled organi- cally, without forethought or a sense of direction. Thus, Lagos has no urban transportation system, few functioning traffic lights, and a crumbling and outdated road system.

The problems do not stop there. Land prices in Lagos are extremely high, due to lack of space for commercial development. However, because of the unreliable electricity supply that makes elevator use questionable, there are few high-rise apartments or office buildings in the city. Banks have been reluctant to invest in real estate trans- actions because of past failures and general economic instability. Faced with the need to drastically change the direction of the city, Babatunde Fashola, Lagos’ visionary governor who took power in 2010, has launched a series

Project Profile 3

of urban development projects to address a variety of the city’s needs. Fashola has announced $50 billion in new infrastructure projects for Lagos, to be developed over the next 10 years. These new project initiatives include the following:

lagos Metro Blue line

The blue line is a major cosmopolitan light-rail transport project to connect districts in Nigeria’s largest city. Designed to ease congestion and speed up journey times for the city’s inhabitants, the Blue Line will run between Marina and Okokomaiko, stopping at 13 stations, and is part of the Lagos Rail Mass Transit program implemented by the govern- ment. Originally proposed in 2008, funding issues have pushed the launch of the Blue Line back to at least 2015. The Line is set to cost $1.2 billion and will be funded by the Lagos State Government.

eko Atlantic

Eko Atlantic is an ambitious land reclamation project, a pioneering residential and business development located on Victoria Island, along its upmarket Bar Beach coastline. The project is being built on three and a half square miles of land reclaimed from the Atlantic Ocean and is expected to provide accommodation for 250,000 people and employ- ment opportunities for a further 150,000. The complex will function as a city-within-a-city, including recreational facilities, business and shopping districts, and modern conveniences.

Bus rapid-transit System

To ease the crush of public transportation, the Bus Rapid Transport (BRT) system was introduced 10 years ago to streamline and modernize the motley collection of buses that had transported residents around the city. Lagos has long suffered from an unregulated transportation system in which a variety of different “buses,” ranging from bat- tered minibuses to old, yellow-painted school buses, competed for customers. Fares were also unregulated, leaving

Figure 1.1 traffic congestion in lagos, Nigeria

Source: Femi Ipaye/Xinhua Press/Corbis


4 Chapter 1 • Introduction


Projects are one of the principal means by which we change our world. Whether the goal is to split the atom, tunnel under the English Channel, introduce Windows 9, or plan the next Summer Olympic Games in Rio de Janeiro, the means through which to achieve these challenges remains the same: project management. Project management has become one of the most popular tools for organizations, both public and private, to improve internal operations, respond rapidly to exter- nal opportunities, achieve technological breakthroughs, streamline new product development, and more robustly manage the challenges arising from the business environment. Consider what Tom Peters, best-selling author and management consultant, has to say about project management and its place in business: “Projects, rather than repetitive tasks, are now the basis for most value- added in business.”3 Project management has become a critical component of successful business operations in worldwide organizations.

One of the key features of modern business is the nature of the opportunities and threats posed by external events. As never before, companies face international competition and the need to pursue commercial opportunities rapidly. They must modify and introduce products constantly, respond to customers as fast as possible, and maintain competitive cost and operating levels. Does performing all these tasks seem impossible? At one time, it was. Conventional wisdom held that a company could compete using a low-cost strategy or as a product innovator or with a focus on customer service. In short, we had to pick our competitive niches and concede others their claim to market share. In the past 20 years, however, everything turned upside down. Companies such as General Electric, Apple, Ericksson, Boeing, and Oracle became increasingly effective at realiz- ing all of these goals rather than settling for just one. These companies seemed to be successful in every aspect of the competitive model: They were fast to market and efficient, cost-conscious and customer-focused. How were they performing the impossible?

Obviously, there is no one answer to this complex question. There is no doubt, however, that these companies shared at least one characteristic: They had developed and committed themselves to project management as a competitive tool. Old middle managers, reported Fortune magazine,

are dinosaurs, [and] a new class of manager mammal is evolving to fill the niche they once ruled: project managers. Unlike his biological counterpart, the project manager is more agile and adaptable than the beast he’s displacing, more likely to live by his wits than throwing his weight around.4

Effective project managers will remain an indispensable commodity for successful organiza- tions in the coming years. More and more companies are coming to this conclusion and adopting

drivers free to charge whatever fares they chose. “They might charge $1 in the morning for one trip one way and by afternoon they can go to $3,” says Dayo Mobereola, managing director of the Lagos Metropolitan Area Transport Authority, noting that commuters spend on average 40% of their income on transportation. Before the project was announced, the city had projected that it would transport 60,000 passengers daily, but now it transports over 200,000 passengers daily. The BRT system has reduced waiting times at bus stops, the travel time across the city, all at a reduced rate when compared to the old system.

Schools, Bridges, and Power Plants

Part of the aggressive infrastructure modernization includes improving traffic by building the first suspension bridge in West Africa, as well as adding a number of new schools around the city. Two new power plants are also slated to be constructed, bringing a more dependable source of power to the city, including powering street lights to ease crime and other problems. The city has even launched a fleet of brand new garbage trucks to deal with the 10,000 tons of waste generated every day.

Lagos’ modernization efforts in recent years have come not a moment too soon in support of its citizens. As Professor Falade observed, these efforts to modernize the city’s facilities are a breath of fresh air. “The difference is clear, the evidence is the improved landscape of Lagos in the urban regeneration project.”2

1.1 What Is a Project? 5

project management as a way of life. Indeed, companies in such diverse industries as construction, heavy manufacturing, insurance, health care, finance, public utilities, and software are becoming project savvy and expecting their employees to do the same.

1.1 What is a Project?

Although there are a number of general definitions of the term project, we must recognize at the outset that projects are distinct from other organizational processes. As a rule, a process refers to ongoing, day-to-day activities in which an organization engages while producing goods or services. Processes use existing systems, properties, and capabilities in a continuous, fairly repetitive manner.5 Projects, on the other hand, take place outside the normal, process-oriented world of the firm. Certainly, in some organizations, such as construction, day-to-day processes center on the creation and development of projects. Nevertheless, for the majority of organizations, project management activities remain unique and separate from the manner in which more routine, process-driven work is performed. Project work is continuously evolving, establishes its own work rules, and is the antith- esis of repetition in the workplace. As a result, it represents an exciting alternative to business as usual for many companies. The challenges are great, but so are the rewards of success.

First, we need a clear understanding of the properties that make projects and project manage- ment so unique. Consider the following definitions of projects:

A project is a unique venture with a beginning and end, conducted by people to meet estab- lished goals within parameters of cost, schedule, and quality.6

Projects [are] goal-oriented, involve the coordinated undertaking of interrelated activities, are of finite duration, and are all, to a degree, unique.7

A project can be considered to be any series of activities and tasks that: • Have a specific objective to be completed within certain specifications • Have defined start and end dates • Have funding limits (if applicable) • Consume human and nonhuman resources (i.e., money, people, equipment) • Are multifunctional (i.e., cut across several functional lines)8

[A project is] [o]rganized work toward a predefined goal or objective that requires resources and effort, a unique (and therefore risky) venture having a budget and schedule.9

Probably the simplest definition is found in the Project Management Body of Knowledge (PMBoK) guide of the Project Management Institute (PMI). PMI is the world’s largest professional project management association, with more than 450,000 members worldwide as of 2014. In the PMBoK guide, a project is defined as “a temporary endeavor undertaken to create a unique product, ser- vice, or result” (p. 553).10

Let us examine the various elements of projects, as identified by these set of definitions.

• Projects are complex, one-time processes. A project arises for a specific purpose or to meet a stated goal. It is complex because it typically requires the coordinated inputs of numerous members of the organization. Project members may be from different departments or other organizational units or from one functional area. For example, a project to develop a new software application for a retail company may require only the output of members of the Information Systems group working with the marketing staff. On the other hand, some proj- ects, such as new product introductions, work best with representation from many functions, including marketing, engineering, production, and design. Because a project is intended to fulfill a stated goal, it is temporary. It exists only until its goal has been met, and at that point, it is dissolved.

• Projects are limited by budget, schedule, and resources. Project work requires that members work with limited financial and human resources for a specified time period. They do not run indefinitely. Once the assignment is completed, the project team disbands. Until that point, all its activities are constrained by limitations on budget and personnel availability. Projects are “resource-constrained” activities.

• Projects are developed to resolve a clear goal or set of goals. There is no such thing as a project team with an ongoing, nonspecific purpose. The project’s goals, or deliverables,

6 Chapter 1 • Introduction

define the nature of the project and that of its team. Projects are designed to yield a tangible result, either as a new product or service. Whether the goal is to build a bridge, implement a new accounts receivable system, or win a presidential election, the goal must be specific and the project organized to achieve a stated aim.

• Projects are customer-focused. Whether the project is responding to the needs of an internal organizational unit (e.g., accounting) or intended to exploit a market opportunity external to the organization, the underlying purpose of any project is to satisfy customer needs. In the past, this goal was sometimes overlooked. Projects were considered successful if they attained technical, budgetary, and scheduling goals. More and more, however, companies have real- ized that the primary goal of a project is customer satisfaction. If that goal is neglected, a firm runs the risk of “doing the wrong things well”—pursuing projects that may be done efficiently but that ignore customer needs or fail commercially.

general Project characteristics

Using these definitional elements, we can create a sense of the key attributes that all projects share. These characteristics are not only useful for better understanding projects, but also offer the basis for seeing how project-based work differs from other activities most organizations under- take. Projects represent a special type of undertaking by any organization. Not surprisingly, the challenges in performing them right are sometimes daunting. Nevertheless, given the manner in which business continues to evolve on a worldwide scale, becoming “project savvy” is no longer a luxury: It is rapidly becoming a necessity.

Projects are characterized by the following properties:11

1. Projects are ad hoc endeavors with a clear life cycle. Projects are nontraditional; they are activities that are initiated as needed, operate for a specified time period over a fairly well understood development cycle, and are then disbanded. They are temporary operations.

2. Projects are building blocks in the design and execution of organizational strategies. As we will see in later chapters, projects allow organizations to implement companywide strategies. They are the principal means by which companies operationalize corporate-level objectives. In effect, projects are the vehicles for realizing company goals. For example, Intel’s strat- egy for market penetration with ever newer, smaller, and faster computer chips is realized through its commitment to a steady stream of research and development projects that allows the company to continually explore the technological boundaries of electrical and computer engineering.

3. Projects are responsible for the newest and most improved products, services, and organi- zational processes. Projects are tools for innovation. Because they complement (and often transform) traditional process-oriented activities, many companies rely on projects as vehi- cles for going beyond conventional activities. Projects are the stepping-stones by which we move forward.

4. Projects provide a philosophy and strategy for the management of change. “Change” is an abstract concept until we establish the means by which we can make real alterations in the things we do and produce. Projects allow organizations to go beyond simple statements of intent and to achieve actual innovation. For example, whether it is Chevrolet’s Volt electric car or Apple’s newest iPhone upgrade, successful organizations routinely ask for customer input and feedback to better understand their likes and dislikes. As the vehicle of change, the manner in which a company develops its projects has much to say about its ability to inno- vate and commitment to change.

5. Project management entails crossing functional and organizational boundaries. Projects epitomize internal organizational collaboration by bringing together people from various functions across the company. A project aimed at new product development may require the combined work of engineering, finance, marketing, design, and so forth. Likewise, in the global business environment, many companies have crossed organizational boundaries by forming long-term partnerships with other firms in order to maximize opportunities while emphasizing efficiency and keeping a lid on costs. Projects are among the most common means of promoting collaboration, both across functions and across organizations.

6. The traditional management functions of planning, organizing, motivation, directing, and control apply to project management. Project managers must be technically well versed,

1.1 What Is a Project? 7

proficient at administrative functions, willing and able to assume leadership roles, and, above all, goal-oriented: The project manager is the person most responsible for keeping track of the big picture. The nature of project management responsibilities should never be underestimated because these responsibilities are both diverse and critical to project success.

7. The principal outcomes of a project are the satisfaction of customer requirements within the constraints of technical, cost, and schedule objectives. Projects are defined by their limitations. They have finite budgets, definite schedules, and carefully stated specifica- tions for completion. For example, a term paper assignment in a college class might include details regarding form, length, number of primary and secondary sources to cite, and so forth. Likewise, in the Disney’s Expedition Everest case example at the end of the chapter, the executive leading the change process established clear guidelines regarding performance expectations. All these constraints both limit and narrowly define the focus of the project and the options available to the project team. It is the very task of managing successful project development within such specific constraints that makes the field so challenging.

8. Projects are terminated upon successful completion of performance objectives—or earlier in their life cycle, if results no longer promise an operational or strategic advantage. As we have seen, projects differ from conventional processes in that they are defined by limited life cycles. They are initiated, completed, and dissolved. As important alternatives to conven- tional organizational activities, they are sometimes called “temporary organizations.”12

Projects, then, differ from better-known organizational activities, which often involve repetitive processes. The traditional model of most firms views organizational activities as consistently performing a discrete set of activities. For example, a retail-clothing establishment buys, stocks, and sells clothes in a continuous cycle. A steel plant orders raw materials, makes steel, and ships finished products, again in a recurring cycle. The nature of these operations focuses our atten- tion on a “process orientation,” that is, the need to perform work as efficiently as possible in an ongoing manner. When its processes are well understood, the organization always seeks better, more efficient ways of doing the same essential tasks. Projects, because they are discrete activities, violate the idea of repetition. They are temporary activities that operate outside formal channels. They may bring together a disparate collection of team members with different kinds of functional expertise. Projects function under conditions of uncertainty, and usually have the effect of “shaking up” normal corporate activities. Because of their unique characteristics, they do not conform to common standards of operations; they do things differently and often reveal new and better ways of doing things. Table 1.1 offers some other distinctions between project-based work and the more traditional, process-based activities. Note a recurring theme: Projects operate in radical ways that consistently violate the standard, process-based view of organizations.

Consider Apple’s development of the iPod, a portable MP3 player that can be integrated with Apple’s popular iTunes site to record and play music downloads. Apple, headed by its former chairman, the late Steven Jobs, recognized the potential in the MP3 market, given the enormous popularity (and, some would say, notoriety) of file-sharing and downloading music through

table 1.1 Differences Between Process and Project Management13

Process Project

Repeat process or product New process or product Several objectives One objective Ongoing One shot—limited life People are homogenous More heterogeneous Well-established systems in place to integrate efforts Systems must be created to integrate efforts Greater certainty of performance, cost, schedule Greater uncertainty of performance, cost, schedule Part of line organization Outside of line organization Bastions of established practice Violates established practice Supports status quo Upsets status quo

Source: R. J. Graham. (1992). “A Survival Guide for the Accidental Project Manager,” Proceedings of the Annual Project Management Institute Symposium. Drexel Hill, PA: Project Management Institute, pp. 355–61. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

8 Chapter 1 • Introduction

the Internet. The company hoped to capitalize on the need for a customer-friendly MP3 player, while offering a legitimate alternative to illegal music downloading. Since its introduction in 2003, consumers have bought nearly 400 million iPods and purchased more than 25 billion songs through Apple’s iTunes online store. In fact, Apple’s iTunes division is now the largest U.S. market for music sales, accounting for 29% of all music sold in the United States and 64% of the digital music market.

In an interview, Jobs acknowledged that Apple’s business needed some shaking up, given the steady but unspectacular growth in sales of its flagship Macintosh personal computer, still holding approximately 13% of the overall PC market. The iPod, as a unique venture within Apple, became a billion-dollar business for the company in only its second year of existence. So popular has the iPod become for Apple that the firm created a separate business unit, moving the product and its support staff away from the Mac group. “Needless to say, iPod has become incredibly popular, even among people who aren’t diehard Apple fanatics,” industry analyst Paolo Pescatore told NewsFactor, noting that Apple recently introduced a smaller version of the product with great success. “In short, they have been very successful thus far, and I would guess they are looking at this realignment as a way to ensure that success will continue.”14

A similar set of events are currently unfolding, centered on Apple’s introduction and succes- sive upgrades of its iPad tablet. Among the numerous features offered by the iPad is the ability to download books (including college textbooks) directly from publishers, effectively eliminating the traditional middlemen—bookstores—from the process. So radical are the implications of the iPad that competitors have introduced their own models (such as Samsung’s Galaxy tablet) to capture a share of this market. Meanwhile, large bookstores are hoping to adapt their business models to the new electronic reality of book purchase by offering their own readers (for example, Kindle for Amazon). Some experts are suggesting that within a decade, tablets and other electronic readers will make traditional books obsolete, capturing the majority of the publishing market. These are just some examples of the way that project-driven technological change, such as that at Apple, is reshaping the competitive landscape.

Given the enthusiasm with which project management is being embraced by so many orga- nizations, we should note that the same factors that make project management a unique undertak- ing are also among the main reasons why successful project management is so difficult. The track record of project management is by no means one of uninterrupted success, in part because many companies encounter deep-rooted resistance to the kinds of changes needed to accommodate a “project philosophy.” Indeed, recent research into the success rates for projects offers some grim conclusions:

• A study of more than 300 large companies conducted by the consulting firm Peat Marwick found that software and/or hardware development projects fail at the rate of 65%. Of compa- nies studied, 65% reported projects that went grossly over budget, fell behind schedule, did not perform as expected, or all of the above. Half of the managers responding indicated that these findings were considered “normal.”15

• A study by the META Group found that “more than half of all (information technology) IT projects become runaways—overshooting their budgets and timetables while failing to deliver fully on their goals.”16

• Joe Harley, the Chief Information Officer at the Department for Work and Pensions for the UK government, stated that “only 30%” of technology-based projects and programs are a success—at a time when taxes are funding an annual budget of £14bn (over $22 billion) on public sector IT, equivalent to building 7,000 new primary schools or 75 hospitals a year.17

• The United States Nuclear Security Administration has racked up $16 billion in cost over- runs on 10 major projects that are a combined 38 years behind schedule, the Government Accountability Office reports. For example, at Los Alamos National Laboratory, a seven-year, $213 million upgrade to the security system that protects the lab’s most sensitive nuclear bomb-making facilities does not work. A party familiar with the organization cites a “perva- sive culture of tolerating the intolerable and accepting the unacceptable.”18

• According to the 2004 PriceWaterhouseCoopers Survey of 10,640 projects valued at $7.2 billion, across a broad range of industries, large and small, only 2.5% of global businesses achieved 100% project success, and more than 50% of global business projects failed. The Chaos Summary 2013 survey by The Standish Group reported similar findings: The majority of all projects were

1.2 Why Are Projects Important? 9

either “challenged” (due to late delivery, being over budget, or delivering less than required features) or “failed” and were canceled prior to completion, or the product developed was never used. Researchers have concluded that the average success rate of business-critical application development projects is 39%. Their statistics have remained remarkably steady since 1994.19

• The Special Inspector General for Iraq Reconstruction (SIGIR) reported that more than $8 billion of the $53 billion the Pentagon spent on thousands of Iraqi reconstruction projects was lost due to “fraud, waste, and abuse.” Hundreds were eventually canceled, with 42% of the terminated projects ended because of mismanagement or shoddy construction. As part of their final 2013 report, SIGIR noted: “We found that incomplete and unstandardized databases left us unable to identify the specific use of billions of dollars spent on projects.”20

These findings underscore an important point: Although project management is becoming popular, it is not easy to assimilate into the conventional processes of most firms. For every firm discovering the benefits of projects, many more underestimate the problems involved in becoming “project savvy.”

These studies also point to a core truth about project management: We should not overesti- mate the benefits to be gained from project management while underestimating the commitment required to make a project work. There are no magic bullets or quick fixes in the discipline. Like any other valuable activity, project management requires preparation, knowledge, training, and commitment to basic principles. Organizations wanting to make use of project-based work must recognize, as Table 1.1 demonstrates, that its very strength often causes it to operate in direct con- tradiction to standard, process-oriented business practices.

1.2 Why are Projects imPortant?

There are a number of reasons why projects and project management can be crucial in helping an organization achieve its strategic goals. David Cleland, a noted project management researcher, suggests that many of these reasons arise from the very pressures that organizations find them- selves facing.21

1. Shortened product life cycles. The days when a company could offer a new product and depend on having years of competitive domination are gone. Increasingly, the life cycle of new products is measured in terms of months or even weeks, rather than years. One has only to look at new products in electronics or computer hardware and software to observe this trend. Interestingly, we are seeing similar signs in traditional service-sector firms, which also have recognized the need for agility in offering and upgrading new services at an increas- ingly rapid pace.

2. Narrow product launch windows. Another time-related issue concerns the nature of oppor- tunity. Organizations are aware of the dangers of missing the optimum point at which to launch a new product and must take a proactive view toward the timing of product intro- ductions. For example, while reaping the profits from the successful sale of Product A, smart firms are already plotting the best point at which to launch Product B, either as a product upgrade or a new offering. Because of fierce competition, these optimal launch opportunities are measured in terms of months. Miss your launch window, even by a matter of weeks, and you run the risk of rolling out an also-ran.

3. Increasingly complex and technical products. It has been well-documented that the average automobile today has more computing power than the Apollo 11 space capsule that allowed astronauts to walk on the moon. This illustrates a clear point: the world today is complex. Products are complicated, technically sophisticated, and difficult to produce efficiently. The public’s appetite for “the next big thing” continues unabated and substantially unsatisfied. We want the new models of our consumer goods to be better, bigger (or smaller), faster, and more complex than the old ones. Firms constantly upgrade product and service lines to feed this demand. That causes multiple problems in design and production as we continually seek to push the technical limits. Further, in anticipating future demand, many firms embark on expensive programs of research and development while attempting to discern con- sumer tastes. The effect can be to erroneously create expensive and technically sophisticated

10 Chapter 1 • Introduction

projects that we assume the customer will want. For example, Rauma Corporation of Finland developed a state-of-the-art “loader” for the logging industry. Rauma’s engineers loaded the product with the latest computerized gadgetry and technologies that gave the machine a space-age feel. Unfortunately, the chief customer for the product worked in remote regions of Indonesia, with logistics problems that made servicing and repairing the loaders impracti- cal. Machines that broke down had to be airlifted more than 1,000 miles to service centers. Since the inception of this project, sales of the logging machinery have been disappointing. The project was an expensive failure for Rauma and serves to illustrate an important point: Unless companies find a way to maintain control of the process, an “engineering for engi- neering’s sake” mentality can quickly run out of control.22

4. Global markets. The early twenty-first century has seen the emergence of enormous new markets for almost every type of product and service. Former closed or socialist societies, as well as rapidly developing economies such as Brazil, China, Vietnam, and India, have added huge numbers of consumers and competitors to the global business arena. The increased glo- balization of the economy, coupled with enhanced methods for quickly interacting with cus- tomers and suppliers, has created a new set of challenges for business. These challenges also encompass unique opportunities for those firms that can quickly adjust to this new reality. In the global setting, project management techniques provide companies with the ability to link multiple business partners, and respond quickly to market demand and supplier needs, while remaining agile enough to anticipate and respond to rapid shifts in consumer tastes. Using project management, successful organizations of the future will recognize and learn to rapidly exploit the prospects offered by a global business environment.

5. An economic period marked by low inflation. One of the key indicators of economic health is the fact that inflation has been kept under control. In most of the developed Western econo- mies, low inflation has helped to trigger a long period of economic expansion, while also helping provide the impetus for emerging economies, such as those in India and China, to expand rapidly. Unfortunately, low inflation also limits the ability of businesses to maintain profitability by passing along cost increases. Companies cannot continue to increase profit margins through simply raising prices for their products or services. Successful firms in the future will be those that enhance profits by streamlining internal processes—those that save money by “doing it better” than the competition. As a tool designed to realize goals like inter- nal efficiency, project management is a means by which to bolster profits.

These are just some of the more obvious challenges facing business today. The key point is that the forces giving rise to these challenges are not likely to abate in the near future. In order to meet these challenges, large, successful companies such as General Electric, 3M, Apple, Samsung, Bechtel, and Microsoft have made project management a key aspect of their operating philosophies.

Project Profile

“throwing Good Money after Bad”: the BBc’s Digital Media initiative

The British Broadcasting Corporation (BBC) recently announced the cancelation of a major Information Technology (IT) project intended to update their vast broadcast operations. The project, called the Digital Media Initiative (DMI), was originally budgeted at £81.7 million ($140 million) and was developed to eliminate the outdated filing systems and use of old-fashioned, analog videotape with its expensive archival storage. The BBC is one of the world’s largest and most widely recognized news and media organizations; it is publically funded and under British government oversight. The DMI project was intended to save the organization millions annually by eliminating the cost of expensive and out- dated storage facilities, while moving all media content to a modern, digital format. As an example of a large-scale IT project, the plan for DMI involved media asset management, archive storage and retrieval systems, and media sharing capabilities.

The DMI project was begun in 2008 when the BBC contracted with technology service provider Siemens, with consulting expertise to be provided by Deloitte. Interestingly, the BBC never put the contract out for competitive bid- ding, reasoning that it already had a 10-year support contract with Siemens and trusted Siemens’ judgment on project development. As part of this “hands-off” attitude, executives at the BBC gave Siemens full control of the project, and

1.2 Why Are Projects Important? 11

apparently little communication flowed back and forth between the organizations. The BBC finally grew concerned with the distant relationship that was developing between itself and the contractor when Siemens began missing important delivery milestones and encountering technical difficulties. After one year, the BBC terminated its $65 million contract with Siemens and sued the company for damages, collecting approximately $47 million in a court settlement. Still, losing nearly $20 million in taxpayer money after only one year, with nothing to show for it, did not bode well for the future.

Having been burned by this relationship with an outside contractor, the BBC next tried to move the project “in house,” assigning its own staff and project manager to continue developing the DMI. The project was under the overall control of the BBC’s Chief Technology Officer, John Linwood. It was hoped that the lessons learned from the first-round failure of the project would help improve the technology and delivery of the system throughout the organization. Unfortunately, the project did no better under BBC control. Reports started surfacing as early as 2011 that the project was way behind schedule, was not living up to its promises, and, in fact, had been failing most testing along the way. However, although there are claims that the BBC was well aware of the flaws in the project as early as 2011, the picture it presented to the outside world, including Parliamentary oversight committees, was relentlessly upbeat. The BBC’s Director General, Mark Thompson, appeared before a committee in 2011 and told them DMI was definitely on schedule and was actually working already: “There are many programs that are already being made with DMI and some have gone to air and are going to air,” he told Members of Parliament.

The trouble was, the project was not working well at all. Continual failures with the technology were widely known within the project team and company executives, but reports suggest that concerns were buried under a flood of rosy projections. In fact, a later report on the project by an outside consulting firm suggests that throughout 2012, the deteriorating fortunes of DMI were not accurately reported either within management or, critically, to the BBC Trust. For example, the BBC’s own internal project management office issued a “code red” warning of imminent project failure in February that wasn’t reported to the trust until six months later. The CTO, John Linwood, maintained that the project did work, would lead to a streamlined and more cost-effective method for producing media, and did not waver from that view throughout these years.

This rosy view hid a deeper problem: the technology just was not working well. Different views emerged as to why DMI was not progressing. To the “technologists,” there was nothing wrong with the system; it did deliver work- ing technology, but the project was undermined by would-be users who never bought into the original vision and who continually changed their requirements. They believed that DMI was failing not because it did not work, but as a result of internal politics. On the other side were those who questioned the development of the project because the technology, whether it had been “delivered” or not, never really worked, certainly not at the scale required to make it adopted across the whole organization. Further, it was becoming evident that off-the-shelf technology existed in the marketplace which did some of what DMI promised but which, critically, already worked well. Why, then, was the BBC spending so much time and money trying to create its own system out of thin air?

Figure 1.2 BBc Digital initiative Project

Source: Roberto Herrett/Loop Images/Corbis (continued)

12 Chapter 1 • Introduction

Project management also serves as an excellent training ground for future senior executives in most organizations. One unique aspect of projects is how they blend technical and behavioral chal- lenges. The technical side of project management requires managers to become skilled in project selection, budgeting and resource management, planning and scheduling, and tracking projects. Each of these skills will be discussed in subsequent chapters. At the same time, however, project managers face the equally strong challenge of managing the behavioral, or “people,” side of proj- ects. Projects, being temporary endeavors, require project managers to bring together individuals from across the organization, quickly mold them into an effective team, manage conflict, provide leadership, and engage in negotiation and appropriate political behavior, all in the name of project success. Again, we will address these behavioral challenges in this text. One thing we know is: Project managers who emphasize one challenge and ignore the other, whether they choose to focus on the technical or behavioral side of project management, are not nearly as successful as those who seek to become experts in both. Why is project management such a useful training ground for senior executives? Because it provides the first true test of an individual’s ability to master both the technical and human challenges that characterize effective leaders in business. Project managers, and their projects, create the kind of value that companies need to survive and prosper.

According to a news report, it was not until April 2013 that events demonstrated the ongoing problems with DMI. During BBC coverage of the death and funeral of Margaret Thatcher, news staff worked feverishly to transfer old archived analog videotape to digital format in order to produce footage for background on the life and career of the former Prime Minister. So poorly did the new digital archive system work that it was reported that tapes had to be physically transported around London by taxi and subway system to get to their locations while video transfer work was being carried out by private production companies. All this after nearly four years working to develop DMI!

The failure of the system during Thatcher’s funeral was the final straw. In May 2013 the new Director General of the BBC, Lord Hall, announced the cancellation of the project and that the BBC’s chief technology officer, John Linwood, was to be suspended pending an external investigation into the management of the DMI project. It was later revealed that a senior BBC manager had expressed grave doubts about DMI to BBC Chairman Lord Patten one year before the project was cancelled. He had also claimed that there was a “very significant risk” that the National Audit Office had been misled about the actual progress of DMI in 2011. Other BBC executives had also voiced similar concerns for about two years before DMI was abandoned. The final cost of the project to the BBC and British taxpayers has been estimated at about $160 million. BBC Trust member Anthony Fry remarked that the DMI had been a “complete catastrophe” and said that the project was “probably the most serious, embarrassing thing I have ever seen.”

Members of Parliament, looking into the failure of DMI, also had a number of very pointed criticisms of the project, executive oversight of DMI, and the operations of the BBC in general. Margaret Hodge MP, Chair of the Committee of Public Accounts, summed up the project in her Parliament report:

“The BBC’s Digital Media Initiative was a complete failure. License fee payers paid nearly £100 million ($160 million) for this supposedly essential system but got virtually nothing in return.

The main output from the DMI is an archive catalogue and ordering system that is slower and more cumbersome than the 40-year-old system it was designed to replace. It has only 163 regular users and a running cost of £3 million ($5.1 million) a year, compared to £780,000 ($1.3 million) a year for the old system.

When my Committee examined the DMI’s progress in February 2011, the BBC told us that the DMI was “an abso- lutely essential have to have” and that a lot of the BBC’s future was tied up in the successful delivery of the DMI.

The BBC also told us that it was using the DMI to make many programs and was on track to complete the system in 2011 with no further delays. This turned out not to be the case.

The BBC was far too complacent about the high risks involved in taking it in-house. No single individual had overall responsibility or accountability for delivering the DMI and achieving the benefits, or took ownership of problems when they arose.

Lack of clearly defined responsibility and accountability meant the Corporation failed to respond to warning sig- nals that the program was in trouble.”

Bad planning, poor corporate governance, excessively optimistic projections, and a cloak of secrecy regarding the real status of the Digital Media Initiative project all resulted in a very public black eye for one of the most respected broadcasting organizations in the world. It is likely that the causes of the failure of the DMI project will be debated for years to come, but at a minimum this story should be a cautionary tale for organizations developing sophisticated IT projects.23

1.3 Project Life Cycles 13

1.3 Project liFe cycles

Imagine receiving a term paper assignment in a college class. Our first step would be to develop a sense of the assignment itself—what the professor is looking for, how long the paper should be, the number of references required, stylistic expectations, and so forth. Once we have familiarized our- selves with the assignment, our next step would be to develop a plan for how we intend to proceed with the project in order to complete it by the due date. We make a rough guess about how much time will be needed for the research, writing the first draft, proofreading the paper, and completing the final draft; we use this information to create some tentative milestones for the various compo- nents of the assignment. Next, we begin to execute our plan, doing the library or online research, creating an outline, writing a draft, and so forth. Our goal is to complete the assignment on time, doing the work to our best possible ability. Finally, after turning in the paper, we file or discard our reference materials, return any books to the library, breathe a sigh of relief, and wait for the grade.

This example represents a simplified but useful illustration of a project’s life cycle. In this case, the project consisted of completing the term paper to the standards expected of the instructor in the time allowed. A project life cycle refers to the stages in a project’s development. Life cycles are important because they demonstrate the logic that governs a project. They also help us develop our plans for carrying out the project. They help us decide, for example, when we should devote resources to the project, how we should evaluate its progress, and so forth. Consider the simplified model of the project life cycle shown in Figure 1.3, which divides the life cycle into four distinct phases: conceptualization, planning, execution, and termination.

• Conceptualization refers to the development of the initial goal and technical specifications for a project. The scope of the work is determined, necessary resources (people, money, physical plant) identified, and important organizational contributors or stakeholders signed on.

• Planning is the stage in which all detailed specifications, schematics, schedules, and other plans are developed. The individual pieces of the project, often called work packages, are bro- ken down, individual assignments made, and the process for completion clearly delineated. For example, in planning our approach to complete the term paper, we determine all the necessary steps (research, drafts, editing, etc.) in the process.

• During execution, the actual “work” of the project is performed, the system developed, or the product created and fabricated. It is during the execution phase that the bulk of project team labor is performed. As Figure 1.3 shows, project costs (in man hours) ramp up rapidly during this stage.

• Termination occurs when the completed project is transferred to the customer, its resources reassigned, and the project formally closed out. As specific subactivities are completed, the project shrinks in scope and costs decline rapidly.

These stages are the waypoints at which the project team can evaluate both its performance and the project’s overall status. Remember, however, that the life cycle is relevant only after the proj- ect has actually begun. The life cycle is signaled by the actual kickoff of project development,

Conceptualization Planning Execution Termination

Man-hours of work

Figure 1.3 Project life cycle Stages

14 Chapter 1 • Introduction

the development of plans and schedules, the performance of necessary work, and the comple- tion of the project and reassignment of personnel. When we evaluate projects in terms of this life cycle model, we are given some clues regarding their subsequent resource requirements; that is, we begin to ask whether we have sufficient personnel, materials, and equipment to support the project. For example, when beginning to work on our term paper project, we may discover that it is necessary to purchase a PC or hire someone to help with researching the topic. Thus, as we plan the project’s life cycle, we acquire important information regarding the resources that we will need. The life cycle model, then, serves the twofold function of project timing (schedule) and proj- ect requirements (resources), allowing team members to better focus on what and when resources are needed.

The project life cycle is also a useful means of visualizing the activities required and chal- lenges to be faced during the life of a project. Figure 1.4 indicates some of these characteristics as they evolve during the course of completing a project.24 As you can see, five components of a proj- ect may change over the course of its life cycle:

• Client interest: The level of enthusiasm or concern expressed by the project’s intended cus- tomer. clients can be either internal to the organization or external.

• Project stake: The amount of corporate investment in the project. The longer the life of the project, the greater the investment.

• Resources: The commitment of financial, human, and technical resources over the life of the project.

• Creativity: The degree of innovation required by the project, especially during certain development phases.

• Uncertainty: The degree of risk associated with the project. Riskiness here reflects the number of unknowns, including technical challenges that the project is likely to face. Uncertainty is highest at the beginning because many challenges have yet to be identified, let alone addressed.

Each of these factors has its own dynamic. Client interest, for example, follows a “U-shaped” curve, reflecting initial enthusiasm, lower levels of interest during development phases, and renewed interest as the project nears completion. Project stake increases dramatically as the proj- ect moves forward because an increasing commitment of resources is needed to support ongoing activities. Creativity, often viewed as innovative thought or applying a unique perspective, is high at the beginning of a project, as the team and the project’s client begin developing a shared vision of the project. As the project moves forward and uncertainty remains high, creativity also contin- ues to be an important feature. In fact, it is not until the project is well into its execution phase, with defined goals, that creativity becomes less important. To return to our example of the term

Execution Termination




Project Stake

Client Interest


Intensity Level

Planning Concep- tualization

Figure 1.4 Project life cycles and their effects

Source: Victor Sohmen. (2002, July). “Project Termination: Why the Delay?” Paper presented at PMI Research Conference, Seattle, WA. Project Management Institute, Sohmen, Victor. “Project termination: Why the delay?” PMI Research Conference. Proceedings, p. 467–475. Paper presented at PMI Research Conference. Project Management Institute, Inc (2002). Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

1.3 Project Life Cycles 15

paper project, in many cases, the “creativity” needed to visualize a unique or valuable approach to developing the project is needed early, as we identify our goals and plan the process of achiev- ing them. Once identified, the execution phase, or writing the term paper, places less emphasis on creativity per se and more on the concrete steps needed to complete the project assignment.

The information simplified in Figure 1.4 is useful for developing a sense of the competing issues and challenges that a project team is likely to face over the life cycle of a project. Over time, while certain characteristics (creativity, resources, and uncertainty) begin to decrease, other ele- ments (client interest and project stake) gain in importance. Balancing the requirements of these elements across the project life cycle is just one of the many demands placed on a project team.

Figure 1.5 Stephanie Smith—Westinghouse electric

Source: Jeffrey Pinto/Pearson Education, Inc.

Box 1.1

Project Managers in Practice

Stephanie Smith, Westinghouse Electric Company

Stephanie Smith is a project manager in the nuclear industry, working for Westinghouse Electric Company while living in Phoenix, Arizona. She earned her undergraduate degree in Biological Sciences from the University of Pittsburgh and subsequently a master’s degree in Teaching. After teaching Biology and Environmental Sciences for four years, Stephanie decided on a career change and was hired as a Software Librarian at Westinghouse. Her job was to manage software created by multiple teams of engineers for use in nuclear power plants while also developing programmatic documentation such as program plans and program quality plans, document creation plans, and a program for technical editing of engineering documentation. After about a year of program-level support, she gained further experience working on large projects in nuclear protection and safety monitoring where, in addition to her other duties, she interacted with the members of the Nuclear Regulatory Commission.

As a project manager in the nuclear industry, the majority of the projects Stephanie has worked on are intended to perform first-of-a-kind engineering to develop products for use in nuclear power plants. This re- quires a strong technical skill set. However, Stephanie is quick to note that having the technical abilities alone does not prepare you for project management nor will it allow you to do your job to the best of your abilities. “Aside from the technical nature of this work, the majority of my effort is spent utilizing project management skills to develop and implement projects according to customer, internal quality, and regulatory requirements.” Communication skills are critical, Stephanie argues, as “I regularly interact with my project team, upper man- agement, and the customer to track project progress in terms of schedule, budget, and quality.”

Stephanie is responsible for ensuring that technical problems are resolved as efficiently as possible, which is one of her greatest challenges, given the industry and the need to thoroughly think through problems,


16 Chapter 1 • Introduction

1.4 determinants oF Project success

Definitions of successful projects can be surprisingly elusive.25 How do we know when a project is successful? When it is profitable? If it comes in on budget? On time? When the developed product works or sells? When we achieve our long-term payback goals? Generally speaking, any definition of project success must take into consideration the elements that define the very nature of a project: that is, time (schedule adherence), budget, functionality/quality, and customer satisfaction. At one time, managers normally applied three criteria of project success:

• Time. Projects are constrained by a specified time frame during which they must be com- pleted. They are not supposed to continue indefinitely. Thus the first constraint that governs project management involves the basic requirement: the project should come in on or before its established schedule.

• Budget. A second key constraint for all projects is a limited budget. Projects must meet bud- geted allowances in order to use resources as efficiently as possible. Companies do not write blank checks and hope for the best. Thus the second limit on a project raises the question: Was the project completed within budget guidelines?

• Performance. All projects are developed in order to adhere to some initially determined technical specifications. We know before we begin what the project is supposed to do or how the final product is supposed to operate. Measuring performance, then, means determining whether the finished product operates according to specifications. The project’s clients natu- rally expect that the project being developed on their behalf will work as expected. Applying this third criterion is often referred to as conducting a “quality” check.

This so-called triple constraint was once the standard by which project performance was routinely assessed. Today, a fourth criterion has been added to these three (see Figure 1.6):

• Client acceptance. The principle of client acceptance argues that projects are developed with customers, or clients, in mind, and their purpose is to satisfy customers’ needs. If cli- ent acceptance is a key variable, then we must also ask whether the completed project is

effectively manage risks, and make prudent decisions regarding the safety of the product, all with an eye to- ward satisfying customers and regulatory agencies. “Risks must be effectively managed, particularly in the nuclear industry, for cost and safety reasons; therefore, I am always conscious that decisions we make have to be within carefully laid-out standards of safety.” She is also responsible for contract management within her projects. This entails Stephanie working with customers and upper management to further define vague language in the contract so that work can be completed according to expectations. These meetings are also critical for project scope definition and control, skills project managers use on a daily basis.

“Without a strong foundation in project management fundamentals, I simply could not do my job,” Stephanie argues. “My daily work is centered on the ability to effectively implement both the hard and soft skills of project management (i.e., the technical and people-oriented behaviors). Strong communication and leadership skills are very important in my daily work. Not a day goes by that I am not receiving and transmitting information among upper management, my team, and the customer. My work is dynamic, and regardless of how much planning is done, unanticipated events come up, which is where the need for flexibility comes in. The resolution of these problems requires significant communication skills and patience.”

The greatest opportunity Stephanie sees in her work is supporting the development of clean energy worldwide. The nuclear industry has shed its old images and emerged in the current era as one of the cleanest and safest forms of energy. Nuclear power and project management are fast-growing and rapid- paced fields, and they require people interested in adapting to the unique challenges they offer. The work is demanding but, ultimately, highly rewarding. “In supporting a global effort for clean energy, I have the opportunity to work with very bright and energetic people, and I truly do learn something new every day. I encourage the novice or undergraduate to identify your greatest strengths, and try to develop a vision of how to apply those strengths to achieve the lifestyle you want. Do you see yourself in an office setting? Do you see yourself working in the field? One of the real advantages of project management careers is that they offer a level of flexibility and freedom that you rarely find in other office settings. Project management is challenging but the rewards can be impressive—both in terms of money and the satisfaction of seeing the results of your efforts.”

1.4 Determinants of Project Success 17

acceptable to the customer for whom it was intended. Companies that evaluate project suc- cess strictly according to the original “triple constraint” may fail to apply the most important test of all: the client’s satisfaction with the completed project.

We can also think of the criteria for project success in terms of “internal” versus “external” conditions. When project management was practiced primarily by construction and other heavy industries, its chief value was in maintaining internal organizational control over expenditures of money and time. The traditional triple-constraint model made perfect sense. It focused internally on efficiency and productivity measures. It provided a quantifiable measure of personnel evalua- tion, and it allowed accountants to control expenses.

More recently, however, the traditional triple-constraint model has come under increasing criticism as a measure of project success. The final product, for example, could be a failure, but if it has been delivered in time and on budget and satisfies its original specifications (however flawed), the project itself could still be declared a success. Adding the external criterion of client acceptance corrects such obvious shortcomings in the assessment process. First, it refocuses cor- porate attention outside the organization, toward the customer, who will probably be dissatisfied with a failed or flawed final product. Likewise, it recognizes that the final arbiter of project success is not the firm’s accountants, but rather the marketplace. A project is successful only to the extent that it benefits the client who commissioned it. Finally, the criterion of client acceptance requires project managers and teams to create an atmosphere of openness and communication throughout the development of the project.

Consider one example. In his book, What Customers Really Want, author Scott McKain relates how a coach bus company that transports music stars (i.e., clients either lease or purchase the com- pany’s buses) was originally planning to spend a great deal on a project to improve the interior of its vehicles because they believed that with these upgrades, customers would be willing to pay more to lease their buses. However, prior to starting a full-blown overhaul of their fleet, execu- tives decided to ask past customers what they thought about this plan. Surprisingly, the company found that while its customers did want nice interiors, the single most important factor in selecting a coach company was the bus driver (i.e., a “nice guy,” someone who could get the music stars to their destination safely, who would also serve as a good ambassador for the band with fans). Based on this information, the company dropped their original project and instead initiated a driver education program to teach their drivers how to communicate more effectively with customers and how to retain and grow customer goodwill. The company also started compensating drivers according to how well they served the customer and how well they cultivated long-term relation- ships with them. Once the company did that, it moved from fourth in the marketplace to first, and grew from 28 to 56 coaches.26

An additional approach to project assessment argues that another factor must always be taken into consideration: the promise that the delivered product can generate future opportunities, whether commercial or technical, for the organization.27 In other words, it is not enough to assess


Client Acceptance Budget

Time Performance

Figure 1.6 the New Quadruple constraint

18 Chapter 1 • Introduction

a project according to its immediate success. We must also evaluate it in terms of its commercial success as well as its potential for generating new business and new opportunities. Figure 1.7 illustrates this scheme, which proposes four relevant dimensions of success:

• Project efficiency: Meeting budget and schedule expectations. • Impact on customer: Meeting technical specifications, addressing customer needs, and cre-

ating a project that satisfies the client’s needs. • Business success: Determining whether the project achieved significant commercial success. • Preparing for the future: Determining whether the project opened new markets or new

product lines or helped to develop new technology.

This approach challenges the conventional triple-constraint principle for assessing project success. Corporations expect projects not only to be run efficiently (at the least) but also to be developed to meet customer needs, achieve commercial success, and serve as conduits to new business opportunities. Even in the case of a purely internal project (e.g., updating the software for a firm’s order-entry system), project teams need to focus both on customer needs and an assess- ment of potential commercial or technical opportunities arising from their efforts.

A final model, offered recently, also argues against the triple-constraint model as a measure of project success. According to Atkinson,29 all groups that are affected by a project (stakeholders) should have a hand in assessing its success. The context and type of a project may also be relevant in specifying the criteria that will most clearly define its success or failure. Table 1.2 shows the Atkinson


Project Completion

1 Project


2 Impact on the


3 Business Success

4 Preparing for

the Future


Figure 1.7 four Dimensions of Project Success importance

Source: A. J. Shenhar, O. Levy, and D. Dvir. (1997). “Mapping the Dimensions of Project Success,” Project Management Journal, 28(2): 12. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

table 1.2 Understanding Success criteria

iron triangle information System Benefits (organization) Benefits (Stakeholders)

Cost Maintainability Improved efficiency Satisfied users

Quality Reliability Improved effectiveness Social and environmental impact

Time Validity Increased profits Personal development

Information quality Strategic goals Professional learning, contractors’ profits

Use Organization learning Capital suppliers, content

Reduced waste Project team, economic impact to surrounding community

1.5 Developing Project Management Maturity 19

Box 1.2

Project Management research in Brief

Assessing Information Technology (IT) Project Success

As noted earlier in this chapter, IT projects have a notoriously checkered history when it comes to successful implementation. Part of the problem has been an inability to define the characteristics of a successful IT proj- ect in concrete terms. The criteria for IT project success are often quite vague, and without clear guidelines for project success, it is hardly any wonder that so many of these projects do not live up to predevelopment expectations. In 1992 and again in 2003, two researchers, W. DeLone and E. McLean, analyzed several previ- ous studies of IT projects to identify the key indicators of success. Their findings, synthesized from previous research, suggest that, at the very least, IT projects should be evaluated according to six criteria:

• System quality. The project team supplying the system must be able to assure the client that the implemented system will perform as intended. All systems should satisfy certain criteria: They should, for example, be easy to use, and they should supply quality information.

• Information quality. The information generated by the implemented IT must be the information required by users and be of sufficient quality that it is “actionable”: In other words, generated informa- tion should not require additional efforts to sift or sort the data. System users can perceive quality in the information they generate.

• Use. Once installed, the IT system must be used. Obviously, the reason for any IT system is its useful- ness as a problem-solving, decision-aiding, and networking mechanism. The criterion of “use” assesses the actual utility of a system by determining the degree to which, once implemented, it is used by the customer.

• User satisfaction. Once the IT system is complete, the project team must determine user satisfaction. One of the thorniest issues in assessing IT project success has to do with making an accurate determina- tion of user satisfaction with the system. Yet, because the user is the client and is ultimately the arbiter of whether or not the project was effective, it is vital that we attain some measure of the client’s satis- faction with the system and its output.

• Individual impact. All systems should be easy to use and should supply quality information. But beyond satisfying these needs, is there a specific criterion for determining the usefulness of a system to the client who commissioned it? Is decision making faster or more accurate? Is information more retrievable, more affordable, or more easily assimilated? In short, does the system benefit users in the ways that are most important to those users?

• Organizational impact. Finally, the supplier of the system must be able to determine whether it has a positive impact throughout the client organization. Is there, for example, a collective or synergistic effect on the client corporation? Is there a sense of good feeling, or are there financial or operational metrics that demonstrate the effectiveness or quality of the system?

DeLone and McLean’s work provides an important framework for establishing a sense of IT project suc- cess. Companies that are designing and implementing IT systems must pay early attention to each of these criteria and take necessary steps to ensure that the systems that they deliver satisfy them.28

model, which views the traditional “iron triangle” of cost, quality, and time as merely one set of com- ponents in a comprehensive set of measures. Of course, the means by which a project is to be mea- sured should be decided before the project is undertaken. A corporate axiom, “What gets measured, gets managed,” suggests that when teams understand the standards to which a project is being held, they will place more appropriate emphases on the various aspects of project performance. Consider, for example, an information system setting. If the criteria of success are improved operating effi- ciency and satisfied users, and if quality is clearly identified as a key benefit of the finished product, the team will focus its efforts more strongly on these particular aspects of the project.

1.5 develoPing Project management maturity

With the tremendous increase in project management practices among global organizations, a recent phenomenon has been the rise of project maturity models for project management orga- nizations. Project management maturity models are used to allow organizations to benchmark the best practices of successful project management firms. Project management maturity models recognize that different organizations are currently at different levels of sophistication in their best

20 Chapter 1 • Introduction

practices for managing projects. For example, it would be reasonable to expect an organization such as Boeing (aircraft and defense systems) or Fluor-Daniel (industrial construction) to be much more advanced in how they manage projects, given their lengthy histories of project initiatives, than a company that has only recently developed an emphasis on project-based work.

The purpose of benchmarking is to systematically manage the process improvements of proj- ect delivery by a single organization over a period of time.30 Because there are many diverse dimen- sions of project management practice, it is common for a new organization just introducing project management to its operations to ask, “Where do we start?” That is, which of the multiple project management processes should we investigate, model, and apply to our organization? Maturity mod- els provide the necessary framework to first, analyze and critically evaluate current practices as they pertain to managing projects; second, compare those practices against those of chief competitors or some general industry standard; and third, define a systematic route for improving these practices.

If we accept the fact that the development of better project management practices is an evo- lutionary process, involving not a sudden leap to top performance but rather a systematic commit- ment to continuous improvement, maturity models offer the template for defining and then achiev- ing such progressive improvement.31 As a result, most effective project maturity models chart both a set of standards that are currently accepted as state-of-the-art as well as a process for achieving significant movement toward these benchmarks. Figure 1.8 illustrates one approach to defining current project management practices a firm is using.32 It employs a “spider web” methodology in which a set of significant project management practices have first been identified for organizations within a specific industry. In this example, a firm may identify eight components of project man- agement practice that are key for success, based on an analysis of the firm’s own needs as well as through benchmarking against competing firms in the industry. Note that each of the rings in the diagram represents a critical evaluation of the manner in which the organization matches up with industry standards. Suppose we assigned the following meanings to the different ratings:

ring level Meaning

0 Not defined or poor

1 Defined but substandard

2 Standardized

3 Industry leader or cutting edge




Project Scheduling

Control Practices

Coaching, Auditing, and Evaluating Projects

Portfolio Management

Structural Support for Project Management

Personnel Development for Projects

Networking Between Projects

Project Stakeholder Management


Figure 1.8 Spider Web Diagram for Measuring Project Maturity

Source: R. Gareis. (2001). “Competencies in the Project-Oriented Organization,” in D. Slevin, D. Cleland, and J. Pinto, The Frontiers of Project Management Research. Newtown Square, PA: Project Management Institute, pp. 213–24, figure on p. 216. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

1.5 Developing Project Management Maturity 21

Following this example, we may decide that in terms of project team personnel develop- ment or project control systems, our practices are poor relative to other competitors and rate those skills as 0. On the other hand, perhaps our scheduling processes are top-notch, enabling us to rate them as a 3. Figure 1.9 shows an example of the same spider web diagram with our relative skill levels assigned across the eight key elements of project management we have defined. This exercise helps us to form the basis for where we currently are in terms of project management sophistication, a key stage in any maturity model in which we seek to move to a higher level.

Once we have established a sense of our present project management abilities, as well as our shortcomings, the next step in the maturity model process is to begin charting a step-by-step, incre- mental path to our desired goal. Table 1.3 highlights some of the more common project maturity models and the interim levels they have identified en route to the highest degree of organization- wide project expertise. Several of these models were developed by private project management consultancies or professional project organizations.

It is interesting to compare and contrast the four maturity models highlighted in Table 1.3. These examples of maturity models are taken from the most well-known models in the field, including Carnegie Mellon University’s Software Engineering Institute’s (SEI) Capability Maturity Model, Harold Kerzner’s Maturity Model, ESI International’s Project Framework, and the maturity model developed by the Center for Business Practices.33 Illustrating these dimensions in pyramid form, we can see the progression toward project management maturity (Figure 1.10). Despite some differences in terminology, a clear sense of pattern exists among these models. Typically they start with the assumption that project management practices within a firm are not planned and are not collectively employed; in fact, there is likely no common lan- guage or methods for undertaking project management. As the firm grows in project maturity, it begins to adopt common practices, starts programs to train cadres of project management professionals, establishes procedures and processes for initiating and controlling its projects, and so forth. Finally, by the last stage, not only is the organization “project-savvy,” but it also has progressed beyond simply applying project management to its processes and is now actively exploring ways to continuously improve its project management techniques and procedures. It is during the final stage that the organization can be truly considered “project mature”; it has internalized all necessary project management principles and is actively seeking to move beyond them in innovative ways.




Project Scheduling

Control Practices

Coaching, Auditing, and Evaluating Projects

Portfolio Management

Structural Support for Project Management

Personnel Development for Projects

Networking Between Projects

Project Stakeholder Management


Figure 1.9 Spider Web Diagram with embedded organizational evaluation

Source: R. Gareis. (2001). “Competencies in the Project-Oriented Organization,” in D. Slevin, D. Cleland, and J. Pinto, The Frontiers of Project Management Research. Newtown Square, PA: Project Management Institute, pp. 213–24, figure on p. 216. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

ta b

le 1


A c

o m

p ar

is o

n o

f Pr

o je

ct M

at u

ri ty

M o

d el

s an

d in

cr em

en ta

l S ta

g es

c en

te r

fo r

B u

si n

es s

Pr ac

ti ce


Le ve

l 1 : I

ni tia

l P ro

ce ss

• A

d ho

c pr

oc es

s •

M an

ag em

en t

aw ar

en es


Le ve

l 2 : S

tr uc

tu re

, P ro

ce ss

, a nd


an da

rd s

• Ba

si c

pr oc

es se

s, n

ot s

ta nd

ar d

on a

ll pr

oj ec

ts •

M an

ag em

en t

su pp

or ts

u se

• Es

tim at

es , s

ch ed

ul es

b as


on e

xp er

t kn

ow le

dg e

Le ve

l 3 : I

ns tit

ut io

na liz


Pr oj

ec t

M an

ag em

en t

• A

ll pr

oj ec

t pr

oc es

se s

ar e

re pe

at ab

le •

Es tim

at es

, s ch

ed ul

es b

as ed


in du

st ry

s ta

nd ar


Le ve

l 4 : M

an ag

ed •

Pr oj

ec t

m an

ag em

en t

pr ac

tic es


te gr

at ed

w ith

c or

po ra


pr oc

es se

s •

So lid

a na

ly si

s of

p ro

je ct


rf or

m an

ce •

Es tim

at es

, s ch

ed ul

es b

as ed


c or

po ra

te s

pe ci

fic s

Le ve

l 5 : O

pt im

iz in

g •

Pr oc

es se

s to

m ea

su re

p ro

je ct


fic ie

nc y

• Pr

oc es

se s

in p

la ce

t o

im pr

ov e

pr oj

ec t

pe rf

or m

an ce

• C

om pa

ny f

oc us

es o

n co

nt in

u- ou

s im

pr ov

em en


K er

zn er

’s P

ro je

ct M

an ag

em en

t M

at u

ri ty

M o

d el

Le ve

l 1 : C

om m

on L

an gu

ag e

• Sp

or ad

ic u

se o

f pr

oj ec

t m

an ag

em en

t •

Sm al

l p oc

ke ts

o f

in te

re st


t he

f irm

• N

o in

ve st

m en

t in



ai ni


Le ve

l 2 : C

om m

on P

ro ce

ss es

• Ta

ng ib

le b

en ef

its m

ad e

ap pa

re nt

• PM

s up

po rt

t hr

ou gh

ou t

th e

fir m

• D

ev el

op m

en t

of a



rr ic

ul um

Le ve

l 3 : S

in gu

la r

M et

ho do

lo gy

• In

te gr

at ed

p ro

ce ss

es •

C ul

tu ra

l a nd

m an

ag em

en t

su pp

or t

• Fi

na nc

ia l b

en ef

it fr

om P


tr ai

ni ng

Le ve

l 4 : B

en ch

m ar

ki ng

• A

na ly

si s

an d

ev al

ua tio

n of


ac tic

es •

Pr oj

ec t

of fic

e es

ta bl

is he


Le ve

l 5 : C

on tin

uo us


pr ov

em en

t •

Le ss

on s

le ar

ne d,

f ile

s cr

ea te

d •

K no

w le

dg e

tr an

sf er

b et

w ee

n te

am s

• M

en to

rs hi

p pr

og ra


eS i i

n te

rn at

io n

al ’s

P ro

je ct

f ra

m ew

o rk

Le ve

l 1 : A

d H

oc •

Pr oc

es se

s ill

-d ef

in ed

b e-

ca us

e th

ey a

re a

pp lie

d in

di vi

du al

ly •

Li tt

le s

up po

rt b

y or

ga ni

za tio


Le ve

l 2 : C

on si

st en

t •

O rg

an iz

at io

n is

w el

l i nt

en -

tio ne

d in

it s

m et

ho ds

• N

o pr

oj ec

t co

nt ro

l p ro

ce ss


or le

ss on

s le

ar ne


Le ve

l 3 : I

nt eg

ra te

d •

Pr oc

es se

s ar

e ta

ilo re

d to


ha nc

e al

l P M

a sp

ec ts

• C

om m

on u

se a


un de

rs ta

nd in

g of

m et

ho ds


ro ss

t he

f irm

Le ve

l 4 : C

om pr

eh en

si ve

• PM

f ul

ly im

pl em

en te

d ac

ro ss


e fir

m •

In fo

rm at

io n

is u

se d

to e

va lu

at e

pr oc

es se

s an

d re

du ce

v ar

ia tio

n •

A dv

an ce

d PM

t oo

ls a


te ch

ni qu

es a

re d

ev el

op ed

Le ve

l 5 : O

pt im

iz in

g •

C on

tin ua

l e ff

or t

to im

pr ov

e an

d in

no va

te p

ro je


ca pa

bi lit

y •

C om

m on

f ai

lu re

s ar

e el

im in

at ed

Se i’s

c ap

ab ili

ty M

at u

ri ty

M o

d el

in te

g ra

ti o


Le ve

l 1 : I

ni tia

l •

A d

ho c,

c ha

ot ic


oc es

se s

Le ve

l 2 : M

an ag

ed •

Re qu

ire m

en ts

m an

ag em

en t,


oj ec

t pl

an ni

ng , a

nd c

on tr


oc cu

r •

Pr oc

es s

qu al

ity a

ss ur

an ce


cu rs

• C

on fig

ur at

io n

m an

ag em

en t

is u

se d

Le ve

l 3 : D

ef in

ed •

Re qu

ire m

en ts

d ev

el op

m en

t an

d pr

od uc

t in

te gr

at io

n oc

cu r

• Ve

rif ic

at io

n an

d va

lid at

io n

of p

ro ce

ss es

• Ri

sk m

an ag

em en

t is


ph as

iz ed

Le ve

l 4 : Q

ua nt

ita tiv

e M

an ag

em en

t •

Pr oc

es s

pe rf

or m

an ce

is g

au ge

d •

Q ua

nt ita

tiv e

PM h

ig hl

ig ht


Le ve

l 5 : O

pt im

iz in

g •

In no

va tio

n an

d de

pl oy

m en

t ac

ce nt

ua te

d •

C au

sa l a

na ly

si s

an d

re so

lu -

tio n

oc cu



1.6 Project Elements and Text Organization 23

Project maturity models have become very useful in recent years precisely because they reflect the growing interest in project management while highlighting one of the recurring prob- lems: the lack of clear direction for companies in adopting, adapting, and improving these pro- cesses for optimal use. The key feature of these models is the important recognition that change typically does not occur abruptly; that is, companies that desire to become skilled in their project management approaches simply cannot progress in immediate steps from a lack of project man- agement understanding to optimal project practices. Instead, the maturity models illustrate that “maturity” is an ongoing process, based on continuous improvement through identifiable incre- mental steps. Once we have an accurate picture of where we fit into the maturity process, we can begin to determine a reasonable course of action to progress to our desired level. In this manner, any organization, no matter how initially unskilled in project management, can begin to chart a course toward the type of project organization it hopes to become.

1.6 Project elements and text organization

This text was written to provide a holistic, managerial-based approach to project management. The text is holistic in that it weaves together the wide variety of duties, responsibilities, and knowledge that successful project managers must acquire. Project management is a comprehensive and excit- ing undertaking. It requires us to understand aspects of management science in building sched- ules, assigning resources, monitoring and controlling our projects, and so forth. At the same time, successful project managers also must integrate fundamental issues of behavioral science, involv- ing knowledge of human beings, leadership practices, motivation and team development, conflict resolution, and negotiation skills. Truly, a “science-heavy” approach to this subject will make us no more successful in our future project management responsibilities than will a focus that retains an exclusively “people-based” outlook. Project management is an exciting and challenging blend of the science and art of management.

Figure 1.11 offers a model for the organization of this text. The figure is a Gantt chart, a proj- ect scheduling and control device that we will become more familiar with in Chapter 10. For now, however, we can apply it to the structure of this book by focusing on some of its simpler features. First, note that all chapters in the book are listed down the left-hand column. Across the bottom and running from left to right is a simple time line that illustrates the point at which each of the chapters’ topics will be introduced. For simplicity’s sake, I have divided the X-axis time line into four distinct project phases that roughly follow the project life cycle discussed earlier in this chap- ter: (1) Foundation, (2) Planning, (3) Implementation, and (4) Termination. Notice how some of the topics we will cover are particularly relevant only during certain phases of the project while

Low Maturity

Ad hoc process, no common language, little support

Moderate Maturity

Defined practices, training programs, organizational support

Institutionalized, seeks continuous


High Maturity

Figure 1.10 Project Management Maturity—A Generic Model

24 Chapter 1 • Introduction

others, such as project leadership, are significant across much of the project’s life cycle. Among the benefits of setting up the text to follow this sequence are that, first, it shows the importance of blending the human-based topics (leadership and team building) directly with the more ana- lytical or scientific elements of project management. We cannot compartmentalize our approach to project management as either exclusively technical or behavioral; the two are opposite sides of the same coin and must be appreciated jointly. Second, the structure provides a simple logic for ordering the chapters and the stage of the project at which we are most likely to concern ourselves with these topics. Some concepts, as illustrated by the figure, are more immediately concerned with project planning while others become critical at later phases in the project. Appreciating the elements of project management and their proper sequencing is an important learning guide. Finally, the figure offers an intuitively appealing method for visually highlighting the structure and flow we will follow across the topics in the text.

The foundation stage helps us with our fundamental understanding of what projects are and how they are typically managed in modern organizations. As part of that understanding, we must necessarily focus on the organizational setting within which projects are created, selected, and devel- oped. Some of the critical issues that can affect the manner in which projects are successfully imple- mented are the contextual issues of a firm’s strategy, structure, and culture. Either these elements are set up to support project-based work or they are not. In the former case, it is far easier to run projects and achieve positive results for the organization. As a result, it is extremely helpful for us to clearly understand the role that organizational setting, or context, plays in project management.

In Chapter 3 we explore the process of project screening and selection. The manner in which a firm selects the projects it chooses to undertake is often critical to its chances of successful devel- opment and commercial profitability. Chapter 4 introduces the challenges of project management from the perspective of the project leader. Project management is an extremely “leader-intensive” undertaking: The project manager is the focal point of the project, often functioning as a miniature CEO. The more project managers understand about project leadership and the skills required by effective project managers, the better companies can begin training project managers within their own ranks.

The second phase is related to the up-front issues of project planning. Once a decision to proceed has been made, the organization must first select a suitable project manager to oversee the development process. Immediately, this project manager is faced with a number of responsibilities, including:

1. Selecting a team—Team building and conflict management are the first challenges that proj- ect managers face.

2. Developing project objectives and a plan for execution—Identifying project requirements and a logical plan to develop the project are crucial.

3. Performing risk management activities—Projects are not developed without a clear sense of the risks involved in their planning and implementation.

4. Cost estimating and budgeting—Because projects are resource-constrained activities, careful budgeting and cost estimation are critical.

Foundation Planning Implementation Termination

Figure 1.11 organization of text

1.6 Project Elements and Text Organization 25

5. Scheduling—The heart of project planning revolves around the process of creating clear, aggressive, yet reasonable schedules that chart the most efficient course to project completion.

6. Managing resources—The final step in project planning is the careful management of project resources, including project team personnel, to most efficiently perform tasks.

Chapter 5, which discusses project scope management, examines the key features in the over- all plan. “Project scope management” is something of an umbrella term under which we consider a number of elements in the overall project planning process. This chapter elaborates the variety of planning techniques and steps for getting a project off on the right foot.

Chapter 6 addresses some of the behavioral challenges project managers face in terms of effective team building and conflict management. This chapter looks at another key component of effective human resource management: the need to create and maintain high-performance teams. Effectively building and nurturing team members—often people from very different back- grounds—is a constant challenge and one that requires serious consideration. Conflict occurs on a number of levels, not just among team members, but between the team and project stakeholders, including top management and customers. This chapter will identify some of the principal causes of conflict and explain various methods for resolving it.

Chapter 7 deals with project risk management. In recent years, this area of project manage- ment has become increasingly important to companies that want to ensure, as far as possible, that project selection choices are appropriate, that all the risks and downside potential have been con- sidered, and that, where appropriate, contingency plans have been developed. Chapter 8 covers budgeting and cost estimation. Because project managers and teams are held to both standards of performance and standards of cost control, it is important to understand the key features of cost estimation and budgeting.

Chapters 9 and 10 focus on scheduling methodologies, which are a key feature of project management. These chapters offer an in-depth analysis of various project-scheduling tools, dis- cuss critical software for project scheduling, and explain some recent breakthroughs in project scheduling. Chapter 11 covers some important recent developments in project scheduling, the agile project planning methodology, and the development and application of critical chain proj- ect scheduling. Chapter 12 considers the challenges of resource allocation. Once various project activities have been identified, we must make sure they work by allocating the resources needed to support them.

The third process in project management, implementation, is most easily understood as the stage in which the actual “work” of the project is being performed. For example, engineers and other technical experts determine the series of tasks necessary to complete the overall project, including their individual task responsibilities, and each of the tasks is actively managed by the manager and team to ensure that there are no significant delays that can cause the project to exceed its schedule. Chapter 13 addresses the project challenges of control and evaluation. During the implementation phase, a considerable amount of ambiguity regarding the status of the project is possible unless specific, practical steps are taken to establish a clear method for tracking and con- trolling the project.

Finally, the processes of project termination reflect the fact that a project is a unique organi- zational endeavor, marked by a specified beginning and ending. The process of closing down a project, whether due to the need to “kill” it because it is no longer viable or through the steps of a planned termination, offers its own set of challenges. A number of procedures have been devel- oped to make this process as smooth and logical as possible. Chapter 14 discusses the elements in project closeout— the phase in which the project is concluded and resources (both monetary and human) are reassigned.

This book was written to help create a new generation of effective project managers. By exploring the various roles of project managers and addressing the challenges and opportunities they constantly face, we will offer a comprehensive and integrative approach to better understand the task of project management—one that explores the full range of strategic, technical, and behav- ioral challenges and duties for project managers.

This text also includes, at the end of relevant chapters, a series of activities designed to help students develop comprehensive project plans. It is absolutely essential that persons complet- ing a course in project management carry away with them practical knowledge about the steps

26 Chapter 1 • Introduction

involved in creating a project, planning its development, and overseeing its work. Future manag- ers need to develop the skills to convert the theories of project management into the successful practice of the craft. With this goal in mind, the text contains a series of exercises designed to help professors and students construct overall project plans. Activities involve the development, from beginning to end, of a project plan, including narrative, risk analysis, work breakdown structure, activity estimation and network diagramming, resource leveling and project budgeting, and so forth. In order to add a sense of realism to the process, later chapters in the book also include a series of hypothetical problems. By the end of the course, students should have created a compre- hensive project document that details the necessary steps in converting project plans into practi- cal accomplishments.

As a template for providing examples, the text employs a hypothetical company called ABCups Inc., which is about to initiate an important project. Chapter-ending activities, including exercises in scheduling, budgeting, risk management, and so forth, will often include examples created from the ABCups project for students to use as a model for their own work. In this way, students will be presented both with a challenge and with an example for generating their own deliverables as they progressively build their project plans.

Several software packages are available for planning and tracking the current status of a project. Some of them (e.g., products by SAP and Oracle) are large, quite complex, and capable of linking project management functions to other critical through-put operations of a company. Other desktop software packages are more readily accessible and easier to interpret for the aver- age novice interested in improving his or her project management skills. This text uses examples throughout from Microsoft’s Project 2013, including screen captures, to illustrate how MSP 2013 can be used for a variety of planning and tracking purposes. Additionally, some simple tutorials are included in the appendices at the end of the text to give readers a feel for how the software works and some of the features it offers. As a method for learning the capabilities of the soft- ware, it’s a start. For those committed to fully learning one of these project management schedul- ing packages, I encourage you to investigate alternative packages and, once you have made your choice, invest in a comprehensive training manual.

An additional feature of this text is the linkage between concepts that are discussed through- out and the Project Management Body of Knowledge (PMBoK), which was developed by the Project Management Institute (PMI). As the world’s leading professional organization for project management and with nearly half a million members, PMI has been in the forefront of efforts to standardize project management practices and codify the necessary skills to be successful in our field. Now in its fifth edition, the PMBoK identifies ten critical “knowledge areas” of project man- agement skills and activities that all practitioners need to master in order to become fully trained in their profession. These knowledge areas, which are shown in Figure 1.12, encompass a broad overview of the component processes for project management. Although it is not my intention to create a text to serve as a primer for taking a professional certification exam, it is important for us to recognize that the skills we develop through reading this work are directly applicable to the professional project management knowledge areas.

Students will find several direct links to the PMBoK in this text. First, the key terms and their definitions are intended to follow the updated, fifth edition PMBoK glossary (included as an appen- dix at the end of the text). Second, chapter introductions will also highlight references to the PMBoK as we address them in turn. We can see how each chapter not only adds to our knowledge of project management but also directly links to elements within the PMBoK. Finally, many end-of-chapter exercises and Internet references will require direct interaction with PMI through its Web site.

As an additional link to the Project Management Institute and the PMBoK, this text will include sample practice questions at the end of relevant chapters to allow students to test their in-depth knowledge of aspects of the PMBoK. Nearly 20 years ago, PMI instituted its Project Management Professional (PMP) certification as a means of awarding those with an expert knowl- edge of project management practice. The PMP certification is the highest professional designation for project management expertise in the world and requires in-depth knowledge in all nine areas of the PMBoK. To date, more than 600,000 project professionals worldwide have attained the PMP certification and the numbers are steadily growing each year. The inclusion of questions at the end of the relevant chapters offers students a way to assess how well they have learned the impor- tant course topics, the nature of PMP certification exam questions, and to point to areas that may require additional study in order to master this material.

Summary 27

This text offers an opportunity for students to begin mastering a new craft—a set of skills that is becoming increasingly valued in contemporary corporations around the world. Project manag- ers represent the new corporate elite: a corps of skilled individuals who routinely make order out of chaos, improving a firm’s bottom line and burnishing their own value in the process. With these goals in mind, let us begin.34

12.1 Plan Procurement Management 12.2 Conduct Procurements 12.3 Control Procurements 12.4 Close Procurements

11.1 Plan Risk Management 11.2 Identify Risks 11.3 Perform Qualitative Risk Analysis 11.4 Perform Quantitative Risk Analysis 11.5 Plan Risk Responses 11.6 Control Risks

10.1 Plan Communications Management 10.2 Manage Communications 10.3 Control Communications

8.1 Plan Quality Management 8.2 Perform Quality Assurance 8.3 Control Quality

7.1 Plan Cost Management 7.2 Estimate Costs 7.3 Determine Budget 7.4 Control Costs

6.1 Plan Schedule Management 6.2 Define Activities 6.3 Sequence Activities 6.4 Estimate Activity Resources 6.5 Estimate Activity Durations 6.6 Develop Schedule 6.7 Control Schedule

Project Management

4.1 Develop Project Charter 4.2 Develop Project Management Plan 4.3 Direct & Manage Project Work 4.4 Monitor & Control Project Work 4.5 Perform Integrated Change Control 4.6 Close Project or Phase

4. Integration Management

5.1 Plan Scope Management 5.2 Collect Requirements 5.3 Define Scope 5.4 Create WBS 5.5 Validate Scope 5.6 Control Scope

5. Scope Management 6. Time Management

9.1 Plan HR Management 9.2 Acquire Project Team 9.3 Develop Project Team 9.4 Manage Project Team

9. Human Resource Management

12. Procurement Management11. Risk Management

13. Stakeholder Management

8. Quality Management

10. Communications Management

7. Cost Management

13.1 Identify Stakeholders 13.2 Plan Stakeholder Management 13.3 Manage Stakeholder Engagement 13.4 Control Stakeholder Engagement

Figure 1.12 overview of the Project Management institute’s PMBoK Knowledge Areas

Source: Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge (PMBoK Guide), 5th ed. Project Management Institute, Inc. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.


1. Understand why project management is becoming such a powerful and popular practice in business. Project management offers organizations a number of practical competitive advantages, including the ability to be both effective in the marketplace and efficient with the use of organizational resources, and the ability to achieve technological break- throughs, to streamline new-product development, and to manage the challenges arising from the busi- ness environment.

2. recognize the basic properties of projects, includ- ing their definition. Projects are defined as

temporary endeavors undertaken to create a unique product or service. Among their key properties are that projects are complex, one-time processes; proj- ects are limited by budget, schedule, and resources; they are developed to resolve a clear goal or set of goals; and they are customer-focused.

3. Understand why effective project management is such a challenge. Projects operate outside of nor- mal organizational processes, typified by the work done by functional organizational units. Because they are unique, they require a different mind- set: one that is temporary and aimed at achieving

28 Chapter 1 • Introduction

a clear goal within a limited time frame. Projects are ad hoc endeavors with a clear life cycle. They are employed as the building blocks in the design and execution of organizational strategies, and they provide a philosophy and a strategy for the man- agement of change. Other reasons why they are a challenge include the fact that project management requires the crossing of functional and organiza- tional boundaries while trying to satisfy the mul- tiple constraints of time, budget, functionality, and customer satisfaction.

4. differentiate between project management prac- tices and more traditional, process-oriented busi- ness functions. Projects involve new process or product ideas, typically with one objective or a lim- ited set of objectives. They are one-shot activities with a defined beginning and end, employing a het- erogeneous group of organizational members as the project team. They operate under circumstances of change and uncertainty, outside of normal organiza- tional channels, and are intended to upset the status quo and violate established practice, if need be, in order to achieve project goals. Process-oriented func- tions adhere more closely to rigid organizational rules, channels of communication, and procedures. The people within the functional departments are homogenous, engaged in ongoing activities, with well-established systems and procedures. They rep- resent bastions of established practice designed to reinforce the organization’s status quo.

5. recognize the key motivators that are pushing companies to adopt project management practices. Among the key motivators in pushing organiza- tions to adopt project management are (1) shortened product life cycles, (2) narrow product launch win- dows, (3) increasingly complex and technical prod- ucts, (4) the emergence of global markets, and (5) an economic period marked by low inflation.

6. Understand and explain the project life cycle, its stages, and the activities that typically occur at each stage in the project. The project life cycle is a mechanism that links time to project activities and refers to the stages in a project’s development. The common stages used to describe the life cycle for a project are (1) conceptualization, (2) planning, (3) execution, and (4) termination. A wide and diverse set of activities occurs during different life cycle stages; for example, during the conceptualization phase, the basic project mission and scope is devel- oped and the key project stakeholders are signed on to support the project’s development. During plan- ning, myriad project plans and schedules are cre- ated to guide the development process. Execution requires that the principal work of the project be performed, and finally, during the termination stage,

the project is completed, the work is finished, and the project is transferred to the customer.

7. Understand the concept of project “success,” including various definitions of success, as well as the alternative models of success. Originally, project success was predicated simply on a triple- constraint model that rewarded projects if they were completed with regard to schedule, budget, and functionality. This model ignored the emphasis that needs to be placed on project clients, however. In more accurate terms, project success involves a “quadruple constraint,” linking the basic project metrics of schedule adherence, budget adherence, project quality (functionality), and customer satis- faction with the finished product. Other models of project success for IT projects employ the measures of (1) system quality, (2) information quality, (3) use, (4) user satisfaction, (5) individual impact, and (6) organizational impact.

8. Understand the purpose of project management maturity models and the process of benchmarking in organizations. Project management maturity models are used to allow organizations to bench- mark the best practices of successful project man- agement firms. Project maturity models recognize that different organizations are at different levels of sophistication in their best practices for manag- ing projects. The purpose of benchmarking is to systematically manage the process improvements of project delivery by a single organization over a period of time. As a firm commits to implement- ing project management practices, maturity models offer a helpful, multistage process for moving for- ward through increasing levels of sophistication of project expertise.

9. identify the relevant maturity stages that organiza- tions go through to become proficient in their use of project management techniques. Although there are a number of project maturity models, sev- eral of the most common share some core features. For example, most take as their starting point the assumption that unsophisticated organizations initi- ate projects in an ad hoc fashion, with little overall shared knowledge or procedures. As the firm moves through intermediate steps, it will begin to initiate processes and project management procedures that diffuse a core set of project management techniques and cultural attitudes throughout the organization. Finally, the last stage in maturity models typically recognizes that by this point the firm has moved beyond simply learning the techniques of project management and is working at continuous improve- ment processes to further refine, improve, and solidify project management philosophies among employees and departments.

Case Study 1.1 29

Key Terms

Benchmarking (p. 20) Client acceptance (p. 16) Clients (p. 14) Budget (p. 16)

Deliverables (p. 5) Performance (p. 16) Process (p. 5) Project (p. 5)

Project life cycle (p. 13) Project management (p. 8) Project management maturity models (p. 19)

Project success (p. 16) Stakeholders (p. 13) Time (p. 16) Triple constraint (p. 16)

Discussion Questions

1.1 What are some of the principal reasons why project manage- ment has become such a popular business tool in recent years?

1.2 What do you see as being the primary challenges to introducing a project management philosophy in most organizations? That is, why is it difficult to shift to a project- based approach in many companies?

1.3 What are the advantages and disadvantages of using proj- ect management?

1.4 What key characteristics do all projects possess? 1.5 Describe the basic elements of a project life cycle. Why is

an understanding of the life cycle relevant for our under- standing of projects?

1.6 Think of a successful project and an unsuccessful project with which you are familiar. What distinguishes the two, both in terms of the process used to develop them and their outcomes?

1.7. Consider the Expedition Everest case at the end of the chapter: What elements in Disney’s approach to

developing its theme rides do you find particularly im- pressive? How can a firm like Disney balance the need for efficiency and smooth development of projects with the desire to be innovative and creative? Based on this case, what principles appear to guide its development process?

1.8 Consider the six criteria for successful IT projects. Why is IT project success often so difficult to assess? Make a case for some factors being more important than others.

1.9 As organizations seek to become better at managing projects, they often engage in benchmarking with other companies in similar industries. Discuss the concept of benchmarking. What are its goals? How does bench- marking work?

1.10 Explain the concept of a project management maturity model. What purpose does it serve?

1.11 Compare and contrast the four project management maturity models shown in Table 1.3. What strengths and weaknesses do you perceive in each of the models?

CaSe STuDy 1.1 MegaTech, Inc.

MegaTech, Inc., designs and manufactures automo- tive components. For years, the company enjoyed a stable marketplace, a small but loyal group of custom- ers, and a relatively predictable environment. Though slowly, annual sales continued to grow until recently hitting $300 million. MegaTech products were popular because they required little major updating or yearly redesign. The stability of its market, coupled with the consistency of its product, allowed MegaTech to fore- cast annual demand accurately, to rely on production runs with long lead times, and to concentrate on inter- nal efficiency.

Then, with the advent of the North American Free Trade Agreement (NAFTA) and other international trade agreements, MegaTech found itself competing with auto parts suppliers headquartered in countries around the world. The company was thrust into an

unfamiliar position: It had to become customer-focused and quicker to market with innovative products. Facing these tremendous commercial challenges, top manage- ment at MegaTech decided to recreate the company as a project-based organization.

The transition, though not smooth, has nonethe- less paid big dividends. Top managers determined, for instance, that product updates had to be much more frequent. Achieving this goal meant yearly redesigns and new technologies, which, in turn, meant making innovative changes in the firm’s operations. In order to make these adjustments, special project teams were formed around each of the company’s prod- uct lines and given a mandate to maintain market competitiveness.

At the same time, however, MegaTech wanted to maintain its internal operating efficiencies. Thus


30 Chapter 1 • Introduction

all project teams were given strict cost and schedule guidelines for new product introductions. Finally, the company created a sophisticated research and devel- opment team, which is responsible for locating likely new avenues for technological change 5 to 10 years down the road. Today, MegaTech operates project teams not only for managing current product lines but also for seeking longer-term payoffs through applied research.

MegaTech has found the move to project man- agement challenging. For one thing, employees are still rethinking the ways in which they allocate their time and resources. In addition, the firm’s success rate with new projects is still less than management had hoped. Nevertheless, top managers feel that, on balance, the shift to project management has given

the company the operating advantage that it needed to maintain its lead over rivals in its globally com- petitive industry. “Project management,” admits one MegaTech executive, “is certainly not a magic pill for success, but it has started us thinking about how we operate. As a result, we are doing smarter things in a faster way around here.”


1. What is it about project management that of- fers MegaTech a competitive advantage in its industry?

2. What elements of the marketplace in which MegaTech operates led the firm to believe that proj- ect management would improve its operations?

CaSe STuDy 1.2 The IT Department at Hamelin Hospital

Hamelin Hospital is a large (700-bed) regional hospi- tal in the northeastern United States. The information technology (IT) department employs 75 people and has an operating budget of over $35 million. The de- partment is responsible for managing 30–40 projects, ranging from small (redesigning computer screens) to very large, such as multimillion-dollar system develop- ment projects that can run for over a year. Hamelin’s IT department has been growing steadily, reflecting the hospital’s commitment to expanding its informa- tion storage and processing capacities. The two princi- pal functions of the IT department are developing new software applications and maintaining the current in- formation system. Project management is a way of life for the department.

The IT department jobs fall into one of five cat- egories: (1) help-desk technician, (2) programmer, (3) senior programmer, (4) systems analyst, and (5) proj- ect manager. Help-desk technicians field queries from computer system users and solve a wide range of problems. Most new hires start at the help desk, where they can become familiar with the system, learn about problem areas, become sensitive to users’ frustrations and concerns, and understand how the IT department affects all hospital operations. As individuals move up the ladder, they join project teams, either as program- mers or systems analysts. Finally, five project manag- ers oversee a constantly updated slate of projects. In addition, the workload is always being supplemented by new projects. Team personnel finish one assignment

and then move on to a new one. The typical IT depart- ment employee is involved in seven projects, each at a different stage of completion.

The project management system in place at Hamelin is well regarded. It has spearheaded a tre- mendous expansion of the hospital’s IT capabilities and thus helped the hospital to gain a competitive advantage over other regional hospitals. Recently, in fact, Hamelin began “farming out” its IT services on a fee-for-service basis to competing hospitals needing help with their records, administration, order-entry systems, and so forth. Not surprisingly, the results have improved the hospital’s bottom line: At a time when more and more health care organizations are feeling the effects of spiraling health care costs, Hamelin’s IT department has helped the hospital sustain continuous budget increases, additional staffing, a larger slate of projects, and a track record of success.


1. What are the benefits and drawbacks of starting most new hires at the help-desk function?

2. What are the potential problems with requiring project team members to be involved in multiple projects at the same time? What are the potential advantages?

3. What signals does the department send by mak- ing “project manager” the highest position in the department?

Case Study 1.3 31

CaSe STuDy 1.3 Disney’s Expedition Everest

One of the newest thrill rides to open in the Walt Disney World Resort may just be the most impressive. As Disney approached its 50th anniversary, the company wanted to celebrate in a truly special way. What was its idea? Create a park attraction that would, in many ways, serve as the link between Disney’s amazing past and its prom- ising future. Disney showed that it was ready to pull out all stops in order to get everything just right.

In 2006, The Walt Disney Company introduced Expedition Everest in Disney’s Animal Kingdom Park at Lake Buena Vista, Florida. Expedition Everest is more than just a roller coaster. It is the embodiment of the Disney spirit: a ride that combines Disney’s trademark thrills, unexpected twists and turns, incredible attention to detail, and impressive project management skills.

First, let’s consider some of the technical details of Expedition Everest:

• With a peak of just under 200 feet, the ride is con- tained within the tallest of 18 mountains created by Disney’s Imagineers at Disney parks worldwide.

• The ride contains nearly a mile of track, with twists, tight turns, and sudden drops.

• The Disney team created a Yeti: an enormous, fur-covered, Audio-Animatronics monster pow- ered by a set of hydraulic cylinders whose com- bined thrust equals that of a Boeing 747 airliner. Through a series of sketches, computer-animated drawings, sculptures, and tests that took more than two years to perfect, Disney created and pro- grammed its Abominable Snowman to stand over 10 feet tall and serve as the focal point of the ride.

• More than 900 bamboo plants, 10 species of trees, and 110 species of shrubs were planted to re-create the feeling of the Himalayan lowlands surrounding Mount Everest.

• More than 1,800 tons of steel were used to construct the mountain. The covering of the framework was done using more than 3,000 prefabricated “chips” created from 25,000 individual computer-molded pieces of steel.

• To create the proper color schemes, 2,000 gallons of stain and paint were used on rockwork and throughout the village Disney designed to serve as a backdrop for the ride.

• More than 2,000 handcrafted items from Asia are used as props, cabinetry, and architectural ornamentation.

Building an attraction does not come easily or quickly for Disney’s Imagineers. Expedition Everest

was several years in development as Disney sent teams, including Walt Disney Imagineering’s Creative Executive Joe Rohde, on repeated trips to the Himalayas in Nepal to study the lands, architecture, colors, ecol- ogy, and culture in order to create the most authentic setting for the new attraction. Disney’s efforts reflect a desire to do much more than provide a world-class ride experience; they demonstrate the Imagineers’ eagerness to tell a story—a story that combines the mythology of the Yeti figure with the unique history of the Nepalese living in the shadow of the world’s tallest mountain. Ultimately, the attraction, with all its background and thematic elements, took nearly five years to complete.

Riders on Expedition Everest gain a real feel for the atmosphere that Disney has worked so hard to cre- ate. The guests’ adventure starts by entering the build- ing of the “Himalayan Escape” tour company, complete with Norbu and Bob’s booking office to obtain permits for their trip. Overhead flutter authentic prayer flags from monasteries in Nepal. Next, guests pass through Tashi’s General Store and Bar to stock up on supplies for their journey to the peak of the mountain. Finally, guests pass through an old tea warehouse that contains a remarkable museum of artifacts reflecting Nepal’s culture, a history of the Himalayas, and tales of the Yeti, which is said to inhabit the slopes of Mount Everest. It is only now that guests are permitted to board the Anandapur Rail Service for their trip to the peak. Each train is modeled after an aging, steam-engine train, seating 34 guests per train.

Over the next several minutes, guests are trans- ported up the roller coaster track, through a series of winding turns, until their encounter with the Yeti. At this point another unique feature of the attraction emerges: The train begins rushing backward down the track, as though it were out of control. Through the balance of the ride, guests experience a landscape of sights and sounds culminating in a 50 mph final dash down the mountain and back to the safety of the Nepalese village.

Disney’s approach to the management of projects such as Expedition Everest is to combine careful plan- ning, including schedule and budget preparation, with the imagination and vision for which the company is so well known. Creativity is a critical element in the development of new projects at Disney. The company’s Imagineers include some of the most skilled artists and computer-animation experts in the world. Although it is easy to be impressed by the technical knowledge of Disney’s personnel, it is important to remember that each new project is approached with an understanding


32 Chapter 1 • Introduction

of the company’s underlying business and attention to market projections, cost control, and careful project management discipline. New attraction proposals are carefully screened and researched. The result is the creation of some of the most innovative and enjoyable rides in the world. Disney does not add new attractions to its theme parks frequently, but when it does so, it does so with style!


1. Suppose you were a project manager for Disney. Based on the information in this case, what

critical success metrics do you think the com- pany uses when designing a new ride; that is, how would you prioritize the needs for addressing project cost, schedule, quality, and client acceptance? What evidence supports your answer?

2. Why is Disney’s attention to detail in its rides unique? How does the company use the “atmo- sphere” discussed in the case to maximize the experience while minimizing complaints about length of wait for the ride?

CaSe STuDy 1.4 Rescue of Chilean Miners

On October 13, 2010, Foreman Luiz Urzua stepped out of the rescue capsule to thunderous applause and cries of “Viva, Chile!”; he was the last of 33 miners rescued after spending 70 days trapped beneath 2,000 feet of earth and rock. Following a catastrophic collapse, the miners were trapped in the lower shafts of the mine, initially without contact with the surface, leaving the world in suspense as to their fate. Their discovery and ultimate rescue are a story of courage, resourcefulness, and ultimately, one of the most successful projects in recent times.

The work crew of the San Jose copper and gold mine near Copiapo, in northern Chile, were in the middle of their shift when suddenly, on August 5, 2010, the earth shook and large portions of the mine tunnels collapsed, trapping 33 miners in a “workshop” in a lower gallery of the mine. Though they were temporarily safe, they were nearly a half mile below the surface, with no power and food for two days. Worse, they had no means of com- municating with the surface, so their fate remained a mystery to the company and their families. Under these conditions, their main goal was simple survival, con- serving and stretching out meager food supplies for 17 days, until the first drilling probe arrived, punching a hole in the ceiling of the shaft where they were trapped. Once they had established contact with the surface and provided details of their condition, a massive rescue operation was conceived and undertaken.

The first challenge was simply keeping the min- ers alive. The earliest supply deliveries down the nar- row communication shaft included quantities of food and water, oxygen, medicine, clothing, and necessities for survival as well as materials to help the miners pass their time. While groups worked to keep up the miners’ spirits, communicating daily and passing along mes- sages from families, other project teams were formed to begin developing a plan to rescue the men.

The challenges were severe. Among the signifi- cant questions that demanded practical and immediate answers were:

1. How do we locate the miners? 2. How quickly can we drill relief shafts to their

location? 3. How do we bring them up safely?

The mine tunnels had experienced such dam- age in the collapse that simply digging the miners out would have taken several months. A full-scale res- cue operation was conceived to extract the miners as quickly as possible. The U.S.-Chilean company Geotec Boyles Brothers, a subsidiary of Layne Christensen Company, assembled the critical resources from around the world. In western Pennsylvania, two com- panies that were experienced in mine collapses in the South American region were brought into the project. They had UPS ship a specialty drill, capable of creating wide-diameter shafts, large enough to fit men without collapsing. The drill arrived within 48 hours, free of charge. In all, UPS shipped more than 50,000 pounds of specialty equipment to the drilling and rescue site. The design of the rescue pod was the work of a NASA engi- neer, Clinton Cragg, who drew on his experience as a former submarine captain in the Navy and directed a team of 20 to conceive of and develop a means to carry the miners one at a time to the surface.

Doctors from NASA and U.S. submarine experts arrived at the mine site in mid-August, to assess the psychological state of the miners. Using their expertise in the physical and mental pressures of dealing with extended isolation, they worked with local officials to develop an exercise regimen and a set of chores for the workers in order to give them a sense of structure and responsibilities. The miners knew that help was being

Internet Exercises 33

assembled, but they had no notion of the technical chal- lenges of making each element in the rescue succeed. Nevertheless, with contact firmly established with the surface through the original contact drill shaft, the min- ers now began receiving news, updates from the surface, and a variety of gifts to ease the tedium of waiting.

The United States also provided an expert driller, Jeff Hart, who was called from Afghanistan, where he was helping American forces find water at forward operating bases, to man the specialty drilling machine. The 40-year-old drilled for 33 straight days, through tough conditions, to reach the men trapped at the mine floor. A total of three drilling rigs were erected and began drilling relief shafts from different directions. By September 17, Hart’s drill (referred to as “Plan B”) reached the miners, though the diameter of the shaft was only 5 inches. It would take a few weeks to ream the shaft with progressively wider drill bits to the final 25-inch diameter necessary to support the rescue cap- sules being constructed. Nevertheless, the rescue team was exuberant over the speed with which the shaft reached the trapped miners. Because of the special skills of the mining professionals, it is estimated that they cut more than two months off the time that experts expected this phase of the operation to take.

The first rescue capsule, named Phoenix, arrived at the site on September 23, with two more under con- struction and due to be shipped in two weeks. The Phoenix capsule resembled a specially designed cylin- drical tube. It was 13 feet long and weighed 924 pounds with an interior width of 22 inches. It was equipped with oxygen and a harness to keep occupants upright, communication equipment, and retractable wheels. The idea was for the capsule to be narrow enough to be lowered into the rescue shaft but wide enough for one person at a time to be fitted inside and brought back to the surface. To ensure that all 33 miners would fit into the Phoenix, they were put on special liquid diets and given an exercise regimen to follow while waiting for the final preparations to be made.

Finally, after extensive tests, the surface team decided that the shaft was safe enough to support the

rescue efforts and lowered the first Phoenix capsule into the hole. In two successive trips, the capsule car- ried down a paramedic and rescue expert who vol- unteered to descend into the mine to coordinate the removal of the miners. The first rescued miner broke the surface just after midnight on October 13 follow- ing a 15-minute ride in the capsule. A little more than 22 hours later, the shift manager, Urzua, was brought out of the mine, ending a tense and stressful rescue project.

The rescue operation of the Chilean miners was one of the most successful emergency projects in recent memory. It highlighted the ability of people to work together, marshal resources, gather support, and use innovative technologies in a humanitarian effort that truly captured the imagination of the world. The chal- lenges that had to be overcome were significant: first, the technical problems associated with simply finding and making contact with survivors; second, devising a means to recover the men safely; third, undertaking special steps to ensure the miners’ mental and physi- cal health remained strong; and finally, requiring all parties to develop and rely on radical technologies that had never been used before. In all these challenges, the rescue team performed wonders, recovering and restoring to their families all 33 trapped miners. On November 7, just one month after the rescue, one of the miners, Edison Pena, realized his own personal dream: running in and completing the New York City mara- thon. Quite an achievement for a man who had just spent more than two months buried a half mile below the surface of the earth!35


1. What does the story of the Chilean miners res- cue suggest to you about the variety of ways that project management can be used in the modern world?

2. Successful project management requires clear organization, careful planning, and good execu- tion. How were each of these traits shown in this rescue example?

Internet exercises

1.1 The largest professional project management organiza- tion in the world is the Project Management Institute (PMI). Go to its Web site,, and examine the links you find. Which links suggest that project man- agement has become a sophisticated and vital element in corporate success? Select at least three of the related links and report briefly on the content of these links.

1.2 Go to the PMI Web site and examine the link “Membership.” What do you discover when you begin navigating among the various chapters and cooperative organizations

associated with PMI? How does this information cause you to rethink project management as a career option?

1.3 Go to Library.aspx and examine some of the cases included on the Web page. What do they suggest about the challenges of managing projects successfully? The complexity of many of today’s projects? The exciting breakthroughs or opportunities that projects allow us to exploit?

1.4 Using your favorite search engine (Google, Yahoo!, etc.), type in the keywords “project” and “project management.”

34 Chapter 1 • Introduction


Randomly select three of the links that come up on the screen. Summarize what you find.

1.5 Go to the Web site for the Software Engineering Institute of Carnegie Mellon University at https://resources.sei.cmu. edu/asset_files/SpecialReport/1994_003_001_16265.pdf and access the software process maturity questionnaire. What are some of the questions that IT companies need to consider when assessing their level of project management maturity?

PMP certificAtion sAMPle QUestions

1. The majority of the project budget is expended upon: a. Project plan development. b. Project plan execution. c. Project termination. d. Project communication.

2. Which of the following is the most critical component of the triple constraint?

a. Time, then cost, then quality. b. Quality, then budget, then time. c. Scope. d. They are all of equal importance unless otherwise


3. Which of the following best describes a project stakeholder?

a. A team member. b. The project manager.

c. Someone who works in an area affected by the project.

d. All of the above are stakeholders.

4. All of the following are elements in the definition of a project, except:

a. A project is time-limited. b. A project is unique. c. A project is composed of unrelated activities. d. A project is undertaken for a purpose.

5. All of the following distinguish project management from other process activities, except:

a. There are no fundamental differences between project and process management.

b. Project management often involves greater cer- tainty of performance, cost, and schedule.

c. Process management operates outside of line organizations.

d. None of the above correctly distinguish project from process management.

Answers: 1. b—The majority of a project budget is spent during the execution phase; 2. d—Unless otherwise stated, all elements in the triple-constraint model are equally critical; 3. d—All of the examples listed are types of project stakeholders; 4. c—A project is composed of “interrelated” activities; 5. d—None of the answers given correctly differentiates “process” from “project” management.

1. Valery, Paul, quoted in “Extreme chaos” (Boston: Standish Group International, 2001).

2. Duthiers, V., and Kermeliotis, T. (2012, August 22). “Lagos of the future: Megacity’s ambitious plans.” CNN. urbanization-regeneration-infrastructure/; Walt, V. (2014, June 30). “Africa’s Big Apple,” Fortune, pp. 92–94; Ogunbiyi, T. (2014, February 6). “On Lagos’ investment in infrastructure development,” Business Day. http:// in-infrastructure-development/#.U6hKwPldV8E; Joy, O. (2013, October 10). “Tech cities and mega dams: Africa’s giant infrastructure projects,” CNN. http://edition. infrastructure/; Curnow, R. and Kermeliotis, T. (2012, April 5). “The daily grind of commuting in Africa’s economic hubs,” CNN. africa/commuting-africa/index.html?iref=allsearch

3. Peters, Thomas. (1994). Liberation Management: Necessary Disorganization for the Nanosecond Nineties. New York: Fawcett Books.

4. Stewart, Thomas H. (1995). “The corporate jungle spawns a new species,” Fortune, July 10, pp. 179–80.

5. Gilbreath, Robert D. (1988). “Working with pulses not streams: Using projects to capture opportunity,” in Cleland, D., and King, W. (Eds.), Project Management Handbook. New York: Van Nostrand Reinhold, pp. 3–15.

6. Buchanan, D. A., and Boddy, D. (1992). The Expertise of the Change Agent: Public Performance and Backstage Activity. London: Prentice Hall.

7. Frame, J. D. (1995). Managing Projects in Organizations, 2nd ed. San Francisco, CA: Jossey-Bass. See also Frame, J. D. (2002). The New Project Management, 2nd ed. San Francisco, CA: Jossey-Bass.

8. Kerzner, H. (2003). Project Management, 8th ed. New York: Wiley.

9. Field, M., and Keller, L. (1998). Project Management. London: The Open University.

10. Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge, 5th ed. Newtown Square, PA: PMI.

11. Cleland, D. I. (2001). “The discipline of project manage- ment,” in Knutson, J. (Ed.), Project Management for Business Professionals. New York: Wiley, pp. 3–22.

12. Lundin, R. A., and Soderholm, A. (1995). “A theory of the temporary organization,” Scandinavian Journal of Management, 11(4): 437–55.

13. Graham, R. J. (1992). “A survival guide for the acciden- tal project manager.” Proceedings of the Annual Project Management Institute Symposium. Drexel Hill, PA: Project Management Institute, pp. 355–61.

14. Sources:; Mossberg, W. S. (2004). “The music man,” Wall Street Journal, June 14, p. B1. Project Management Institute, Sohmen, Victor. “Project termination: Why the delay?” PMI Research Conference. Proceedings, p. 467–475. Paper presented at PMI Research Conference. Project Management Institute, Inc (2002). Copyright and all rights reserved. Material from this publication has been reproduced with the per- mission of PMI.

Notes 35

15. Pinto, J. K., and Millet, I. (1999). Successful Information Systems Implementation: The Human Side, 2nd ed. Newtown Square, PA: PMI.

16. Kapur, G. K. (1998). “Don’t look back to create the future.” Presentation at the Frontiers of Project Management Conference, Boston, MA.

17. Ted Ritter ( 2007, May 17). Public sector IT projects have only 30% success rate - CIO for Department for Work and Pensions. Retrieved from: public-sector/2007/05/public-sector-it- projects-have.html

18. Clausing, J., and Daly, M. (2013, September 14). “US nuclear agency faulted for laxity and overspending,” Boston Globe. nation-bloated-nuclear-spending-comes-under-fire/ O2uP7gv06vTAEw0AIcCIlL/story.html

19. “How to establish an organizational culture that pro- motes projects,” ProjectManagementCulture.htm; Standish Group. (2006). The Trends in IT Value report; Standish Group. (2013). Chaos Manifesto 2013. Boston, MA.

20. Kelley, M. (2008, November 18). “$600M spent on can- celed contracts,” USA Today, p. 1; Francis, D. (2014, June 12). “How squandered U.S. money fuels Iraqi insurgents,” Fiscal Times. Squandered-US-Money-Fuels-Iraq-s-Insurgents; Mulrine, A. (2013, July 12). “Rebuilding Iraq: Final report card on US efforts highlights massive waste,” Christian Science Monitor. www. Final-report-card-on-US-efforts-highlights-massive-waste

21. Cleland, D. I. (1994). Project Management: Strategic Design and Implementation. New York: McGraw-Hill; Pinto, J. K., and Rouhiainen, P. (2001). Building Customer-Based Project Organizations. New York: Wiley; Gray, C. F., and Larson, E. W. (2003). Project Management, 2nd ed. Burr Ridge, IL: McGraw-Hill.

22. Petroski, H. (1985). To Engineer Is Human—The Role of Failure in Successful Design. London: St. Martin’s Press.

23. Hewlett, S. (2014, February 3). “BBC’s Digital Media Initiative failed because of more than poor oversight,” The Guardian. 2014/ feb/03/bbc-digital-media-initiative-failed-mark-thompson; Conlan, T. (2013, May 24). “BBC axes £98m technology proj- ect to avoid ‘throwing good money after bad,’” The Guardian. nology-project-digital-media-initiative; Commons Select Committee. (2014, April 10). “BBC’s Digital Media Initiative a complete failure.” mittees/committees-a-z/commons-select/public-accounts- committee/news/bbc-dmi-report-substantive/; BBC. (2013, December 18). “BBC ‘not effective’ in running failed £100m IT scheme.” arts-25433174; Daniel, E., and Ward, J. (2013, June). “BBC’s DMI project failure is a warning to all organisations,” Computer Weekly. BBCs-DMI-project-failure-is-a-warning-to-all-organisations

24. Sohmen, Victor. (2002, July). “Project termination: Why the delay?” Paper presented at PMI Research Conference, Seattle, WA.

25. Freeman, M., and Beale, P. (1992). “Measuring project suc- cess,” Project Management Journal, 23(1): 8–17.

26. Morris, P. W. G. (1997). The Management of Projects. Thomas Telford: London; McKain, S. (2005). What Customers Really Want. Thomas Nelson: Nashville, TN.

27. Shenhar, A. J., Levy, O., and Dvir, D. (1997). “Mapping the dimensions of project success,” Project Management Journal, 28(2): 5–13.

28. DeLone, W. H., and McLean, E. R. (1992). “Information systems success: The quest for the dependent variable,” Information Systems Research, 3(1): 60–95; Seddon, P. B. (1997). “A respecification and extension of the DeLone and McLean model of IS success,” Information Systems Research, 8(3): 249–53; DeLone, W. H., and McLean, E. R. (2003). “The DeLone and McLean model of information system suc- cess: A ten-year update,” Journal of Management Information Systems, 19(4): 9–30.

29. Atkinson, R. (1999). “Project management: Cost, time and quality, two best guesses and a phenomenon, it’s time to accept other success criteria,” International Journal of Project Management, 17(6): 337–42; Cooke-Davies, T. (2002). “The ‘real’ success factors on projects,” International Journal of Project Management, 20(3): 185–90; Olson, D. L. (2001). Introduction to Information Systems Project Management. Burr Ridge, IL: Irwin/McGraw-Hill.

30. Pennypacker, J. S., and Grant, K. P. (2003). “Project man- agement maturity: An industry benchmark,” Project Management Journal, 34(1): 4–11; Ibbs, C. W., and Kwak, Y. H. (1998). “Benchmarking project management organiza- tions,” PMNetwork, 12(2): 49–53.

31. Reginato, P. E., and Ibbs, C. W. (2002). “Project manage- ment as a core competency,” Proceedings of PMI Research Conference 2002, Slevin, D., Pinto, J., and Cleland, D. (Eds.), The Frontiers of Project Management Research. Newtown Square, PA: Project Management Institute, pp. 445–50.

32. Crawford, K. (2002). Project Management Maturity Model: Providing a Proven Path to Project Management Excellence. New York: Marcel Dekker; Foti, R. (2002). “Implementing maturity models,” PMNetwork, 16(9): 39–43; Gareis, R. (2001). “Competencies in the project-oriented organiza- tion,” in Slevin, D., Cleland, D., and Pinto, J. (Eds.), The Frontiers of Project Management Research. Newtown Square, PA: Project Management Institute, pp. 213–24; Gareis, R., and Huemann, M. (2000). “Project management compe- tencies in the project-oriented organization,” in Turner, J. R., and Simister, S. J. (Eds.), The Gower Handbook of Project Management, 3rd ed. Aldershot, UK: Gower, pp. 709–22; Ibbs, C. W., and Kwak, Y. H. (2000). “Assessing project man- agement maturity,” Project Management Journal, 31(1): 32–43.

33. Humphrey, W. S. (1988). “Characterizing the software pro- cess: A maturity framework,” IEEE Software, 5(3): 73–79; Carnegie Mellon University. (1995). The Capability Maturity Model: Guidelines for Improving the Software Process. Boston, MA: Addison-Wesley; Kerzner, H. (2001). Strategic Planning for Project Management Using a Project Management Maturity Model. New York: Wiley; Crawford, J. K. (2002). Project Management Maturity Model. New York: Marcel Dekker; Pritchard, C. (1999). How to Build a Work Breakdown Structure: The Cornerstone of Project Management. Arlington, VA: ESI International.

34. Jenkins, Robert N. (2005). “A new peak for Disney,” St. Petersburg Times Online, news_pf/travel/A_new_peak_for_Disney.

35. mine.rescue.recap/index.html; OPINION/10/12/gergen.miners/index.html; www. blumenfeld/5140-how-americans-engineered-the-rescue- of-the-chilean-miners


2 ■ ■ ■

The Organizational Context Strategy, Structure, and Culture

Chapter Outline Project Profile

Tesla’s $5 Billion Gamble introduction 2.1 Projects and organizational

strategy 2.2 stakeholder ManageMent

Identifying Project Stakeholders Managing Stakeholders

2.3 organizational structure 2.4 forMs of organizational

structure Functional Organizations Project Organizations Matrix Organizations Moving to Heavyweight Project

Organizations Project ManageMent research in Brief

The Impact of Organizational Structure on Project Performance

2.5 Project ManageMent offices

2.6 organizational culture How Do Cultures Form? Organizational Culture and Project

Management Project Profile

Electronic Arts and the Power of Strong Culture in Design Teams

Summary Key Terms Discussion Questions Case Study 2.1 Rolls-Royce Corporation Case Study 2.2 Classic Case: Paradise Lost—The

Xerox Alto Case Study 2.3 Project Task Estimation and the

Culture of “Gotcha!” Case Study 2.4 Widgets ‘R Us Internet Exercises PMP Certification Sample Questions Integrated Project—Building Your

Project Plan Notes

Chapter Objectives After completing this chapter, you should be able to:

1. Understand how effective project management contributes to achieving strategic objectives. 2. Recognize three components of the corporate strategy model: formulation, implementation,

and evaluation. 3. See the importance of identifying critical project stakeholders and managing them within the

context of project development. 4. Recognize the strengths and weaknesses of three basic forms of organizational structure and

their implications for managing projects. 5. Understand how companies can change their structure into a “heavyweight project

organization” structure to facilitate effective project management practices. 6. Identify the characteristics of three forms of project management office (PMO).

7. Understand key concepts of corporate culture and how cultures are formed. 8. Recognize the positive effects of a supportive organizational culture on project management

practices versus those of a culture that works against project management.

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Project Procurement Management (PMBoK sec. 12) 2. Identify Stakeholders (PMBoK sec. 13.1) 3. Plan Stakeholder Management (PMBoK 13.2) 4. Manage Stakeholder Engagement (PMBoK 13.3) 5. Organizational Influences on Project Management (PMBoK sec. 2.1) 6. Organizational Structures (PMBoK sec. 2.1.3) 7. Organizational Cultures and Styles (PMBoK sec. 2.1.1) 8. Enterprise Environmental Factors (PMBoK sec. 2.1.5)

Project Profile

case—tesla’s $5 Billion Gamble

Tesla Motors, developer of the iconic Model S “electric sports car,” recently unveiled plans to create a “gigafactory” in order to produce batteries to power its automobiles. The concept was introduced by Tesla’s owner, Elon Musk, who called the proposed battery plant the world’s largest, and would lead to hiring 6,500 new workers and creating thou- sands of ancillary jobs in the process. Musk’s plan is to develop a factory that will cover 10 million square feet of space with a manufacturing capacity to produce 35 gigawatt hours of batteries per year. To put this in perspective, Tesla’s closest competitor in producing car batteries would be Nissan’s battery factory in Tennessee, which employs only 300 workers and can turn out 4.8 gigawatt hours of batteries. In setting their sights on building the world’s largest battery factory, Tesla (and Elon Musk) are gambling that demand for electric cars is rapidly growing. Musk’s plan is for the plant to start producing batteries by 2017, which puts pressure on the company to break ground by the end of 2014.

Tesla’s first car, the Tesla Model S, is a fully-electric powered sports car that has generated huge publicity for its performance, styling, and quality. Consumer Reports gave the car a “99” rating; its highest score ever. Selling for over $80,000 per car, however, has limited the market for the Tesla Model S to the very affluent. As a result, Tesla has already announced plans for a mid-priced car, the Gen III, which is expected to have a starting price of around $35,000. Tesla’s challenge lies in reducing the cost of its batteries. For example, the 85 kilowatt-hour battery pack for the Model S can cost over $25,000. Clearly, for a mid-priced car to be a possibility, Tesla has to find a way to lower battery costs, with an initial target of a 30% reduction.

With the promise of such a massive factory, including the thousands of jobs the project would bring, it is no sur- prise that a number of western states are actively competing to be the host site for the structure. Officials in Arizona, Nevada, New Mexico, and Texas have all promised tax breaks, the opportunity for Tesla to open their own retail stores statewide, and a list of other incentives for them to agree to build in their state.

Not everyone has greeted Tesla’s plan with enthusiasm, however. For example, Volkswagen CEO Martin Winterkorn recently observed that the current supply of car batteries was more than enough, given the slow accep- tance rate with which electric cars are entering the American marketplace. Sales of electric vehicles remain small—less than 1% of the total U.S. market. The U.S. government spent more than $1 billion on new electric-vehicle battery plants as part of the Obama administration’s economic stimulus, but many of those plants now run at just 15% to 20% of capacity. Numerous CEOs of car companies, battery makers, and others with a stake in the automotive industry share concerns about the advisability of devoting such huge capital investment in one factory for a market that is, at best, slowly developing.

Tesla, with sales of just over 22,400 cars last year, is already the largest buyer of lithium-ion battery cells in the world. Its plans to sell 500,000 vehicles means that its own demand would be greater than the demand for every laptop, mobile phone, and tablet sold in the world. To help meet this demand, as well as offset some of the cost of the huge factory project, Elon Musk has been negotiating with some skeptical potential partners, including Panasonic’s automo- tive and industrial systems subsidiary, to invest in the new Gigafactory and run battery-cell production. Tesla executives


Project Profile 37

38 Chapter 2 • The Organizational Context

argue that they need a plant to guarantee future supplies of the millions of battery cells they need at the reduced costs that come from economies of scale and logistics savings.

The risks in taking on this huge project are not solely technical or demand-based. Given Tesla’s tight timetable for completion of the factory, there is concern that it may not be possible to complete a structure within the window Mr. Musk envisions. While it may be doable, there is no doubt that the vision to imagine, design, and build a Gigafactory makes this a unique opportunity, coupled with significant risks.1


For successful project management, the organizational setting matters—its culture, its structure, and its strategy each play an integral part, and together they create the environment in which a project will flourish or founder. For example, a project’s connection to your organization’s overall strategy, the care with which you staff the team, and the goals you set for the proj- ect can be critical. Similarly, your organization’s policies, structure, culture, and operating systems can work to support and promote project management or work against the ability to effectively run projects. Contextual issues provide the backdrop around which project activi- ties must operate, so understanding what is beneath these issues truly contributes to under- standing how to manage projects. Issues that affect a project can vary widely from company to company.

Before beginning a project, the project manager and team must be certain about the struc- ture of the organization as it pertains to their project and the tasks they seek to accomplish. As clearly as possible, all reporting relationships must be specified, the rules and procedures that will govern the project must be established, and any issues of staffing the project team must be identified. General Electric’s efforts to acquire French conglomerate Alstom for $17 billion has been an enormously complicated undertaking, involving the combined efforts of multiple business units, financial analysis, and constant interaction with Alstom’s principle stakeholders, especially the French government. As part of their strategy, GE must identify the business groups that can be blended in with their own organization, units that are redundant to GE operations, and a logical organizational structure to best link the combined organization

FIgure 2.1 the tesla Model S “Skateboard” design with the flat battery pack located in the base of the car

Source: Car Culture/Corbis

2.1 Projects and Organizational Strategy 39

together in as efficient a manner as possible. Integrating Alstom’s nearly 85,000 employees and global business units with their own operations makes GE’s efforts a showcase in the project management of a strategic acquisition.

For many organizations, projects and project management practices are not the operating norm. In fact, as Chapter 1 discussed, projects typically exist outside of the formal, process- oriented activities associated with many organizations. As a result, many companies are sim- ply not structured to allow for the successful completion of projects in conjunction with other ongoing corporate activities. The key challenge is discovering how project management may best be employed, regardless of the structure the company has adopted. What are the strengths and weaknesses of various structural forms and what are their implications for our ability to manage projects? This chapter will examine the concept of organizational culture and its roots and implications for effective project management. By looking closely at three of the most important contextual issues for project management—strategy, organizational structure, and culture—you will see how the variety of structural options can affect, either positively or negatively, the firm’s ability to manage projects.

2.1 Projects and organIzatIonal strategy

strategic management is the science of formulating, implementing, and evaluating cross-functional decisions that enable an organization to achieve its objectives.2 In this section we will consider the relevant components of this definition as they apply to project management. Strategic management consists of the following elements:

1. Developing vision statements and mission statements. Vision and mission statements establish a sense of what the organization hopes to accomplish or what top managers hope it will become at some point in the future. Vision statements describe the organi- zation in terms of where it would like to be in the future. Effective vision statements are both inspirational and aspirational. A corporate vision serves as a focal point for members of the organization who may find themselves pulled in different directions by competing demands. In the face of multiple expectations and even contradictory efforts, an ultimate vision can serve as a “tie breaker,” which is highly beneficial in establishing priorities. A sense of vision is also an extremely important source of moti- vation and purpose. As the Book of Proverbs points out: “Where there is no vision, the people perish” (Prov. 29:18).3 Mission statements explain the company’s reason for exis- tence and support the vision. Many firms apply their vision and mission statements to evaluating new project opportunities as a first screening device. For example, Bechtel Corporation, a large construction organization, employs as its vision the goal of being “the world’s premier engineering, construction, and project management company.”4 For Bechtel, this means (1) Customers and partners will see Bechtel as integral to their success; (2) People will be proud to work at Bechtel; and (3) Communities will regard Bechtel as “ responsible—and responsive.” Projects they undertake must support this vision and those that do not are not pursued.

2. Formulating, implementing, and evaluating. Projects, as the key ingredients in strategy implementation, play a crucial role in the basic process model of strategic management. A firm devotes significant time and resources to evaluating its business opportunities through developing a corporate vision or mission, assessing internal strengths and weak- nesses as well as external opportunities and threats, establishing long-range objectives, and generating and selecting among various strategic alternatives. All these components relate to the formulation stage of strategy. Within this context, projects serve as the vehicles that enable companies to seize opportunities, capitalize on their strengths, and implement overall corporate objectives. New product development, for example, fits neatly into this framework. New products are developed and commercially introduced as a compa- ny’s response to business opportunities. Effective project management enables firms to efficiently and rapidly respond.

3. Making cross-functional decisions. Business strategy is a corporate-wide venture, requiring the commitment and shared resources of all functional areas to meet overall

40 Chapter 2 • The Organizational Context

table 2.1 Projects reflect Strategy

Strategy Project

Technical or operating initiatives (such as new distribution strategies or decentralized plant operations)

Construction of new plants or modernization of facilities

Development of products for greater market penetration and acceptance

New product development projects

New business processes for greater streamlining and efficiency Reengineering projects

Changes in strategic direction or product portfolio reconfiguration New product lines

Creation of new strategic alliances Negotiation with supply chain members (including suppliers and distributors)

Matching or improving on competitors’ products and services Reverse engineering projects

Improvement of cross-organizational communication and efficiency in supply chain relationships

Enterprise IT efforts

Promotion of cross-functional interaction, streamlining of new product or service introduction, and improvement of departmental coordination

Concurrent engineering projects

objectives. Cross-functional decision making is a critical feature of project management, as experts from various functional groups come together into a team of diverse personalities and backgrounds. Project management work is a natural environment in which to opera- tionalize strategic plans.

4. Achieving objectives. Whether the organization is seeking market leadership through low-cost, innovative products, superior quality, or other means, projects are the most effective tools to allow objectives to be met. A key feature of project management is that it can potentially allow firms to be effective in the external market as well as inter- nally efficient in operations; that is, it is a great vehicle for optimizing organizational objectives, whether they incline toward efficiency of production or product or process effectiveness.

Projects have been called the “stepping-stones” of corporate strategy.5 This idea implies that an organization’s overall strategic vision is the driving force behind its project development. For example, 3M’s desire to be a leading innovator in business gives rise to the creation and man- agement of literally hundreds of new product development projects within the multinational organization every year. Likewise, Rubbermaid Corporation is noted for its consistent pursuit of new product development and market introduction. The manner in which organizational strategies affect new project introductions will be addressed in greater detail in the chapter on project selection (Chapter 3). Projects are the building blocks of strategies; they put an action-oriented face on the strategic edifice. Some examples of how projects operate as strategic building blocks are shown in Table 2.1. Each of the examples illustrates the underlying theme that projects are the “operational reality” behind strategic vision. In other words, they serve as the building blocks to create the reality a strategy can only articulate.

The tows matrix (See Figure 2.2) is a useful way to see the links between projects and an organization’s strategic choices. TOWS comes from the acronym for “Threats–Opportunities– Weaknesses–Strengths” and refers to the challenges companies face in both their internal envi- ronment (within the organization) and their external environment (outside the company). In first identifying and then formulating strategies for addressing internal strengths and weak- nesses and external opportunities and threats, firms rely on projects as a device for pursuing these strategic choices. As Figure 2.2 suggests, once an organization determines the appropri- ate strategies to pursue (e.g., “maxi-maxi” strategy), it can then identify and undertake project choices that support this TOWS matrix. Projects offer companies the ability to create concrete means for realizing strategic goals.6

2.2 Stakeholder Management 41

An organization’s strategic management is the first important contextual element in its proj- ect management approaches. Because projects form the building blocks that allow us to implement strategic plans, it is vital that there exist a clear sense of harmony, or complementarity, between strategy and projects that have been selected for development. In a later section, we will add to our understanding of the importance of creating the right context for projects by adding an additional variable into the mix: the organization’s structure.

2.2 stakeholder ManageMent

Organizational research and direct experience tell us that organizations and project teams cannot operate in ways that ignore the external effects of their decisions. One way to understand the rela- tionship of project managers and their projects to the rest of the organization is through employing stakeholder analysis. stakeholder analysis is a useful tool for demonstrating some of the seem- ingly irresolvable conflicts that occur through the planned creation and introduction of any new project. Project stakeholders are defined as all individuals or groups who have an active stake in the project and can potentially impact, either positively or negatively, its development.7 Project stakeholder analysis, then, consists of formulating strategies to identify and, if necessary, manage for positive results the impact of stakeholders on the project.

Stakeholders can affect and are affected by organizational actions to varying degrees.8 In some cases, a corporation must take serious heed of the potential influence some stakeholder groups are capable of wielding. In other situations, a stakeholder group may have relatively little power to influence a company’s activities but its presence may still require attention. Contrast, for example, the impact that the government has on regulating the tobacco indus- try’s activities with the relative weakness of a small subcontractor working for Oracle on new software development. In the first case, the federal government has, in recent years, strongly limited the activities and sales strategies of the tobacco companies through the threat of regula- tion and litigation. On the other hand, Oracle, a large organization, can easily replace one small subcontractor with another.

Stakeholder analysis is helpful to the degree that it compels firms to acknowledge the poten- tially wide-ranging effects, both intended and unintended, that their actions can have on various stakeholder groups.9 For example, the strategic decision to close an unproductive manufacturing facility may make good business sense in terms of costs versus benefits that the company derives from the manufacturing site. However, the decision to close the plant has the potential to unleash

External Opportunities (O)

Internal Strengths (S)

Internal Weaknesses (W)

SO “Maxi-Maxi” Strategy

ST “Maxi-Mini” Strategy

WT “Mini-Mini” Strategy

WO “Mini-Maxi” Strategy

Develop projects that use strengths to maximize


Develop projects that use strengths to minimize


Develop projects that minimize weaknesses and

avoid threats

Develop projects that minimize weaknesses by

taking advantage of opportunities

1. 2. 3.

1. 2. 3.

1. 2. 3.

1. 2. 3.

External Threats (T)

FIgure 2.2 toWS Matrix

42 Chapter 2 • The Organizational Context

a torrent of stakeholder complaints in the form of protests and challenges from local unions, work- ers, community leaders in the town affected by the closing, political and legal groups, environmen- tal concerns, and so forth. Sharp managers will consider the impact of stakeholder reaction as they weigh the possible effects of their strategic decisions.

Just as stakeholder analysis is instructive for understanding the impact of major strate- gic decisions, project stakeholder analysis is extremely important when it comes to managing projects. The project development process itself can be directly affected by stakeholders. This relationship is essentially reciprocal in that the project team’s activities can also affect external stakeholder groups.10 Some common ways the client stakeholder group has an impact on proj- ect team operations include agitating for faster development, working closely with the team to ease project transfer problems, and influencing top management in the parent organization to continue supporting the project. The project team can reciprocate this support through actions that show willingness to closely cooperate with the client in development and transition to user groups.

The nature of these various demands can place them seemingly in direct conflict. That is, in responding to the concerns of one stakeholder, project managers often unwittingly find themselves having offended or angered another stakeholder who has an entirely different agenda and set of expectations. For example, a project team working to install a new software application across the organization may go to such levels to ensure customer satisfaction that they engage in countless revisions of the package until they have, seemingly, made their customers happy. However, in doing so, the overall project schedule may now have slipped to the point where top management is upset by the cost and schedule overruns. In managing projects, we are challenged to find ways to balance a host of demands and still maintain supportive and constructive relationships with each important stakeholder group.

Identifying Project stakeholders

Internal stakeholders are a vital component in any stakeholder analysis, and their impact is usually felt in relatively positive ways; that is, while serving as limiting and control- ling influences (in the case of the company accountant), for example, most internal stake- holders want to see the project developed successfully. On the other hand, some external stakeholder groups operate in manners that are quite challenging or even hostile to project development. Consider the case of spikes in the price of oil. With oil prices remain- ing unstable, ranging from $60 to above $100 per barrel through much of 2014, the impact on the global economy, attempting to emerge from the Great Recession, has been severe. Many groups in the United States have advocated taking steps to lessen the country’s dependence on foreign oil, including offshore exploration and the development of a new generation of nuclear power plants. Hydraulic fracturing (“fracking”) technology has been widely embraced as a means for developing shale deposits across the country, resulting in projections that the United States will go from a net importer of 1.5 trillion cubic feet of natural gas in 2012 to an exporter by 2016. Environmental groups, however, continue to oppose these steps, vowing to use litigation, political lobbying, and other measures to resist the development of these alter- native energy sources. As a recent example of the danger, they cite the Deepwater Horizon disaster that leaked thousands of barrels of oil into the Gulf of Mexico. Political efforts by environmentalists and their supporters have effectively delayed for years the development of the 1,700-mile-long Keystone XL oil pipeline from Canada’s oil sands region to refineries in Texas. Cleland refers to these types of external stakeholders as intervenor groups, defined as groups external to the project but possessing the power to effectively intervene and disrupt the project’s development.11

Among the set of project stakeholders that project managers must consider are:


• Top management • Accounting • Other functional managers • Project team members

2.2 Stakeholder Management 43


• Clients • Competitors • Suppliers • Environmental, political, consumer, and other intervenor groups

clIents Our focus throughout this entire book will be on maintaining and enhancing client rela- tionships. In most cases, for both external and internal clients, a project deals with an investment. Clients are concerned with receiving the project from the team as quickly as possible because the longer the project implementation, the longer the money invested sits without generating any re- turns. As long as costs are not passed on to them, clients seldom are overly interested in how much expense is involved in a project’s development. The opposite is usually the case, however. Costs typically must be passed on, and customers are avidly interested in getting what they pay for. Also, many projects start before client needs are fully defined. Product concept screening and clarification are often made part of the project scope of work (see Chapter 5). These issues—costs and client needs—are two strong reasons why many customers seek the right to make suggestions and request alterations in the project’s features and operating characteristics well into the schedule. Customers feel, with justification, that a project is only as good as it is acceptable and useful. This sets a certain flexibility requirement and requires willingness from the project team to be amenable to specification changes.

Another important fact to remember about dealing with client groups is that the term client does not in every case refer to the entire customer organization. The reality is often far more complex. A client firm consists of a number of internal interest groups, and in many cases they have different agendas. For example, a company can probably readily identify a number of distinct clients within the customer organization, including the top management team, engineering groups, sales teams, on-site teams, manufacturing or assembly groups, and so on. Under these normal circumstances, it becomes clear that the process of formulating a stakeholder analysis of a customer organization can be a complex undertaking.

The challenge is further complicated by the need to communicate, perhaps using different business language, with the various customer stakeholder groups (see Figure 2.3). Preparing a presentation to deal with the customer’s engineering staff requires mastery of technical infor- mation and solid specification details. On the other hand, the finance and contractual people are looking for tightly presented numbers. Formulating stakeholder strategies requires you first to acknowledge the existence of these various client stakeholders, and then to formulate a coordinated plan for uncovering and addressing each group’s specific concerns and learning how to reach them.

Parent Organization

External Environment

Top Management

Accountant Project Team

Project ManagerClients

Other Functional Managers

FIgure 2.3 Project Stakeholder relationships

44 Chapter 2 • The Organizational Context

coMPetItors Competitors can be an important stakeholder element because they are affected by the successful implementation of a project. Likewise, should a rival company bring a new product to market, the project team’s parent organization could be forced to alter, delay, or even abandon its project. In assessing competitors as a project stakeholder group, project managers should try to uncover any information available about the status of a competitor’s projects. Further, where possible, any apparent lessons a competitor may have learned can be a source of useful informa- tion for a project manager who is initiating a similar project. If a number of severe implementation problems occurred within the competitor’s project, that information could offer valuable lessons in terms of what to avoid.

suPPlIers Suppliers are any group that provides the raw materials or other resources the proj- ect team needs in order to complete the project. When a project requires a significant supply of externally purchased components, the project manager needs to take every step possible to ensure steady deliveries. In most cases this is a two-way street. First, the project manager has to ensure that each supplier receives the information necessary to implement its part of the proj- ect in a timely way. Second, the project manager must monitor the deliveries so they are met according to plan. In the ideal case, the supply chain becomes a well-greased machine that au- tomatically both draws the input information from the project team and delivers the products without excessive involvement of the project manager. For example, in large-scale construction projects, project teams daily must face and satisfy an enormous number of supplier demands. The entire discipline of supply chain management is predicated on the ability to streamline logistics processes by effectively managing the project’s supply chain.12 When this process fails or is disrupted the consequences can be severe, as in the case of the catastrophic tsunami that struck the northeastern coast of Japan in March 2011, The supply chains and product develop- ment capabilities of Japanese corporations were badly damaged. Economists estimate that the natural disaster cost the country’s economy over $300 billion. Further, numerous corporations (both Japanese companies and those that are their supply chain partners) were affected by the disaster. Japan manufactures 20% of the world’s semiconductor products, leading to serious shortages and delivery delays for companies such as Intel, Toshiba, and Apple.

Intervenor grouPs Environmental, political, social, community-activist, or consumer groups that can have a positive or negative effect on the project’s development and successful launch are referred to as intervenor groups.13 That is, they have the capacity to intervene in the project development and force their concerns to be included in the equation for project imple- mentation. There are some classic examples of intervenor groups curtailing major construction projects, particularly in the nuclear power plant construction industry. As federal, state, and even local regulators decide to involve themselves in these construction projects, intervenors have at their disposal the legal system as a method for tying up or even curtailing projects. For example, while wind farms supply more than half of the electricity needs for the country of Denmark, an alternative energy “wind farm” project being proposed for sites off the coast of Cape Cod, Massachusetts, have encountered strong resistance from local groups opposed to the threat from these farms ruining the local seascape. Litigation has tied this wind farm project up for years and shows no sign of being approved in the near future. Prudent project managers need to make a realistic assessment of the nature of their projects and the likelihood that one intervenor group or another may make an effort to impose its will on the development process.

toP ManageMent In most organizations, top management holds a great deal of control over project managers and is in the position to regulate their freedom of action. Top management is, after all, the body that authorizes the development of the project through giving the initial “go” de- cision, sanctions additional resource transfers as they are needed by the project team, and supports and protects project managers and their teams from other organizational pressures. Top manage- ment requires that the project be timely (they want it out the door quickly), cost-efficient (they do not want to pay more for it than they have to), and minimally disruptive to the rest of the functional organization.

accountIng The accountant’s raison d’être in the organization is maintaining cost efficiency of the project teams. Accountants support and actively monitor project budgets and, as such, are

2.2 Stakeholder Management 45

sometimes perceived as the enemy by project managers. This perception is wrong minded. To be able to manage the project, to make the necessary decisions, and to communicate with the customer, the project manager has to stay on top of the cost of the project at all times. An efficient cost control and reporting mechanism is vital. Accountants perform an important administrative service for the project manager.

FunctIonal Managers Functional managers who occupy line positions within the tradition- al chain of command are an important stakeholder group to acknowledge. Most projects are staffed by individuals who are essentially on loan from their functional departments. In fact, in many cases, project team members may only have part-time appointments to the team; their functional managers may still expect a significant amount of work out of them per week in performing their functional responsibilities. This situation can create a good deal of confusion, conflict, and the need for negotiation between project managers and functional supervisors and lead to seriously divided loyalties among team members, particularly when performance evaluations are conducted by functional managers rather than the project manager. In terms of simple self-survival, team members often maintain closer allegiance to their functional group than to the project team.

Project managers need to appreciate the power of the organization’s functional managers as a stakeholder group. Functional managers are not usually out to discourage project development. Rather, they have loyalty to their functional roles, and they act and use their resources accordingly, within the limits of the company’s structure. Nevertheless, as a formidable stakeholder group, functional managers need to be treated with due consideration by project managers.

Project teaM MeMbers The project team obviously has a tremendous stake in the project’s out- come. Although some may have a divided sense of loyalty between the project and their functional group, in many companies the team members volunteer to serve on projects and, hopefully, receive the kind of challenging work assignments and opportunities for growth that motivate them to perform effectively. Project managers must understand that their project’s success depends on the commitment and productivity of each member of the project team. Thus, team members’ impact on the project is, in many ways, more profound than that of any other stakeholder group.

Managing stakeholders

Project managers and their companies need to recognize the importance of stakeholder groups and proactively manage with their concerns in mind. Block offers a useful framework of the political process that has application to stakeholder management.14 In his framework, Block suggests six steps:

1. Assess the environment. 2. Identify the goals of the principal actors. 3. Assess your own capabilities. 4. Define the problem. 5. Develop solutions. 6. Test and refine the solutions.

assess the envIronMent Is the project relatively low-key or is it potentially so significant that it will likely excite a great deal of attention? For example, when EMC Corporation, a large computer manufacturer, began development of a new line of minicomputers and storage units with the potential for either great profits or serious losses, it took great care to first determine the need for such a product. Going directly to the consumer population with market research was the key to assessing the external environment. Likewise, one of the shapers of autonomous and near-autonomous care technology (driverless cars) has been companies such as Google working closely with consumers to determine their expectations and comfort level with the technology. In testing to date, autonomous vehicles have driven over 700,000 miles with only one accident (which was human-caused). Current projections are that a safe and workable driverless car could be ready for release as early as 2017. Ultimately, it is estimated that over 1 billion automobiles and trucks worldwide and over 450,000 civilian and military aircraft could be affected by this new technology.15

46 Chapter 2 • The Organizational Context

IdentIFy the goals oF the PrIncIPal actors As a first step in fashioning a strategy to defuse negative reaction, a project manager should attempt to paint an accurate portrait of stakehold- er concerns. Fisher and Ury16 have noted that the positions various parties adopt are almost invariably based on need. What, then, are the needs of each significant stakeholder group regarding the project? A recent example will illustrate this point. A small IT firm specializing in network solutions and software development recently contracted with a larger publishing house to develop a simulation for college classroom use. The software firm was willing to negotiate a lower-than-normal price for the job because the publisher suggested that excellent performance on this project would lead to future business. The software organization, inter- ested in follow-up business, accepted the lower fee because its more immediate needs were to gain entry into publishing and develop long-term customer contacts. The publisher needed a low price; the software developer needed new market opportunities.

Project teams must look for hidden agendas in goal assessment. It is common for departments and stakeholder groups to exert a set of overt goals that are relevant, but often illusionary.17 In haste to satisfy these overt or espoused goals, a common mistake is to accept these goals on face value, without looking into the needs that may drive them or create more compelling goals. Consider, for example, a project in a large, project-based manufacturing company to develop a comprehensive proj- ect management scheduling system. The project manager in charge of the installation approached each department head and believed that he had secured their willingness to participate in creating a scheduling system centrally located within the project management division. Problems developed quickly, however, because IT department members, despite their public professions of support, began using every means possible to covertly sabotage the implementation of the system, delaying comple- tion of assignments and refusing to respond to user requests. What was their concern? They believed that placing a computer-generated source of information anywhere but in the IT department threat- ened their position as the sole disseminator of information. In addition to probing the overt goals and concerns of various stakeholders, project managers must look for hidden agendas and other sources of constraint on implementation success.

assess your own caPabIlItIes As Robert Burns said, “Oh wad some Power the giftie gie us/To see oursels as ithers see us!”18 Organizations must consider what they do well. Likewise, what are their weaknesses? Do the project manager and her team have the political savvy and a sufficiently strong bargaining position to gain support from each of the stakeholder groups? If not, do they have connections to someone who can? Each of these questions is an example of the importance of the project team understanding its own capacities and capabilities. For example, not everyone has the contacts to upper management that may be necessary for ensuring a steady flow of support and resources. If you realistically determine that political acumen is not your strong suit, then the solution may be to find someone who has these skills to help you.

deFIne the ProbleM We must seek to define problems both in terms of our own perspective and in consideration of the valid concerns of the other party. The key to developing and maintaining strong stakeholder relationships lies in recognizing that different parties can have very different but equally legitimate perspectives on a problem. When we define problems not just from our viewpoint but also by trying to understand how the same issue may be perceived by stakeholders, we are operating in a “win-win” mode. Further, we must be as precise as possible, staying focused on the specifics of the problem, not generalities. The more accurately and honestly we can define the problem, the better able we will be to create meaningful solution options.

develoP solutIons There are two important points to note about this step. First, developing solutions means precisely that: creating an action plan to address, as much as possible, the needs of the various stakeholder groups in relation to the other stakeholder groups. This step constitutes the stage in which the project manager, together with the team, seeks to manage the political process. What will work in dealing with top management? In implementing that strategy, what reaction is likely to be elicited from the accountant? The client? The project team? Asking these questions helps the project manager develop solutions that acknowledge the interrelationships of each of the relevant stakeholder groups. The topics of power, political behavior, influence, and negotiation will be discussed in greater detail in Chapter 6.

As a second point, it is necessary that we do our political homework prior to developing solutions.19 Note the late stage at which this step is introduced. Project managers can fall into a

2.3 Organizational Structure 47

trap if they attempt to manage a process with only fragmentary or inadequate information. The philosophy of “ready, fire, aim” is sometimes common in stakeholder management. The result is a stage of perpetual firefighting during which the project manager is a virtual pendulum, swinging from crisis to crisis. Pendulums and these project managers share one characteristic: They never reach a goal. The process of putting out one fire always seems to create a new blaze.

test and reFIne the solutIons Implementing the solutions implies acknowledging that the project manager and team are operating under imperfect information. You may assume that stake- holders will react to certain initiatives in predictable ways, but such assumptions can be errone- ous. In testing and refining solutions, the project manager and team should realize that solution implementation is an iterative process. You make your best guesses, test for stakeholder reactions, and reshape your strategies accordingly. Along the way, many of your preconceived notions about the needs and biases of various stakeholder groups must be refined as well. In some cases, you will have made accurate assessments. At other times, your suppositions may have been dangerously naive or disingenuous. Nevertheless, this final step in the stakeholder management process forces the project manager to perform a critical self-assessment. It requires the flexibility to make accurate diagnoses and appropriate midcourse corrections.

When done well, these six steps form an important method for acknowledging the role that stake- holders play in successful project implementation. They allow project managers to approach “political stakeholder management” much as they would any other form of problem solving, recognizing it as a multivariate problem as various stakeholders interact with the project and with one another. Solutions to political stakeholder management can then be richer, more comprehensive, and more accurate.

An alternative, simplified stakeholder management process consists of planning, organizing, directing, motivating, and controlling the resources necessary to deal with the various internal and external stakeholder groups. The various stakeholder management functions are interlocked and repetitive; that is, this stakeholder management process is really best understood as a cycle. As you continually assess the environment, you refine the goals of the principal stakeholders. Likewise, as you assess your own capabilities, define the problems and possible solutions, you are constantly observing the environment to make sure that your proposed solutions are still valid. Finally, in testing and refining these solutions, it is critical to ensure that they will be the optimal alterna- tives, given likely changes in the environment. In the process of developing and implementing your plans, you are likely to uncover new stakeholders whose demands must also be considered. Further, as the environment changes or as the project enters a new stage of its life cycle, you may be required to cycle through the stakeholder management model again to verify that your old man- agement strategies are still effective. If, on the other hand, you deem that new circumstances make it necessary to alter those strategies, you must work through this stakeholder management model anew to update the relevant information.

2.3 organIzatIonal structure

The word structure implies organization. People who work in an organization are grouped so that their efforts can be channeled for maximum efficiency. organizational structure consists of three key elements:20

1. Organizational structure designates formal reporting relationships, including the number of levels in the hierarchy and the span of control of managers and supervisors. Who reports to whom in the structural hierarchy? This is a key component of a firm’s structure. A span of control determines the number of subordinates directly reporting to each supervisor. In some structures, a manager may have a wide span of control, suggesting a large number of subor- dinates, while other structures mandate narrow spans of control and few individuals report- ing directly to any supervisor. For some companies, the reporting relationship may be rigid and bureaucratic; other firms require flexibility and informality across hierarchical levels.

2. Organizational structure identifies the grouping together of individuals into departments and departments into the total organization. How are individuals collected into larger groups? Starting with the smallest, units of a structure continually recombine with other units to create larger groups, or organizations of individuals. These groups, referred to as departments, may be grouped along a variety of different logical patterns. For example, among the most common reasons for

48 Chapter 2 • The Organizational Context

creating departments are (1) function—grouping people performing similar activities into similar departments, (2) product—grouping people working on similar product lines into departments, (3) geography—grouping people within similar geographical regions or physical locations into depart- ments, and (4) project—grouping people involved in the same project into a department. We will discuss some of these more common departmental arrangements in detail later in this chapter.

3. Organizational structure includes the design of systems to ensure effective communication, coordination, and integration of effort across departments. This third feature of organizational structure refers to the supporting mechanisms the firm relies on to reinforce and promote its structure. These supporting mechanisms may be simple or complex. In some firms, a method for ensuring effective communication is simply to mandate, through rules and procedures, the manner in which project team members must communicate with one another and the types of information they must routinely share. Other companies use more sophisticated or complex methods for promoting coordination, such as the creation of special project offices apart from the rest of the company where project team members work for the duration of the project. The key thrust behind this third element in organizational structure implies that simply creating a logical ordering or hierarchy of personnel for an organization is not sufficient unless it is also supported by systems that ensure clear communication and coordination across the departments.

It is also important to note that within the project management context two distinct structures operate simultaneously, and both affect the manner in which the project is accomplished. The first is the overall structure of the organization that is developing the project. This structure consists of the arrangement of all units or interest groups participating in the development of the project; it includes the project team, the client, top management, functional departments, and other relevant stakeholders. The second structure at work is the internal structure of the project team; it specifies the relationship between members of the project team, their roles and responsibilities, and their interaction with the project manager. The majority of this chapter examines the larger structure of the overall organization and how it pertains to project management. The implications of internal project team structure will be discussed here but explored more thoroughly in Chapter 6.

2.4 ForMs oF organIzatIonal structure

Organizations can be structured in an infinite variety of ways, ranging from highly complex to extremely simple. What is important to understand is that typically the structure of an organization does not happen by chance; it is the result of a reasoned response to forces acting on the firm. A num- ber of factors routinely affect the reasons why a company is structured the way it is. Operating envi- ronment is among the most important determinants or factors influencing an organization’s structure. An organization’s external environment consists of all forces or groups outside the organization that have the potential to affect the organization. Some elements in a company’s external environment that can play a significant role in a firm’s activities are competitors, customers in the marketplace, the government and other legal or regulatory bodies, general economic conditions, pools of available human or financial resources, suppliers, technological trends, and so forth. In turn, these organiza- tional structures, often created for very sound reasons in relation to the external environment, have a strong impact on the manner in which projects are best managed within the organization. As we will see, each organizational type offers its own benefits and drawbacks as a context for creating projects.

Some common structural types classify the majority of firms. These structure types include the following:

1. Functional organizations—Companies are structured by grouping people performing similar activities into departments.

2. Project organizations—Companies are structured by grouping people into project teams on temporary assignments.

3. Matrix organizations—Companies are structured by creating a dual hierarchy in which functions and projects have equal prominence.

Functional organizations

The functional structure is probably the most common organizational type used in business today. The logic of the functional structure is to group people and departments performing similar activi- ties into units. In the functional structure, it is common to create departments such as accounting,

2.4 Forms of Organizational Structure 49

Board of Directors

Chief Executive

Vice President of Marketing

Vice President of Finance

Vice President of Research

New Product Development


Research Labs


Market Research


After-Market Support







Accounting Services



Employee Benefits

Vice President of Production

FIgure 2.4 example of a functional organizational Structure

marketing, or research and development. Division of labor in the functional structure is not based on the type of product or project supported, but rather according to the type of work performed. In an organization having a functional structure, members routinely work on multiple projects or support multiple product lines simultaneously.

Figure 2.4 shows an example of a functional structure. Among the clear strengths of the functional organization is efficiency; when every accountant is a member of the accounting department, it is possible to more efficiently allocate the group’s services throughout the orga- nization, account for each accountant’s work assignments, and ensure that there is no duplica- tion of effort or unused resources. Another advantage is that it is easier to maintain valuable intellectual capital when all expertise is consolidated under one functional department. When you need an expert on offshore tax implications for globally outsourced projects, you do not have to conduct a firmwide search but can go right to the accounting department to find a resi- dent expert.

The most common weakness in a functional structure from a project management perspec- tive relates to the tendency for employees organized this way to become fixated on their concerns and work assignments to the exclusion of the needs of other departments. This idea has been labeled functional siloing, named for the silos found on farms (see Figure 2.5). Siloing occurs when similar people in a work group are unwilling or unable to consider alternative viewpoints, col- laborate with other groups, or work in cross-functional ways. For example, within Data General Corporation, prior to its acquisition by EMC, squabbles between engineering and sales were con- stant. The sales department complained that its input to new product development was mini- mized as the engineering department routinely took the lead on innovation without meaningful consultation with other departments. Likewise, Robert Lutz, former President of Chrysler, argued that an ongoing weakness at the automobile company was the inability of the various functional departments to cooperate with and recognize the contributions of each other. Another weakness of functional structures is a generally poor responsiveness to external opportunities and threats. Communication channels tend to run up and down the hierarchy, rather than across functional boundaries. This vertical hierarchy can overload, and decision making takes time. Functional structures also may not be very innovative due to the problems inherent in the design. With siloed functional groups typically having a restricted view of the overall organization and its goals, it is difficult to achieve the cross-functional coordination necessary to innovate or respond quickly to market opportunities.

For project management, an additional weakness of the functional structure is that it provides no logical location for a central project management function. Top management may assign a project and delegate various components of that project to specialists within the dif- ferent functional groups. Overall coordination of the project, including combining the efforts of the different functions assigned to perform project tasks, must then occur at a higher, top management level. A serious drawback for running projects in this operating environment is

50 Chapter 2 • The Organizational Context

Vice President of Marketing

Vice President of Research

New Product Development


Board of Directors

Chief Executive

Research Labs


Market Research


After-Market Support


Vice President of Production






Vice President of Finance

Accounting Services



Employee Benefits

FIgure 2.5 the Siloing effect found in functional Structures

that they often must be layered, or applied on top of the ongoing duties of members of func- tional groups. The practical effect is that individuals whose main duties remain within their functional group are assigned to staff projects; when employees owe their primary allegiance to their own department, their frame of reference can remain functional. Projects can be tem- porary distractions in this sense, taking time away from “real work.” This can explain some of the behavioral problems that occur in running projects, such as low team member motivation or the need for extended negotiations between project managers and department supervisors for personnel to staff project teams.

Another project-related problem of the functional organization is the fact that it is easy to suboptimize the project’s development.21 When the project is developed as the brainchild of one department, that group’s efforts may be well considered and effective. In contrast, departments not as directly tied to or interested in the project may perform their duties to the minimum pos- sible level. A successful project-based product or service requires the fully coordinated efforts of all functional groups participating in and contributing to the project’s development.

Another problem is that customers are not the primary focus of everyone within the function- ally structured organization. The customer in this environment might be seen as someone else’s problem, particularly among personnel whose duties tend to be supportive. Customer require- ments must be met, and projects must be created with a customer in mind. Any departmental representatives on the project team who have not adopted a “customer-focused” mind-set add to the possibility of the project coming up short.

Summing up the functional structure (see Table 2.2), as it relates to the external environment, the functional structure is well suited to firms with relatively low levels of external uncertainty because their stable environments do not require rapid adaptation or responsiveness. When the environment is relatively predictable, the functional structure works well because it emphasizes efficiency. Unfortunately, project management activities within the functionally organized firm can often be problematic when they are applied in settings for which this structure’s strengths are not well suited. As the above discussion indicates, although there are some ways in which the func- tional structure can be advantageous to managing projects, in the main, it is perhaps the poorest form of structure when it comes to getting the maximum performance out of project management assignments.22

Project organizations

Project organizations are those that are set up with their exclusive focus aimed at running projects. Construction companies, large manufacturers such as Boeing or Airbus, pharmaceutical firms, and many software consulting and research and development organizations are organized as pure

2.4 Forms of Organizational Structure 51

table 2.2 Strengths and Weaknesses of functional Structures

Strengths for Project Management Weaknesses for Project Management

1. Projects are developed within the basic func- tional structure of the organization, requiring no disruption or change to the firm’s design.

1. Functional siloing makes it difficult to achieve cross-functional cooperation.

2. Enables the development of in-depth knowledge and intellectual capital.

2. Lack of customer focus.

3. Allows for standard career paths. Project team members only perform their duties as needed while maintaining maximum connection with their functional group.

3. Projects generally take longer to complete due to structural problems, slower communication, lack of direct ownership of the project, and competing priorities among the functional departments.

4. Projects may be suboptimized due to varying interest or commitment across functional boundaries.

project organizations. Within the project organization, each project is a self-contained business unit with a dedicated project team. The firm assigns resources from functional pools directly to the project for the time period they are needed. In the project organization, the project manager has sole control over the resources the unit uses. The functional departments’ chief role is to coordinate with project managers and ensure that there are sufficient resources available as they need them.

Figure 2.6 illustrates a simple form of the pure project structure. Projects Alpha and Beta have been formed and are staffed by project team members from the company’s functional groups. The project manager is the leader of the project and the staff all report to her. The staffing decisions and duration of employees’ tenure with the project are left to the discretion of the project manager, who is the chief point of authority for the project. As the figure suggests, there are several advan- tages to the use of a pure project structure.

• First, the project manager does not occupy a subordinate role in this structure. All major deci- sions and authority remain under the control of the project manager.

• Second, the functional structure and its potential for siloing or communication problems are bypassed. As a result, communication improves across the organization and within the proj- ect team. Because authority remains with the project manager and the project team, decision making is speeded up. Project decisions can occur quickly, without lengthy delays, as func- tional groups are consulted or allowed to veto project team decisions.

Vice President of Projects

Vice President of Production

Vice President of Marketing

Vice President of Finance

Vice President of Research

Board of Directors

Chief Executive

Project Alpha

Project Beta

FIgure 2.6 example of a Project organizational Structure

52 Chapter 2 • The Organizational Context

table 2.3 Strengths and Weaknesses of Project Structures

Strengths for Project Management Weaknesses for Project Management

1. Assigns authority solely to the project manager.

1. Setting up and maintaining teams can be expensive.

2. Leads to improved communication across the organization and among functional groups.

2. Potential for project team members to develop loyalty to the project rather than to the overall organization.

3. Promotes effective and speedy decision making.

3. Difficult to maintain a pooled supply of intellectual capital.

4. Promotes the creation of cadres of project management experts.

4. Concern among project team members about their future once the project ends.

5. Encourages rapid response to market opportunities.

• Third, this organizational type promotes the expertise of a cadre of project management professionals. Because the focus for operations within the organization is project-based, everyone within the organization understands and operates with the same focus, ensuring that the organization maintains highly competent project management resources.

• Finally, the pure project structure encourages flexibility and rapid response to environmental opportunities. Projects are created, managed, and disbanded routinely; therefore, the abil- ity to create new project teams as needed is common and team formation can be quickly undertaken.

Although there are a number of advantages in creating dedicated project teams using a proj- ect structure (see Table 2.3), this design does have some disadvantages that should be considered.

• First, the process of setting up and maintaining a number of self-contained project teams can be expensive. The different functional groups, rather than controlling their resources, must provide them on a full-time basis to the different projects being undertaken at any point. This can result in forcing the project organization to hire more project specialists (e.g., engineers) than they might need otherwise, with a resulting loss of economies of scale.

• Second, the potential for inefficient use of resources is a key disadvantage of the pure project organization. Organizational staffing may fluctuate up and down as the number of projects in the firm increases or decreases. Hence, it is possible to move from a state in which many projects are running and organizational resources are fully employed to one in which only a few projects are in the pipeline, with many resources underutilized. In short, manpower requirements across the organization can increase or decrease rapidly, making staffing prob- lems severe.

• Third, it is difficult to maintain a supply of technical or intellectual capital, which is one of the advantages of the functional structure. Because resources do not typically reside within the functional structure for long, it is common for them to shift from project to project, prevent- ing the development of a pooled knowledge base. For example, many project organizations hire technically proficient contract employees for various project tasks. These employees may perform their work and, once finished and their contract is terminated, leave the organi- zation, taking their expertise with them. Expertise resides not within the organization, but differentially within the functional members who are assigned to the projects. Hence, some team members may be highly knowledgeable while others are not sufficiently trained and capable.

• A fourth problem with the pure project form has to do with the legitimate concerns of project team members as they anticipate the completion of the project. What, they wonder, will be in their future once their project is completed? As noted above, staffing can be inconsistent, and often project team members finish a project only to discover that they are not needed for new assignments. Functional specialists in project organizations do not have the kind of permanent “home” that they would have in a functional organization, so their concerns are

2.4 Forms of Organizational Structure 53

justified. In a similar manner, it is common in pure project organizations for project team members to identify with the project as their sole source of loyalty. Their emphasis is project- based and their interests reside not with the larger organization, but within their own project. When a project is completed, they may begin searching for new challenges, and may even leave the company for appealing new assignments.

Matrix organizations

One of the more innovative organization designs to emerge in the past 30 years has been the matrix structure. The matrix organization, which is a combination of functional and project activities, seeks a balance between the functional organization and the pure project form. The way it achieves this balance is to emphasize both function and project focuses at the same time. In practical terms, the matrix structure creates a dual hierarchy in which there is a balance of authority between the project emphasis and the firm’s functional departmentalization. Figure 2.7 illustrates how a matrix organization is set up; note that the vice president of projects occupies a unique reporting relation- ship in that the position is not formally part of the organization’s functional department structure. The vice president is the head of the projects division and occupies one side of the dual hierarchy, a position shared with the CEO and heads of functional departments.

Figure 2.7 also provides a look at how the firm staffs project teams. The vice president of projects controls the activities of the project managers under his authority. They, however, must work closely with functional departments to staff their project teams through loans of personnel from each functional group. Whereas in functional organizations project team personnel are still almost exclusively under the control of the functional departments and to some degree serve at the pleasure of their functional boss, in the matrix organizational structure these personnel are shared by both their departments and the project to which they are assigned. They remain under the authority of both the project manager and their functional department supervisor. Notice, for example, that the project manager for Project Alpha has negotiated the use of two resources (personnel) from the vice president of marketing, 1.5 resources from production, and so forth. Each project and project manager is responsible for working with the functional heads to determine the optimal staffing needs, how many people are required to perform necessary project activities, and when they will be available. Questions such as “What tasks must be accomplished on this proj- ect?” are best answered by the project manager. However, other equally important questions, such as “Who will perform the tasks?” and “How long should the tasks take?”, are matters that must be jointly negotiated between the project manager and the functional department head.

Vice President of Projects

Project Alpha

Vice President of Production

Vice President of Marketing

Vice President of Finance

Vice President of Research

Board of Directors

Chief Executive

Project Beta

2 resources

1 resource 2 resources 2 resources 2.5 resources

3 resources1.5 resources 1 resource

FIgure 2.7 example of a Matrix organizational Structure

54 Chapter 2 • The Organizational Context

It is useful to distinguish between three common forms of the matrix structure: the weak matrix (sometimes called the functional matrix), the balanced matrix, and the strong matrix (sometimes referred to as a project matrix). In a weak matrix, functional departments maintain control over their resources and are responsible for managing their components of the project. The project manager’s role is to coordinate the activities of the functional departments, typically as an administrator. She is expected to prepare schedules, update project status, and serve as the link between the depart- ments with their different project deliverables, but she does not have direct authority to control resources or make significant decisions on her own. The goal of the balanced matrix is to equally distribute authority and resource assignment responsibility between the project manager and the functional department head. In a strong matrix, the balance of power has further shifted in favor of the project manager. She now controls most of the project activities and functions, including the assignment and control of project resources, and has key decision-making authority. Although func- tional managers have some input into the assignment of personnel from their departments, their role is mostly consultative. The strong matrix is probably the closest to a “project organization” mentality that we can get while working within a matrix environment.

Creating an organizational structure with two bosses may seem awkward, but there are some important advantages to this approach, provided certain conditions are met. Matrix structures are useful under circumstances in which:23

1. There is pressure to share scarce resources across product or project opportunities. When an organization has scarce human resources and a number of project opportunities, it faces the challenge of using its people and material resources as efficiently as possible to support the maximum number of projects. A matrix structure provides an environment in which the company can emphasize efficient use of resources for the maximum number of projects.

2. There is a need to emphasize two or more different types of output. For example, the firm may need to promote its technical competence (using a functional structure) while continu- ally creating a series of new products (requiring a project structure). With this dual pressure for performance, there is a natural balance in a matrix organization between the functional emphasis on technical competence and efficiency and the project focus on rapid new product development.

3. The environment of the organization is complex and dynamic. When firms face the twin challenges of complexity and rapidly shifting environmental pressures, the matrix structure promotes the exchange of information and coordination across functional boundaries.

In the matrix structure, the goal is to create a simultaneous focus on the need to be quickly responsive to both external opportunities and internal operating efficiencies. In order to achieve this dual focus, equal authority must reside within both the project and the functional groups. One advantage of the matrix structure for managing projects is that it places project management parallel to functional departments in authority. This advantage highlights the enhanced status of the project manager in this structure, who is expected to hold a similar level of power and control over resources as department managers. Another advantage is that the matrix is specifically tailored to encour- age the close coordination between departments, with an emphasis on producing projects quickly and efficiently while sharing resources among projects as they are needed. Unlike the functional structure, in which projects are, in effect, layered over a structure that is not necessarily supportive of their processes, the matrix structure balances the twin demands of external responsiveness and internal efficiency, creating an environment in which projects can be performed expeditiously. Finally, because resources are shared and “movable” among multiple projects, there is a greater likelihood that expertise will not be hoarded or centered on some limited set of personnel, as in the project orga- nization, but will be diffused more widely across the firm.

Among the disadvantages of the matrix structure’s dual hierarchy is the potentially negative effect that creating multiple authority points has on operations. When two parts of the organiza- tion share authority, the workers caught between them can experience great frustration when they receive mixed or conflicting messages from the head of the project group and the head of their functional departments. Suppose that the vice president of projects signaled the need for workers to concentrate their efforts on a critical project with a May 1 deadline. If, at the same time, the head of finance were to tell his staff that with tax season imminent, it was necessary for his employees to ignore projects for the time being to finish tax-related work, what might happen? From the team member’s perspective, this dual hierarchy can be very frustrating. Workers daily experience

2.4 Forms of Organizational Structure 55

a sense of being pulled in multiple directions as they receive conflicting instructions from their bosses—both on projects and in their departments. Consequently, ordinary work often becomes a balancing act based on competing demands for their time.

Another disadvantage is the amount of time and energy required by project managers in meetings, negotiations, and other coordinative functions to get decisions made across multiple groups, often with different agendas. Table 2.4 summarizes the strengths and weaknesses of the matrix structure.

Although matrix structures seem to be a good solution for project management, they require a great deal of time to be spent coordinating the use of human resources. Many project managers com- ment that as part of the matrix, they devote a large proportion of their time to meetings, to resolving or negotiating resource commitments, and to finding ways to share power with department heads. The matrix structure offers some important benefits and drawbacks from the perspective of managing projects. It places project management on an equal footing with functional efficiency and promotes cross-functional coordination. At the same time, however, the dual hierarchy results in some signifi- cant behavioral challenges as authority and control within the organization are constantly in a state of flux.24 A common complaint from project managers operating in matrix organizations is that an enor- mous amount of their time is taken up with “playing politics” and bargaining sessions with functional managers to get the resources and help they need. In a matrix, negotiation skills, political savvy, and networking become vital tools for project managers who want to be successful.

Moving to heavyweight Project organizations

The term heavyweight project organization refers to the belief that organizations can sometimes gain tremendous benefits from creating a fully dedicated project organization.25 The heavyweight project organization concept is based on the notion that successful project organizations do not happen by chance or luck. Measured steps in design and operating philosophy are needed to get to the top and remain there. Taking their formulation from the “Skunkworks” model, named after the famous Lockheed Corporation programs, autonomous project teams represent the final acknowledgment by the firm of the priority of project-based work in the company. In these orga- nizations, the project manager is given full authority, status, and responsibility to ensure project success. Functional departments are either fully subordinated to the projects or the project teams are accorded an independent resource base with which to accomplish their tasks.

In order to achieve the flexibility and responsiveness that the heavyweight organization can offer, it is important to remember some key points. First, no one goes directly to the autonomous team stage when it comes to running projects. This project organizational form represents the last transitional stage in a systematically planned shift in corporate thinking. Instead, managers gradu- ally move to this step through making conscious decisions about how they are going to improve the way they run projects. Successful project firms work to expand the authority of the project manager, often in the face of stiff resistance from functional department heads who like the power balance the way it currently exists. Part of the process of redirecting the power balance involves giving project managers high status, authority to conduct performance evaluations of team mem- bers, authority over project resources, and direct links to the customers. Project managers who are constantly forced to rely on the good graces of functional managers for their team staffing, coor- dination, and financial and other resources are operating with one hand tied behind their backs.

table 2.4 Strengths and Weaknesses of Matrix Structures

Strengths for Project Management Weaknesses for Project Management

1. Suited to dynamic environments. 1. Dual hierarchies mean two bosses.

2. Emphasizes the dual importance of project management and functional efficiency.

2. Requires significant time to be spent negotiating the sharing of critical resources between projects and departments.

3. Promotes coordination across functional units.

3. Can be frustrating for workers caught between com- peting project and functional demands.

4. Maximizes scarce resources between compet- ing project and functional responsibilities.

56 Chapter 2 • The Organizational Context

Second, heavyweight project organizations have realigned their priorities away from func- tional maintenance to market opportunism, a realignment that can occur only when the resources needed to respond rapidly to market opportunities rest with the project team rather than being controlled by higher level bureaucracies within a company. Finally, as noted throughout this book, the shift in focus for many firms toward project-based work profoundly affects the manner in which the project organization, manager, and the team operate. The new focus on the external cus- tomer becomes the driving force for operations, not simply one of several competing demands that the project team must satisfy as best they can.

Ultimately, the decision of which organizational structure is appropriate to use may simply come down to one of expediency; although it may, in fact, be desirable to conduct projects within a structure that offers maximum flexibility and authority to the project manager (the pure project structure), the fact remains that for many project managers it will be impossible to significantly influence decisions to alter the overall organizational structure in support of their project. As a result, perhaps a more appropriate question to ask is: What issues should I be aware of, given the structure of the organization within which I will be managing projects? The previous discussion in this chapter has developed this focus as our primary concern. Given the nature of the structure within which we must operate and manage our projects, what are the strengths and weaknesses of that form as it pertains to our ability to do our job as best we can? In formulating a thoughtful answer to this question, we are perhaps best positioned to understand and adapt most effectively to finding the link between our organization’s structure and project management success.

Box 2.1

Project Management research in Brief

The Impact of Organizational Structure on Project Performance

It is natural to suppose that projects may run more smoothly in some types of organizational structures than in oth- ers. Increasingly, research evidence suggests that depending on the type of project being initiated, some structural forms do, in fact, offer greater advantages in promoting successful completion of the project than others. The work of Gobeli and Larson, for example, is important in highlighting the fact that the type of structure a firm has when it runs projects will have either a beneficial or detrimental effect on the viability of the projects.

Very effective



Very ineffective

Functional organization

Functional matrix

Balanced matrix

Project matrix

Project organization

New product development


FIgure 2.8 Managers’ Perceptions of effectiveness of Various Structures on Project Success

Source: D. H. Gobeli and E. W. Larson. (1987). “Relative Effectiveness of Different Project Management Structures,” Project Management Journal, 18(2): 81–85, figure on page 83. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

2.5 Project Management Offices 57

Larson and Gobeli compared projects that had been managed in a variety of structural types, including functional, matrix, and pure project. They differentiated among three subsets of matrix structure, labeled func- tional matrix, balanced matrix, and project matrix, based on their perception of whether the matrix structure of a firm leaned more heavily toward a functional approach, an evenly balanced style, or one more favorable toward projects. After collecting data from a sample of more than 1,600 project managers, they identified those who were conducting projects in each of the five organizational types and asked them to assess the effectiveness of that particular structure in promoting or inhibiting effective project management practices. Their findings are shown in Figure 2.8, highlighting the fact that, in general, project organizations do promote an atmosphere more supportive of successful project management.

Interestingly, when Gobeli and Larson broke their sample up into new product development projects and those related to construction, their findings were largely similar, with the exception that construction projects were marginally more effective in matrix organizations. This suggests that structure plays a significant role in the creation of successful projects.26

2.5 Project ManageMent oFFIces

A project management office (PMO) is defined as a centralized unit within an organization or depart- ment that oversees or improves the management of projects.27 It is seen as a center for excellence in project management in many organizations, existing as a separate organizational entity or subunit that assists the project manager in achieving project goals by providing direct expertise in vital project management duties such as scheduling, resource allocation, monitoring, and controlling the project. PMOs were originally developed in recognition of the poor track record that many organizations have demonstrated in running their projects. We cited some sobering statistics on the failure rates of IT proj- ects, for example, in Chapter 1, indicating that the majority of such projects are likely to fail.

PMOs were created in acknowledgment of the fact that a resource center for project manage- ment within a company can offer tremendous advantages. First, as we have noted, project managers are called upon to engage in a wide range of duties, including everything from attending to the human side of project management to handling important technical details. In many cases, these individuals may not have the time or ability to handle all the myriad technical details—the activity scheduling, resource allocation, monitoring and control processes, and so forth. Using a PMO as a resource center shifts some of the burden for these activities from the project manager to a support staff that is dedi- cated to providing this assistance. Second, it is clear that although project management is emerging as a profession in its own right, there is still a wide gap in knowledge and expectations placed on project managers and their teams. Simply put, they may not have the skills or knowledge for handling a num- ber of project support activities, such as resource leveling or variance reporting. Having trained proj- ect management professionals available through a PMO creates a “clearinghouse” effect that allows project teams to tap into expertise when they need it.

Another benefit of the PMO is that it can serve as a central repository of all lessons learned, project documentation, and other pertinent record keeping for ongoing projects, as well as for past projects. This function allows all project managers a central access to past project records and lessons learned materials, rather than having to engage in a haphazard search for these documents through- out the organization. A fourth benefit of the PMO is that it serves as the dedicated center for project management excellence in the company. As such, it becomes the focus for all project management pro- cess improvements that are then diffused to other organizational units. Thus, the PMO becomes the place in which new project management improvements are first identified, tested, refined, and finally, passed along to the rest of the organization. Each project manager can use the PMO as a resource, trusting that they will make themselves responsible for all project management innovations.

A PMO can be placed in any one of several locations within a firm.28 As Figure 2.9 demon- strates, the PMO may be situated at a corporate level (Level 3) where it serves an overall corporate support function. It can be placed at a lower functional level (Level 2) where it serves the needs within a specific business unit. Finally, the PMO can be decentralized down to the actual proj- ect level (Level 1) where it offers direct support for each project. The key to understanding the function of the PMO is to recognize that it is designed to support the activities of the project man- ager and staff, not replace the manager or take responsibility for the project. Under these circum- stances, we see that the PMO can take a lot of the pressure off the project manager by handling the

58 Chapter 2 • The Organizational Context

administration duties, leaving the project manager free to focus on the equally important people issues, including leading, negotiating, customer relationship building, and so forth.

Although Figure 2.9 gives us a sense of where PMOs may be positioned in the organization and, by extension, clues to their supporting role depending on how they are structured, it is also helpful to consider some of the PMO models. PMOs have been described as operating under one of three alternative forms and purposes in companies: (1) weather station, (2) control tower, and (3) resource pool.29 Each of these models has an alternative role for the PMO.

1. Weather station—Under the weather station model, the PMO is typically used only as a tracking and monitoring device. In this approach, the assumption is often one in which top management, feeling nervous about committing money to a wide range of projects, wants a weather station as a tracking device, to keep an eye on the status of the projects without directly attempting to influence or control them. The weather station PMO is intended to house independent observers who focus almost exclusively on some key questions, such as: • What’s our progress? How is the project progressing against the original plan? What key

milestones have we achieved? • How much have we paid for the project so far? How do our earned value projections look?

Are there any budgetary warning signals? • What is the status of major project risks? Have we updated our contingency planning as

needed? 2. Control tower—The control tower model treats project management as a business skill to

be protected and supported. It focuses on developing methods for continually improving project management skills by identifying what is working, where the shortcomings exist, and how to resolve ongoing problems. Most importantly, unlike the weather station model, which monitors project management activities only to report results to top management, the control tower is a model that is intended to directly work with and support the activities of the project manager and team. In doing so, it performs four functions: • Establishes standards for managing projects—The control tower model of the PMO is

designed to create a uniform methodology for all project management activities, including duration estimation, budgets, risk management, scope development, and so forth.

PO Level 3

PO Level 2

Level 1

Project A

Project B

PO Project C

Business Unit CorporateSupport

Chief Operating Officer

Sales Delivery Support



FIgure 2.9 Alternative levels of Project offices

Source: W. Casey and W. Peck. (2001). “Choosing the Right PMO Setup,” PMNetwork, 15(2): 40–47, figure on page 44. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

2.6 Organizational Culture 59

• Consults on how to follow these standards—In addition to determining the appropriate standards for running projects, the PMO is set up to help project managers meet those stan- dards through providing internal consultants or project management experts throughout the development cycle as their expertise is needed.

• Enforces the standards—Unless there is some process that allows the organization to enforce the project management standards it has developed and disseminated, it will not be taken seriously. The control tower PMO has the authority to enforce the standards it has established, either through rewards for excellent performance or sanctions for refusal to abide by the standard project management principles. For example, the PMO for Accident Fund Insurance Co. of America has full authority to stop projects that it feels are violating accepted practices or failing to bring value to the company.

• Improves the standards—The PMO is always motivated to look for ways to improve the current state of project management procedures. Once a new level of project performance has been created, under a policy of continuous improvement, the PMO should already be exploring how to make good practices better.

3. Resource pool—The goal of the resource pool PMO is to maintain and provide a cadre of trained and skilled project professionals as they are needed. In essence, it becomes a clear- inghouse for continually upgrading the skills of the firm’s project managers. As the company initiates new projects, the affected departments apply to the resource pool PMO for assets to populate the project team. The resource pool PMO is responsible for supplying project managers and other skilled professionals to the company’s projects. In order for this model to be implemented successfully, it is important for the resource pool to be afforded sufficiently high status within the organization that it can bargain on an equal footing with other top managers who need project managers for their projects. Referring back to Figure 2.7, the resource pool model seems to work best when the PMO is generally viewed as a Level 3 support structure, giving the head of the PMO the status to maintain control of the pool of trained project managers and the authority to assign them as deemed appropriate.

The PMO concept is rapidly being assimilated in a number of companies. However, it has some critics. For example, some critics contend that it is a mistake to “place all the eggs in one basket” with PMOs by concentrating all project professionals in one location. This argument suggests that PMOs actually inhibit the natural, unofficial dissemination of project skills across organizational units by maintaining them at one central location. Another potential pitfall is that the PMO, if its philosophy is not carefully explained, can simply become another layer of oversight and bureaucracy within the organization; in effect, rather than freeing up the project team by performing supporting functions, it actually handcuffs the project by requiring additional administrative control. Another potential dan- ger associated with the use of PMOs is that they may serve as a bottleneck for communications flow across the organization,30 particularly between the parent organization and the project’s customer.

Although some of the criticisms of PMOs contain an element of truth, they should not be used to avoid the adoption of a project office under the right circumstances. The PMO is, at its core, recognition that project management skill development must be encouraged and reinforced, that many organizations have great need of standardized project practices, and that a central, support- ing function can serve as a strong source for continuous project skill improvement. Viewed in this light, the PMO concept is likely to gain in popularity in the years to come.

2.6 organIzatIonal culture

The third key contextual variable in how projects are managed effectively is that of organizational culture. So far, we have examined the manner in which a firm’s strategy affects its project manage- ment, and how projects and portfolios are inextricably tied to a company’s vision and serve to operationalize strategic choices. Structure constitutes the second piece of the contextual puzzle, and we have demonstrated how various organizational designs can help or hinder the project management process. Now we turn to the third contextual variable: an organization’s culture and its impact on managing projects.

One of the unique characteristics of organizations is the manner in which each develops its own outlook, operating policies and procedures, patterns of thinking, attitudes, and norms of behavior. These characteristics are often as unique as an individual’s fingerprints or DNA

60 Chapter 2 • The Organizational Context

signature; in the same way, no two organizations, no matter how similar in size, products, operat- ing environment, or profitability, are the same. Each has developed its own unique method for indoctrinating its employees, responding to environmental threats and opportunities, and sup- porting or discouraging operating behaviors. In other settings, such as anthropology, a culture is seen as the collective or shared learning of a group, and it influences how that group is likely to respond in different situations. These ideas are embedded in the concept of organizational culture. One of the original writers on culture defined it as “the solution to external and internal problems that has worked consistently for a group and that is therefore taught to new members as the correct way to perceive, think about, and feel in relation to these problems.”31

Travel around Europe and you will quickly become immersed in a variety of cultures. You will discern the unique cultural characteristics that distinguish nationalities, such as the Finnish and Swedish. Differences in language, social behavior, family organization, and even religious beliefs clearly demonstrate these cultural differences. Even within a country, cultural attitudes and values vary dramatically. The norms, attitudes, and common behaviors of northern and southern Italians lead to differences in dress, speech patterns, and even evening dining times. One of the key elements in courses on international business identifies cultural differences as patterns of unique behavior, so that business travelers or those living in other countries will be able to recognize “appropriate” standards of behavior and cultural attitudes, even though these cultural patterns may be very different from those of the traveler’s country or origin.

For project team members who are called upon to work on projects overseas, or who are linked via the Internet and e-mail to other project team members from different countries, developing an appreciation for cross-border cultural differences is critical. The values and attitudes expressed by these various cultures are strong regulators of individual behavior; they define our belief systems and work dedication, as well as our ability to function on cross-cultural project teams.

Research has begun to actively explore the impact that workplace cultures have on the per- formance of projects and the manner in which individual project team members decide whether or not they will commit to its goals. Consider two contrasting examples the author has witnessed: In one Fortune 500 company, functional department heads for years have responded to all resource requests from project managers by assigning their worst, newest, or lowest-performing personnel to these teams. In effect, they have treated projects as dumping grounds for malcontents or poor performers. In this organization, project teams are commonly referred to as “leper colonies.” It is easy to imagine the response of a member of the firm to the news that he has just been assigned to a new project! On the other hand, I have worked with an IT organization where the unspoken rule is that all departmental personnel are to make themselves available as expert resources when their help is requested by a project manager. The highest priority in the company is project delivery, and all other activities are subordinated to achieving this expectation. It is common, during particu- larly hectic periods, for IT members to work 12-plus hours per day, assisting on 10 or more projects at any time. As one manager put it, “When we are in crunch time, titles and job descriptions don’t mean anything. If it has to get done, we are all responsible—jointly—to make sure it gets done.”

The differences in managing projects at the companies illustrated in these stories are striking, as is the culture that permeates their working environment and approach to project delivery. Our definition of culture can be directly applied in both of these cases to refer to the unwritten rules of behavior, or norms that are used to shape and guide behavior, that are shared by some subset of organizational members, and that are taught to all new members of the company. This definition has some important elements that must be examined in more detail:

• Unwritten—Cultural norms guide the behavior of each member of the organization but are often not written down. In this way, there can be a great difference between the slogans or inspirational posters found on company walls and the real, clearly understood culture that establishes standards of behavior and enforces them for all new company members. For example, Erie Insurance, annually voted one of the best companies to work for, has a strong, supportive culture that emphasizes and rewards positive collaboration between functional groups. Although the policy is not written down, it is widely held, understood by all, and taught to new organization members. When projects require the assistance of personnel from multiple departments, the support is expected to be there.

• Rules of behavior—Cultural norms guide behavior by allowing us a common language for understanding, defining, or explaining phenomena and then providing us with guidelines

2.6 Organizational Culture 61

as to how best to react to these events. These rules of behavior can be very powerful and commonly held: They apply equally to top management and workers on the shop floor. However, because they are unwritten, we may learn them the hard way. For example, if you were newly hired as a project engineer and were working considerably slower or faster than your coworkers, it is likely that one of them would quickly clue you in on an acceptable level of speed that does not make you or anyone else look bad by comparison.

• Held by some subset of the organization—Cultural norms may or may not be companywide. In fact, it is very common to find cultural attitudes differing widely within an organization. For example, blue-collar workers may have a highly antagonistic attitude toward top management; members of the finance department may view the marketing function with hostility and vice versa; and so forth. These “subcultures” reflect the fact that an organization may contain a num- ber of different cultures, operating in different locations or at different levels. Pitney-Bowes, for example, is a maker of postage meters and other office equipment. Its headquarters unit reflects an image of stability, orderliness, and prestige. However, one of its divisions, Pitney-Bowes Credit Corporation (PBCC), headquartered in Shelton, Connecticut, has made a name for itself by purposely adopting an attitude of informality, openness, and fun. Its décor, featuring fake gas lamps, a French café, and Internet surfing booths, has been described as resembling an “indoor theme park.” PBCC has deliberately created a subculture that reflects its own approach to busi- ness, rather than adopting the general corporate vision.32 Another example is the Macintosh project team’s approach to creating a distinct culture at Apple while they were developing this revolutionary system, to the point of being housed in different facilities from the rest of the com- pany and flying a pirate flag from the flagpole!

• Taught to all new members—Cultural attitudes, because they are often unwritten, may not be taught to newcomers in formal ways. New members of an organization pick up the behaviors as they observe others engaging in them. In some organizations, however, all new hires are immersed in a formal indoctrination program to ensure that they understand and appreciate the organization’s culture. The U.S. Marines, for example, take pride in the process of indoctrination and training for all recruits, which develops a collective, committed attitude toward the Marine Corps. Google takes its new indoctrination procedures (“onboarding”) seriously. The company, which onboarded over 7,000 new hires in 2013, has experimented with its orientation procedures to help new employees, called “Nooglers,” make more social connections and get up to speed more quickly. General Electric also sends new employees away for orientation, to be “tattooed with the meatball,” as members of the company refer to the GE logo.

On the other hand, when allowed to get out of control, a culture can quickly become toxic and work against the goals of the organization. For example, the Australian Olympic swim team has historically been one of the strongest competitors at the summer competition and yet, in London in 2012, the team managed to win just one gold medal, a stunningly poor result. An independent review, commissioned in the aftermath of their performance, focused the blame on a failure of leadership and culture on the team. The report cited a “toxic” culture involving “bullying, the mis- use of prescription drugs, and a lack of discipline.” The worst performance in 20 years was directly attributable to a lack of moral authority and discipline among team members.33

how do cultures Form?

When it is possible to view two organizations producing similar products within the context of very individualistic and different cultures, the question of how cultures form gets particularly interesting. General Electric’s Jet Engine Division and Rolls-Royce share many features, includ- ing product lines. Both produce jet engines for the commercial and defense aircraft industries. However, GE prides itself on its competitive, high-pressure culture that rewards aggressiveness and high commitment, but also has a high “burnout” rate among engineers and mid-level manag- ers. Rolls-Royce, on the other hand, represents an example of a much more paternalistic culture that rewards loyalty and long job tenure.

Researchers have examined some of the powerful forces that can influence how a company’s culture emerges. Among the key factors that affect the development of a culture are technology, environment, geographical location, reward systems, rules and procedures, key organizational members, and critical incidents.34

62 Chapter 2 • The Organizational Context

technology The technology of an organization refers to its conversion process whereby it trans- forms inputs into outputs. For example, the technology of many project organizations is the project development process in which projects are developed to fill a current need or anticipate a future opportunity. The technical means for creating projects can be highly complex and automated or relatively simple and straightforward. Further, the projects may be in the form of products or ser- vices. Research suggests that the type of technology used within a project organization can influ- ence the culture that it promotes. “High-technology” organizations represent an example of how a fast-paced, technologically based culture can permeate through an organization.

envIronMent Organizations operate under distinct environmental pressures. A firm’s environ- ment may be complex and rapidly changing, or it may remain relatively simple and stable. Some firms are global, because their competition is literally worldwide, while other companies focus on regional competition. Regardless of the specific circumstances, a company’s environment affects the culture of the firm. For example, companies with simple and slow-changing environments may develop cultures that reinforce low risk taking, stability, and efficiency. Firms in highly complex environments often develop cultures aimed at promoting rapid response, external scanning for opportunities and threats, and risk taking. In this way, the firm’s operating environment affects the formation of the culture and the behaviors that are considered acceptable within it. For example, a small, regional construction firm specializing in commercial real estate development is likely to have more stable environmental concerns than a Fluor-Daniel or Bechtel, competing for a variety of construction projects on a worldwide basis.

geograPhIcal locatIon Different geographical regions develop their own cultural mores and attitudes. The farther south in Europe one travels, for example, the later the evening meal is typi- cally eaten; in Spain, dinner may commence after 9 pm. Likewise, in the business world, culturally based attitudes often coordinate with the geographical locations of firms or subsidiaries. It can even happen within countries: Xerox Corporation, for example, had tremendous difficulty in try- ing to marry the cultures of its corporate headquarters in Connecticut with the more informal and down-to-earth mentalities of its Palo Alto Research Center (PARC) personnel. Projects at one site were done much differently than those undertaken at another location. It is important not to over- state the effect that geography can play, but it certainly can result in cultural disconnects, particu- larly in cases where organizations have developed a number of dispersed locations, both within and outside of their country of origin.

reward systeMs The types of rewards that a firm offers to employees go a long way toward demonstrating the beliefs and actions its top management truly values, regardless of what official company policies might be. Reward systems support the view that, in effect, a company gets what it pays for. An organization that publicly espouses environmental awareness and customer service but routinely promotes project managers who violate these principles sends a loud message about its real interests. As a result, the culture quickly forms around acts that lead to pollution, dishon- esty, or obfuscation. One has only to look at past business headlines regarding corporate malfea- sance at Enron, WorldCom, Goldman Sachs, or Adelphia Cable Company to see how the culture of those organizations rewarded the type of behavior that ultimately led to accounting fraud, public exposure, and millions of dollars in fines.

rules and Procedures One method for influencing a project management culture is to create a rulebook or system of procedures for employees to clarify acceptable behavior. The idea behind rules and procedures is to signal companywide standards of behavior to new employees. The obvious problem arises when public or formal rules conflict with informal rules of behavior. At Texas Instruments headquarters in Dallas, Texas, a formal rule is that all management staff works a standard 40-hour workweek. However, the informal rule is that each member of the company is really expected to work a 45-hour week, at a minimum, or as one senior manager explained to a newly hired employee, “Here, you work nine hours each day: eight for you and one for TI.” In spite of the potential for disagreements between formal and informal rules, most programs in creating supportive project-based organizations argue that the first step toward improving patterns of behavior is to formally codify expectations in order to alter dysfunctional project cultures. Rules and procedures, thus, represent a good starting point for developing a strong project culture.

2.6 Organizational Culture 63

key organIzatIonal MeMbers Key organizational members, including the founder of the or- ganization, have a tremendous impact on the culture that emerges within the company. When the founder is a traditional entrepreneur who encourages free expression or flexibility, this attitude becomes ingrained in the organization’s culture in a powerful way. The founders of Ben and Jerry’s Ice Cream, two proud ex-hippies, created a corporate culture that was unique and expressed their desire to develop a “fun” alternative to basic capitalism. A corporate culture in which senior execu- tives routinely flaunt the rules or act contrary to stated policies demonstrates a culture in which there is one rule for the people at the top and another for everyone else.

crItIcal IncIdents Critical incidents express culture because they demonstrate for all workers exactly what it takes to succeed in an organization. In other words, critical incidents are a public expression of what rules really operate, regardless of what the company formally espouses. Critical incidents usually take the form of stories that are related to others, including new employees, illus- trating the types of actions that are valued. They become part of the company’s lore, either for good or ill. In a recent year, General Electric’s Transportation Systems Division built up a large backlog of orders for locomotives. The company galvanized its production facilities to work overtime to complete this backlog of work. As one member of the union related, “When you see a unit vice president show up on Saturday, put on an environmental suit, and work on the line spray painting locomotives with the rest of the workers, you realize how committed the company was to getting this order completed on time.”

organizational culture and Project Management

What are the implications of an organizational culture on the project management process? Culture can affect project management in at least four ways. First, it affects how departments are expected to interact and support each other in pursuit of project goals. Second, the culture influences the level of employee commitment to the goals of the project on balance with other, potentially com- peting goals. Third, the organizational culture influences project planning processes such as the way work is estimated or how resources are assigned to projects. Finally, the culture affects how managers evaluate the performance of project teams and how they view the outcomes of projects.

• Departmental interaction—Several of the examples cited in this chapter have focused on the importance of developing and maintaining a solid, supportive relationship between functional departments and project teams. In functional and matrix organizations, power either resides directly with department heads or is shared with project managers. In either case, the manner in which these department heads approach their willingness to support projects plays a hugely important role in the success or failure of new project initiatives. Not surprisingly, cultures that favor active cooperation between functional groups and new projects are much more success- ful than those that adopt a disinterested or even adversarial relationship.

• Employee commitment to goals—Projects depend on the commitment and motivation of the personnel assigned to their activities. A culture that promotes employee commitment and, when necessary, self-sacrifice through working extra hours or on multiple tasks is much more successful than a culture in which the unwritten rules seem to imply that, provided you don’t get caught, there is nothing wrong with simply going through the motions. AMEC Corporation, for example, takes its training of employees seriously when it comes to instill- ing a commitment to safety. AMEC is a multinational construction company, headquartered in Canada. With annual revenues of nearly $7 billion and 29,000 employees, AMEC is one of the largest construction firms in the world. It takes its commitment to core values extremely seriously, impressing upon all employees their responsibilities to customers, business part- ners, each other, the company, and the wider social environment. From the moment new people enter the organization, they are made aware of the need to commit to the guiding principles of ethical behavior, fairness, commitment to quality, and safety.35

• Project planning—We will explore the process of activity duration estimation in a later chapter; however, for now it is important just to note that the way in which employees decide to support the project planning processes is critical. Because activity estimation is often an imprecise process, it is common for some project team members to “pad” their estimates to give themselves as much time as possible. These people are often responding to a culture that reinforces the idea that it is better to engage in poor estimation and project planning than to be late with deliverables.

64 Chapter 2 • The Organizational Context

Conversely, when there is a culture of trust among project team members, they are more inclined to give honest assessments, without fearing that, should they be wrong, they will be punished for our mistakes.

• Performance evaluation—Supportive cultures encourage project team members taking the initiative, even if it means taking risks to boost performance. When a culture sends the signal that the goal of the firm is to create innovative products, it reinforces a project management culture that is aggressive and offers potentially high payoffs (and the occasional significant loss!). As noted earlier, organizations get what they pay for. If the reward systems are posi- tive and reinforce a strong project mentality, they will reap a whirlwind of opportunities. On the other hand, if they tacitly support caution and playing it safe, the project management approaches will equally reflect this principle.

A culture can powerfully affect the manner in which departments within an organization view the process of project management. The culture also influences the manner in which employees commit themselves to the goals of their projects as opposed to other, potentially competing goals. Through symbols, stories, and other signs, companies signal their commitment to project manage- ment. This message is not lost on members of project teams, who take their cues regarding expected performance from supervisors and other cultural artifacts. Visible symbols of a culture that advo- cates cross-functional cooperation will create employees who are prepared and motivated to work in harmony with other groups on project goals. Likewise, when an IT department elevates some of its members to hero status because they routinely went the extra mile to handle system user complaints or problems, the company has sent the message that they are all working toward the same goals and all provide value to the organization’s operations, regardless of their functional background.

To envision how culture can influence the planning and project monitoring processes, suppose that, in your organization, it was clear that those involved in late projects would be severely punished for the schedule slippage. You and your fellow project team members would quickly learn that it is critical to avoid going out on a limb to promise early task completion dates. It is much safer to grossly overestimate the amount of time necessary to complete a task in order to protect yourself. The orga- nizational culture in this case breeds deceit. Likewise, it may be safer in some organizations to delib- erately hide information in cases where a project is running off track, or mislead top management with optimistic and false estimates of project progress. Essentially, the issue is this: Does the corporate culture encourage authentic information and truthful interactions, or is it clear that the safer route is to first protect yourself, regardless of the effect this behavior may have on the success of a project?

Project Profile

electronic Arts and the Power of Strong culture in Design teams

Electronic Arts is one of the top computer gaming companies in the world, known for perennial console and PC best- sellers like Madden NFL, FIFA, Battlefield, Need for Speed, the Sims, and more. In the computer gaming industry, speed to market for new games is critical. Making award-winning games requires a combination of talented designers, graphic artists, programmers, and testers, all working to constantly update best-selling games and introduce new choices for the gaming community. It is a fast-paced environment that thrives on a sense of chaos and disruptive new technologies and ideas. In this setting, the former head of the EA Labels group, Frank Gibeau, has developed a winning formula for game design. He doesn’t believe in large teams for developing games; instead his goal is to preserve each studio’s cul- ture by supporting its existing talent.

Gibeau’s belief is that the best games come from small teams with strong cultures. One of his principles is to limit the size of project teams to promote their commitment to each other and to the quality of the games they design. Gibeau notes that when too many people get involved, there is a law of diminishing returns that sets in, because every- thing becomes too hard to manage – too many people, too many problems. In addition, it’s easier to maintain a unique culture when teams are kept small and allowed to stay in place for an extended time. As a result, EA supports the use of smaller teams over a longer period of time to get the game right. As a result, he is careful to ensure that the different studios don’t over-expand and get too big. Gibeau remains a firm believer in the “small is better” philosophy because it supports dynamic cultures and action-oriented attitudes.

Electronic Arts’ approach to game design is centered on small teams, given the opportunity to work as freely as possible, maintain their distinctive group identities, and thereby promote a strong internal culture. EA executives have recognized that these unique team cultures are critical for encouraging the kind of creativity and commitment to the work that make for technologically advanced games, so necessary for maintaining a competitive edge in a rapidly evolving industry.36

Summary 65

What are some examples of an organization’s culture influencing how project teams actually perform and how outcomes are perceived? One common situation is the phenomenon known as escalation of commitment. It is not uncommon to see this process at work in project organizations. escalation of commitment occurs when, in spite of evidence identifying a project as failing, no longer necessary, or beset by huge technical or other difficulties, organizations continue to support it past the point an objective assessment would suggest that it should be terminated.37 Although there are a number of reasons for escalation of commitment to a failed decision, one important rea- son is the unwillingness of the organization to acknowledge failure or its culture’s working toward blinding key decision makers to the need to take corrective action.

The reverse is also true: In many organizations, projects are managed in an environment in which the culture strongly supports cross-functional cooperation, assigns sufficient resources to enable project managers to schedule aggressively, and creates an atmosphere that makes it pos- sible to develop projects optimally. It is important to recognize that an organization’s culture can be a strong supporter of (as well as an inhibitor to) the firm’s ability to manage effective projects. Because of this impact, organizational culture must be managed, constantly assessed, and, when necessary, changed in ways that promote project management rather than discouraging its effi- cient practice.

The context within which we manage our projects is a key determinant in the likelihood of their success or failure. Three critical contextual factors are the organization’s strategy, structure, and culture. Strategy drives projects; projects operationalize strategy. The two must work together in harmony. The key is maintaining a clear linkage between overall strategy and the firm’s portfo- lio of projects, ensuring that some form of alignment exists among all key elements: vision, objec- tives, strategies, goals, and programs. Further, companies are recognizing that when they adopt a structure that supports projects, they get better results. Likewise, when the cultural ambience of the organization favors project management approaches, they are much more likely to be suc- cessful. Some of these project management approaches are the willingness to take risks, to think creatively, to work closely with other functional departments, and so forth. More and more we are seeing successful project-based organizations recognizing the simple truth that the context in which they are trying to create projects is a critical element in seeing their projects through to com- mercial and technical success.


1. Understand how effective project management contributes to achieving strategic objectives. This chapter linked projects with corporate strategy. Projects are the “building blocks” of strategy because they serve as the most basic tools by which firms can implement previously formulated objectives and strategies.

2. recognize three components of the corporate strategy model: formulation, implementation, and evaluation. The chapter explored a generic model of corporate strategic management, distinguishing between the three components of strategy formulation, strategy implementation, and strategy evaluation. Each of these compo- nents incorporates a number of subdimensions. For example, strategy formulation includes the stages of:

• Developing a vision and mission. • Performing an internal audit (assessing

strengths and weaknesses). • Performing an external audit (assessing

opportunities and threats).

• Establishing long-term objectives. • Generating, evaluating, and selecting strategies.

Strategy implementation requires the coordi- nation of managerial, technological, financial, and functional assets to reinforce and support strategies. Projects often serve as the means by which strategy implementation is actually realized. Finally, strategy evaluation requires an ability to measure results and provide feedback to all concerned parties.

3. see the importance of identifying critical proj- ect stakeholders and managing them within the context of project development. The chapter addresses a final strategic question: the relation- ship between the firm and its stakeholder groups. Project stakeholders are either internal to the firm (top management, other functional depart- ments, support personnel, internal customers) or external (suppliers, distributors, intervenors, governmental agencies and regulators, and customers). Each of these stakeholder groups must be managed in a systematic manner; the process

66 Chapter 2 • The Organizational Context

moves from identification to needs assessment, choice of strategy, and routine evaluation and adjustment. Stakeholder management, in con- junction with strategic management, forms the context by which projects are first evaluated and then managed.

4. recognize the strengths and weaknesses of three basic forms of organizational structure and their implications for managing projects. We exam- ined the strengths and weaknesses of three major organizational structure types, including func- tional, project, and matrix structures. The nature of each of the three structural types and their relationship to project management were addressed. The functional structure, while the most common type of organizational form, was shown to be per- haps the least effective type for managing projects due to a variety of limitations. The project structure, in which the organization uses its projects as the primary form of grouping, has several advantages for managing projects, although it has some general disadvantages as well. Finally, the matrix structure, which seeks to balance the authority and activities between projects and functions using a dual hier- archy system, demonstrates its own unique set of strengths and weaknesses for project management practice.

5. Understand how companies can change their structure into a “heavyweight project organiza- tion” structure to facilitate effective project man- agement practices. The movements within many organizations to a stronger customer focus in their project management operations has led to the creation of a heavyweight project organization, in which the project manager is given high levels of authority in order to further the goals of the project. Because customer satisfaction is the goal of these organizations, they rely on their project managers to work toward project success within the frame- work of greater control of project resources and direct contact with clients.

6. identify the characteristics of three forms of proj- ect management office (PMo). Project manage- ment offices (PMOs) are centralized units within an organization or department that oversee or improve the management of projects. There are three predominant types of PMO in organizations. The weather station is typically used only as a tracking and monitoring device. In this approach, the role of the PMO is to keep an eye on the status of the projects without directly attempting to influence or control them. The second form of PMO is the con- trol tower, which treats project management as a business skill to be protected and supported. It focuses on developing methods for continu- ally improving project management skills by

identifying what is working, where the shortcom- ings exist, and methods for resolving ongoing prob- lems. Most importantly, unlike the weather station model, which only monitors project management activities to report results to top management, the control tower is a model that is intended to directly work with and support the activities of the project manager and team. Finally, the resource pool is a PMO intended to maintain and provide a cadre of trained and skilled project professionals as they are needed. It serves as a clearinghouse for continually upgrading the skills of the firm’s project managers. As the company initiates new projects, the affected departments apply to the resource pool PMO for assets to populate the project team.

7. Understand key concepts of corporate culture and how cultures are formed. Another contextual factor, organizational culture, plays an important role in influencing the attitudes and values shared by members of the organization, which, in turn, affects their commitment to project management and its practices. Culture is defined as the unwrit- ten rules of behavior, or the norms that are used to shape and guide behavior, that are shared by some subset of organizational members and are taught to all new members of the company. When the firm has a strong culture that is supportive of project goals, members of the organization are more likely to work collaboratively, minimize departmental loyalties that could take precedence over proj- ect goals, and commit the necessary resources to achieve the objectives of the project.

Organizational cultures are formed as the result of a variety of factors, including technology, environ- ment, geographical location, reward systems, rules and procedures, key organizational members, and critical incidents. Each of these factors can play a role in determining whether the organization’s culture is strong, collaborative, customer-focused, project- oriented, fast-paced, and so forth.

8. recognize the positive effects of a supportive organizational culture on project management practices versus those of a culture that works against project management. Finally, this chapter examined the manner in which supportive cultures can work in favor of project management and ways in which the culture can inhibit project success. One common facet of a “sick” culture is the escalation of a commitment problem, in which key members of the organization continue to increase their support for clearly failing courses of action or problematic projects. The reasons for escalation are numerous, including our prestige is on the line, the conviction that we are close to succeeding, fear of ridicule if we admit to failure, and the culture of the organization in which we operate.

Key Terms

Balanced matrix (p. 54) Culture (p. 60) Escalation of commitment (p. 65) External environment (p. 48) Functional structure (p. 48) Heavyweight project organization (p. 55)

Intervenor groups (p. 42) Matrix organization (p. 53) Matrix structure (p. 53) Objectives (p. 39) Organizational culture (p. 60) Organizational structure (p. 47)

Project management office (p. 57) Project organizations (p. 50 ) Project stakeholders (p. 41) Project structure (p. 51) Resources (p. 53)

Stakeholder analysis (p. 41) Strategic management (p. 39) Strong matrix (p. 54) Technology (p. 62) TOWS matrix (p. 40) Weak matrix (p. 54)

Discussion Questions

2.1 The chapter suggests that a definition of strategic man- agement includes four components: a. Developing a strategic vision and sense of mission b. Formulating, implementing, and evaluating c. Making cross-functional decisions d. Achieving objectives Discuss how each of these four elements is important in un- derstanding the challenge of strategic project management. How do projects serve to allow an organization to realize each of these four components of strategic management?

2.2 Discuss the difference between organizational objectives and strategies.

2.3 Your company is planning to construct a nuclear power plant in Oregon. Why is stakeholder analysis important as a precondition of the decision whether or not to follow through with such a plan? Conduct a stakeholder analysis for a planned upgrade to a successful software product. Who are the key stakeholders?

2.4 Consider a medium-sized company that has decided to begin using project management in a wide variety of its operations. As part of its operational shift, it is going to adopt a project management office somewhere within the organization. Make an argument for the type of PMO it should adopt (weather station, control tower, or resource pool). What are some key decision criteria that will help it determine which model makes the most sense?

2.5 What are some of the key organizational elements that can affect the development and maintenance of a sup- portive organizational culture? As a consultant, what

advice would you give to a functional organization that was seeking to move from an old, adversarial culture, where the various departments actively resisted helping one another, to one that encourages “project thinking” and cross-functional cooperation?

2.6 You are a member of the senior management staff at XYZ Corporation. You have historically been using a functional structure setup with five departments: finance, human re- sources, marketing, production, and engineering. a. Create a drawing of your simplified functional struc-

ture, identifying the five departments. b. Assume you have decided to move to a project struc-

ture. What might be some of the environmental pressures that would contribute to your belief that it is necessary to alter the structure?

c. With the project structure, you have four ongoing proj- ects: stereo equipment, instrumentation and testing equipment, optical scanners, and defense communica- tions. Draw the new structure that creates these four proj- ects as part of the organizational chart.

2.7 Suppose you now want to convert the structure from that in Question 6 to a matrix structure, emphasizing dual commitments to function and project. a. Re-create the structural design to show how the matrix

would look. b. What behavioral problems could you begin to anticipate

through this design? That is, do you see any potential points of friction in the dual hierarchy setup?

CaSe STuDy 2.1 Rolls-Royce Corporation


Although the name Rolls-Royce is inextricably linked with its ultra-luxurious automobiles, the modern Rolls- Royce operates in an entirely different competitive en- vironment. A leading manufacturer of power systems for aerospace, marine, and power companies, Rolls’s market is focused on developing jet engines for a variety of uses, both commercial and defense-related.

In this market, the company has two principal competi- tors, General Electric and Pratt & Whitney (owned by United Technologies). There are a limited number of smaller, niche players in the jet engine market, but their impact from a technical and commercial perspective is minor. Rolls, GE, and Pratt & Whitney routinely engage in fierce competition for sales to defense contractors

Case Study 2.1 67

68 Chapter 2 • The Organizational Context

and the commercial aviation industry. The two main airframe manufacturers, Boeing and Airbus, make continual multimillion-dollar purchase decisions that are vital for the ongoing success of the engine makers. Airbus, a private consortium of several European part- ner companies, has drawn level with Boeing in sales in recent years. Because the cost of a single jet engine, in- cluding spare parts, can run to several million dollars, winning large orders from either defense or commer- cial aircraft builders represents an ongoing challenge for each of the “big three” jet engine manufacturers.

Airlines in developing countries can often be a lucra- tive but risky market for these firms. Because the countries do not maintain high levels of foreign exchange, it is not unknown, for example, for Rolls (or its competitors) to take partial payment in cash with assorted commodities to pay the balance. Hence, a contract with Turkey’s national airline may lead to some monetary payment for Rolls, along with several tons of pistachios or other trade goods! To maintain their sales and service targets, these jet engine makers routinely resort to creative financing, long-term contracts, or asset-based trading deals. Overall, however, the market for jet engines is projected to continue to expand at huge rates. Rolls-Royce projects a 20-year window with a potential market demand of 70,000 engines, valued at over $400 billion in civil aerospace alone. When defense contracts are factored in as well, the revenue projections for jet engine sales are likely to be enormous. As Rolls sees the future, the single biggest market growth opportunity is in the larger, greater thrust engines, designed to be paired with larger jet aircraft.

Rolls-Royce is currently engaged in a strategic decision that offers the potential for huge payoffs or sig- nificant losses as it couples its latest engine technology, the “Trent series,” with Airbus’s decision to develop an ultra-large commercial aircraft for long-distance travel. The new Airbus design, the 380 model, seats more than 550 people, flying long-distance routes (up to 8,000 miles). The Trent 900, with an engine rating of 70,000 pounds thrust per engine, has been created at great expense to see service in the large jet market. The proj- ect reflects a strategic vision shared by both Airbus and Rolls-Royce that the commercial passenger market will triple in the next 20 years. As a result, future opportu- nities will involve larger, more economically viable air- craft. Since 2007, Airbus has delivered a total of 40 A380s to its customers, with 17 in 2010. Their total order book currently sits at 234 aircraft ordered. Collectively, Airbus and Rolls-Royce have taken a large financial gamble that their strategic vision of the future is the correct one.


1. Who are Rolls’s principal project management stakeholders? How would you design stakeholder management strategies to address their concerns?

2. Given the financial risks inherent in developing a jet engine, make an argument, either pro or con, for Rolls to develop strategic partnerships with other jet engine manufacturers in a manner similar to Airbus’s consortium arrangement. What are the benefits and drawbacks in such an arrangement?

CaSe STuDy 2.2 Classic Case: Paradise Lost—The Xerox Alto38

Imagine the value of cornering the technological market in personal computing. How much would a five-year window of competitive advantage be worth to a company today? It could easily mean billions in revenue, a stellar industry reputation, future earnings ensured—and the list goes on. For Xerox Corporation, however, something strange happened on the way to industry leadership. In 1970, Xerox was uniquely positioned to take advantage of the enormous leaps forward it had made in office au- tomation technology. Yet the company stumbled badly through its own strategic myopia, lack of nerve, structural inadequacies, and poor choices. This is the story of the Xerox Alto, the world’s first personal computer and one of the great “what if?” stories in business history.

The Alto was not so much a step forward as it was a quantum leap. Being in place and operating at the end of 1973, it was the first stand-alone personal computer to combine bit-mapped graphics, a mouse, menu screens,

icons, an Ethernet connection, a laser printer, and word processing software. As a result of the combined efforts of an impressive collection of computer science geniuses headquartered at Xerox’s Palo Alto Research Center (PARC), the Alto was breathtaking in its innovative appeal. It was PARC’s answer to Xerox’s top management command to “hit a home run.” Xerox had profited earlier from just such a home run in the form of the Model 914 photocopier, a technological innovation that provided the impetus to turn Xerox into a billion-dollar company in the 1960s. The Alto represented a similar achievement.

What went wrong? What forces combined to ensure that no more than 2,000 Altos were produced and that none was ever brought to market? (They were used only inside the company and at some university sites.) The answer could lie in the muddled strategic thinking that took place at Xerox while the Alto was in development.

I recently worked with an organization that adopted a mind-set in which it was assumed that the best way to keep project team members working hard was to unilaterally trim their task duration estimates by 20%. Suppose that you were asked to estimate the length of time necessary to write computer code for a particular software product and you determined that it should take about 80 hours. Knowing you were about to present this informa- tion to your supervisor and that she was going to immedi- ately cut the estimate by 20%, what would be your course of action? You would probably first add a “fudge factor” to the estimate in order to protect yourself. The conversation with the boss might go something like this:

Boss “Have you had a chance to estimate that coding sequence yet?”

You Yes, it should take me 100 hours.”

Boss “That’s too long. I can only give you 80 hours, tops.”

You (Theatrical sigh) “Well, if you say so, but I really don’t know how I can pull this off.”

Once you leave the office and shut the door, you turn with a smile and whisper, “Gotcha!”


1. How does the organization’s culture support this sort of behavior? What pressures does the manager face? What pressures does the subordinate face?

2. Discuss the statement, “If you don’t take my esti- mates seriously, I’m not going to give you serious estimates!” How does this statement apply to this example?

CaSe STuDy 2.3 Project Task Estimation and the Culture of “Gotcha!”

The history of Xerox during this period shows a company that stepped back from technological leader- ship into a form of incrementalism, making it content to follow IBM’s lead in office automation. Incrementalism refers to adopting a gradualist approach that plays it safe, avoiding technological leaps, large risks, and con- sequently the possibility of large returns. In 1974, Xerox decided to launch the Model 800 magnetic tape word processor rather than the Alto because the Model 800 was perceived as the safer bet. During the next five years, a series of ill-timed acquisitions, lawsuits, and reorgani- zations rendered the Alto a casualty of inattention. What division would oversee its development and launch? Whose budget would support it, and PARC in general? By leaving such tough decisions unmade, Xerox wasted valuable time and squandered its technological window of opportunity. Even when clear indications showed that competitor Wang was in line to introduce its own line of office systems, Xerox could not take the step to bring the Alto to market. By 1979, Xerox’s unique opportunity was lost. No longer was the Alto a one-of-a-kind tech- nology, and the company quietly shelved any plans for its commercial introduction.

Perhaps the ultimate irony is this: Here was a company that had made its name through the phenom- enal success of a highly innovative product, the Model 914 photocopier, but it did not know how to handle the opportunities presented by the next phenomenon. The Alto was so advanced that the company seemed unable to comprehend its possibilities. Executives did not have a strategic focus that emphasized a continual

progression of innovation. Instead, they were directed toward remaining neck-and-neck with the competition in an incremental approach. When competitor IBM released a new electric typewriter, Xerox responded in the same incremental way. The organizational structure at Xerox did not allow any one division or key manager to become the champion for new technologies like the Alto.

In 1979 Steven Jobs, president of Apple Computer, was given a tour of the PARC complex and saw an Alto in use. He was so impressed with the machine’s features and operating capabilities that he asked when it was due to be commercially launched. When told that much of this technology had been developed in 1973, Jobs became “physically sick,” he later recounted, at the thought of the opportunity Xerox had forgone.


1. Do you see a logical contradiction in Xerox’s will- ingness to devote millions of dollars to support pure research sites like PARC and its refusal to commercially introduce the products developed?

2. How did Xerox’s strategic vision work in favor of or against the development of radical new tech- nologies such as the Alto?

3. What other unforeseeable events contributed to making Xerox’s executives unwilling to take any new risks precisely at the time the Alto was ready to be released?

4. “Radical innovation cannot be too radical if we want it to be commercially successful.” Argue ei- ther in favor of or against this statement.

Case Study 2.3 69

70 Chapter 2 • The Organizational Context

Widgets ’R Us (WRU) is a medium-sized firm specializ- ing in the design and manufacturing of quality widgets. The market for widgets has been stable. Historically, WRU has had a functional organization design with four departments: accounting, sales, production, and engineering. This design has served the company well, and it has been able to compete by being the low-priced company in the industry.

In the past three years, the demand for widgets has exploded. New widgets are constantly being developed to feed the public’s seemingly insatiable demand. The average life cycle of a newly released widget is 12–15 months. Unfortunately, WRU is find- ing itself unable to compete successfully in this new, dynamic market. The CEO has noted a number of problems. Products are slow to market. Many new

innovations have passed right by WRU because the company was slow to pick up signs from the mar- ketplace that they were coming. Internal communi- cation is very poor. Lots of information gets kicked “upstairs,” and no one seems to know what hap- pens to it. Department heads constantly blame other department heads for the problems.


1. You have been called in as a consultant to analyze the operations at WRU. What would you advise?

2. What structural design changes might be under- taken to improve the operations at the company?

3. What are the strengths and weaknesses of the alternative solutions the company could employ?

CaSe STuDy 2.4 Widgets ’R Us

2.1 Wegmans has been consistently voted one of the 100 best com- panies to work for in the United States by Fortune magazine. In fact, in 2005 it was ranked number 1, and in 2012 it was ranked number 4. Go to its Web site,, and click on “About Us.” What messages, formal and informal, are being conveyed about Wegmans through its Web site? What does the Web site imply about the culture of the organization?

2.2 Go to the Web site and ana- lyze some of the case studies found on the Web site. What do these cases suggest about the importance of assessing stakeholder expectations for a project before it has begun its development process? In other words, what are the risks of waiting to address stakeholder concerns until after a project has begun?

2.3 Go to a corporate Web site of your choice and access the organizational chart. What form of organization does this chart represent: functional, project, matrix, or some other form? Based on our discussion in this chapter, what would be the likely strengths and weaknesses of this organiza- tion’s project management activities?

2.4 Access the corporate Web site for Fluor-Daniel Corporation and examine its “Compliance and Ethics” section at www. default.aspx. What does the “Fluor Code of Business Conduct and Ethics” suggest about the way the company does business? What are the strategic goals and directions that naturally flow from the ethical code? In your opinion, how would the ethics statement influence the manner in which the company manages its projects?

PMP certificAtion sAMPle QUestions

1. What is the main role of the functional manager? a. To control resources b. To manage the project when the project manager

isn’t available c. To define business processes d. To manage the project manager

2. What is the typical role of senior management on a project? a. Support the project b. Pay for it c. Support the project and resolve resource and other

conflicts d. Resolve resource and other conflicts

3. What is an organization that controls project managers, documentation, and policies called?

a. Project management office b. Strong matrix c. Functional d. Pure project

4. A business analyst has a career path that has been very important to her throughout the 10 years of her career. She is put on a project with a strong matrix organiza- tional structure. Which of the following is likely viewed as a negative of being on the project?

a. Being away from the group and on a project that might make it more difficult to get promoted

b. Working with people who have similar skills

Internet exercises

c. Working long hours because the project is a high priority

d. Not being able to take her own certification tests because she is so busy

5. The functional manager is planning the billing system replacement project with the newest project manager at the company. In discussing this project, the functional manager focuses on the cost associated with running the system after it is created and the number of years the system will last before it must be replaced. What best describes what the functional manager is focusing on?

a. Project life cycle b. Product life cycle c. Project management life cycle d. Program management life cycle

Internet Exercises 71

Answers: 1. a—The functional manager runs the day-to-day operations of his department and controls the resources; 2. c—Because senior managers usually outrank the project manager, they can help with resolving any resource or other conflicts as they arise; 3. a—The project management office (PMO) typically has all of these responsibilities; 4. a—Being away from her functional group may cause her to feel that her efforts on behalf of the project are not being recognized by her functional manager, since the project employs a strong matrix structure; 5. b—The functional manager is focusing on the product life cycle, which is developed based on an example of a successful project and encompasses the range of use for the product.

72 Chapter 2 • The Organizational Context

inteGrAteD Project

Building Your Project Plan

exercIse 1—develoPIng the Project narratIve and goals You have been assigned to a project team to develop a new product or service for your organiza- tion. Your challenge is to first decide on the type of product or service you wish to develop. The project choices can be flexible, consisting of options as diverse as construction, new product devel- opment, IT implementation, and so forth.

Develop a project scope write-up on the project you have selected. Your team is expected to cre- ate a project history, complete with an overview of the project, an identifiable goal or goals (including project targets), the general project management approach to be undertaken, and significant proj- ect constraints or potential limiting effects. Additionally, if appropriate, identify any basic resource requirements (i.e., personnel or specialized equipment) needed to complete the project. What is most important at this stage is creating a history or narrative of the project you have come up with, includ- ing a specific statement of purpose or intent (i.e., why the project is being developed, what it is, what niche or opportunity it is aimed to address).

The write-up should fully explain your project concept, constraints, and expectations. It is not necessary to go into minute detail regarding the various subactivities or subcomponents of the project; it is more important to concentrate on the bigger picture for now.

saMPle background analysIs and Project narratIve For abcuPs, Inc. Founded in 1990, ABCups, Inc., owns and operates 10 injection-molding machines that produce plastic drinkware. ABCups’s product line consists of travel mugs, thermal mugs, steins, and sports tumblers. The travel mugs, thermal mugs, and steins come in two sizes: 14 and 22 ounces. The sports tumblers are offered only in the 32-ounce size. All products except the steins have lids. The travel and thermal mugs consist of a liner, body, and lid. The steins and sports tumblers have no lining. There are 15 colors offered, and any combination of colors can be used. The travel and thermal mugs have a liner that needs to be welded to the outer body; subcontractors and screen printers weld the parts together. ABCups does no welding, but it attaches the lid to the mug. ABCups’s customer base consists primarily of distributors and promotional organizations. Annual sales growth has remained steady, averaging 2%–3% each year. Last year’s revenues from sales were $70 million.

current Process ABCups’s current method for producing its product is as follows:

1. Quote job. 2. Receive/process order. 3. Schedule order into production. 4. Mold parts. 5. Issue purchase order to screen printer with product specifications. 6. Ship parts to screen printer for welding and artwork. 7. Receive returned product from screen printer for final assembly and quality control. 8. Ship product to customer.

At current processing levels, the entire process can take from two to four weeks, depending on order size, complexity, and the nature of current production activity.

overvIew oF the Project Because of numerous complaints and quality rejects from customers, ABCups has determined to proactively resolve outstanding quality issues. The firm has determined that by bringing welding and screen printing functions “in-house,” it will be able to address the current quality problems,

Goals targets

1. Meet all project deadlines without jeopardizing customer satis- faction within a one-year project time frame.

Excellent = 0 missed deadlines Good = 1–5 missed deadlines Acceptable = <8 missed deadlines

2. Deplete dependence on subcontracted screen printing by 100% within six months without increasing customer’s price or decreasing product quality.

Excellent = 100% independence Good = 80–99% independence Acceptable = 60–79% independence

3. Perform all process changes without affecting current customer delivery schedules for the one-year project time frame.

Excellent = 0% delivery delays Good = <5% delivery delays Acceptable = 5–10% delivery delays

4. Decrease customer wait time over current wait time within one year without decreasing quality or increasing price.

Excellent = 2/3 decrease in wait time Good = 1/2 decrease in wait time Acceptable = 1/3 decrease in wait time

5. Stay within 10% of capital budget without exceeding 20% within the project baseline schedule.

Excellent = 1% variance Good = 5% variance Acceptable = 10% variance

6. Decrease customer rejections by 25% within one year. Excellent = 45% reduction Good = 35% reduction Acceptable = 25% reduction


expand its market, maintain better control over delivery and order output, and be more responsive to customers. The project consists of adding three new processes (welding, screen printing, and improved quality control) to company operations.

ABCups has no experience in or equipment for welding and screen printing. The organization needs to educate itself, investigate leasing or purchasing space and equipment, hire trained workers, and create a transition from subcontractors to in-house operators. The project needs a specified date of completion so that the transition from outsourcing to company production will be smooth and products can be delivered to customers with as little disruption to shipping as possible.

Management’s strategy is to vertically integrate the organization to reduce costs, increase market share, and improve product quality. ABCups is currently experiencing problems with its vendor base, ranging from poor quality to ineffectual scheduling, causing ABCups to miss almost 20% of its customers’ desired ship dates. Maintaining complete control over the product’s development cycle should improve the quality and on-time delivery of ABCups’s product line.

Integrated Project 73

General approach

1. Managerial approach—The equipment will be purchased from outside vendors; however, ABCups’s internal employees will perform the assembly work. Given the type of equipment that is required, outside contractors will not be needed because the company’s facility em- ploys the necessary maintenance staff to set up the equipment and troubleshoot as required, once the initial training has been supplied by the vendor.

2. technical approach—The equipment manufacturers will utilize CAD to design the equip- ment. Initially, the firm will require a bank of parts to be available once the equipment arrives in order to fine-tune the machinery. Fixtures will be designed as required, but will be supplied by the machine manufacturer.


1. Budget constraints—This project must ultimately increase profitability for the company. In addition, the project will have a constraining budget. It must be shown that any additional expense for both the conversion and producing finished cups on-site will result in increased profitability.

74 Chapter 2 • The Organizational Context

1. Ramsey, M., 2014. Does Tesla Really Need a $5 Billion Battery? Wall Street Journal, April 2, pp. B1–B2.

2. David, F. R. (2001). Strategic Management, 8th ed. Upper Saddle River, NJ: Prentice Hall.

3. The Holy Bible, King James Version. Cambridge Edition: 1769; (Prov. 29:18).

4. Vision Statement of Bechtel Corporation 5. Cleland, D. I. (1998). “Strategic project management,”

in Pinto, J. K. (Ed.), Project Management Handbook. San Francisco, CA: Jossey-Bass, pp. 27–40.

6. Weihrich, H. (1982). “The TOWS matrix—A tool for situational analysis,” Long Range Planning, 15: 54–66; Hillson, D. (2002), “Extending the risk process to manage opportunities,” International Journal of Project Management, 20: 235–40.

7. Wheelen, T. L., and Hunger, J. D. (1992). Strategic Management and Business Policy, 4th ed. Reading, MA: Addison-Wesley.

8. Wiener, E., and Brown, A. (1986). “Stakeholder analy- sis for effective issues management,” Planning Review, 36: 27–31.

9. Mendelow, A. (1986). “Stakeholder analysis for strate- gic planning and implementation,” in King, W. R., and Cleland, D. I. (Eds.), Strategic Planning and Management Handbook. New York: Van Nostrand Reinhold, pp. 67–81; Winch, G. M. (2002). Managing Construction Projects. Oxford: Blackwell; Winch, G. M., and Bonke, S. (2001). “Project stakeholder mapping: Analyzing the interest of project stakeholders,” in Slevin, D. P., Cleland, D. I., and Pinto, J. K. (Eds.), The Frontiers of Project Management Research. Newtown Square, PA: PMI, pp. 385–404.

10. Wideman, R. M. (1998). “How to motivate all stake- holders to work together,” in Cleland, D. I. (Ed.), Project Management Field Guide. New York: Van Nostrand Reinhold, pp. 212–26; Hartman, F. T. (2000). Don’t Park Your Brain Outside. Newtown Square, PA: PMI.

11. Cleland, D. I. (1988). “Project stakeholder manage- ment,” in Cleland, D. I., and King, W. R. (Eds.), Project Management Handbook, 2nd ed. New York: Van Nostrand

Reinhold, pp. 275–301. 12. Vrijhoef, R., and Koskela, L. (2000). “The four roles of sup-

ply chain management in construction,” European Journal of Purchasing and Supply Management, 6: 169–78.

13. Cleland, D. I. (1988), as cited in note 12. 14. Block, R. (1983). The Politics of Projects. New York: Yourdon

Press. 15. Manyika, J., Chui, M., Bughin, J., Dobbs, R., Bisson, P., and

Marrs, A. (2013). Disruptive technologies: Advances that will transform life, business, and the global economy. McKinsey Global Institute. file:///C:/Users/jkp4/Downloads/ MGI_Disruptive_technologies_Executive_summary_ May2013.pdf.

16. Fisher, R., and Ury, W. (1981). Getting to Yes: Negotiating Agreement Without Giving In. New York: Houghton Mifflin.

17. Frame, J. D. (1987). Managing Projects in Organizations. San Francisco, CA: Jossey-Bass.

18. Robert Burns, a Scottish poet and lyricist. (1759–1796). 19. Grundy, T. (1998). “Strategy implementation and project

management,” International Journal of Project Management, 16(1): 43–50.

20. Daft, R. L. (2001). Organization Theory and Design, 7th ed. Mason, OH: Southwestern; Moore, D. (2002). Project Management: Designing Effective Organizational Structures in Construction. Oxford: Blackwell; Yourker, R. (1977). “Organizational alternatives for project management,” Project Management Quarterly, 8(1): 24–33.

21. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Management, 5th ed. New York: Wiley.

22. Larson, E. W., and Gobeli, D. H. (1987). “Matrix manage- ment: Contradictions and insights,” California Management Review, 29(4): 126–37; Larson, E. W., and Gobeli, D. H. (1988). “Organizing for product development projects,” Journal of Product Innovation Management, 5: 180–90.

23. Daft, R. L. (2001). Organization Theory and Design, 7th ed. Mason, OH: Southwestern; Anderson, C. C., and Fleming, M. M. K. (1990). “Management control in an engineering matrix organization: A project engineer’s perspective,”


2. limited plant space—ABCups is assuming this conversion does not involve building a new plant or significantly increasing facility size. Space for new machinery, new employees, and storage for dyes and inventory must be created through conversion of existing floor space. If additional floor space is required, leasing or purchasing options will need to be investigated.

3. time—Since this project will require the company to break existing contracts with vendors, any missed milestones or other delays will cause an unacceptable delay to customers. A back- up plan must be in place to avoid losing customers to competitors in case the time frame is not strictly met. The conversion must be undertaken with a comprehensive project schedul- ing system developed and adhered to.

4. safety regulations—The installation and conversion activities must be in accordance with several agencies’ specifications, including but not limited to guidelines from the Occupation- al Safety and Health Administration (OSHA), the insurance carrier, and the financing agency.

5. current orders must be filled on time—All activities must be designed to avoid any delay in current orders. The transition should appear seamless to customers to avoid losing any part of the extant customer base.

Industrial Management, 32(2): 8–13; Ford, R. C., and Randolph, W. A. (1992). “Cross-functional structures: A review and integration of matrix organization and project management,” Journal of Management, 18: 267–94.

24. Larson, E. W., and Gobeli, D. H. (1987). “Matrix manage- ment: Contradictions and insights,” California Management Review, 29(4): 126–37; Larson, E. W., and Gobeli, D. H. (1988). “Organizing for product development projects,” Journal of Product Innovation Management, 5: 180–90; Engwall, M., and Kallqvist, A. S. (2000). “Dynamics of a multi-project matrix: Conflicts and coordination,” Working paper, Chalmers University, www.fenix. 2001/pdf/WP%202001- 07.pdf.

25. Wheelwright, S. C., and Clark, K. (1992). “Creating project plans to focus product development,” Harvard Business Review, 70(2): 70–82.

26. Gobeli, D. H., and Larson, E. W. (1987). “Relative effec- tiveness of different project management structures,” Project Management Journal, 18(2): 81–85; Gray, C., Dworatschek, S., Gobeli, D. H., Knoepfel, H., and Larson, E. W. (1990). “International comparison of project orga- nization structures,” International Journal of Project Management, 8: 26–32.

27. Gray, C. F., and Larson, E. W. (2003). Project Management, 2nd ed. Burr Ridge, IL: McGraw-Hill; Dai, C. (2000). The Role of the Project Management Office in Achieving Project Success. PhD Dissertation, George Washington University.

28. Block, T. (1998). “The project office phenomenon,” PMNetwork, 12(3): 25–32; Block, T. (1999). “The seven secrets of a successful project office,” PMNetwork, 13(4): 43–48; Block, T., and Frame, J. D. (1998). The Project Office. Menlo Park, CA: Crisp Publications; Eidsmoe, N. (2000). “The strategic project management office,” PMNetwork, 14(12): 39–46; Kerzner, H. (2003). “Strategic planning for the project office,” Project Management Journal, 34(2): 13–25; Dai, C. X., and Wells, W. G. (2004). “An explora- tion of project management office features and their rela- tionship to project performance,” International Journal of Project Management, 22: 523–32; Aubry, M., Müller, R., Hobbs, B., and Blomquist, T. (2010). “Project manage- ment offices in transition,” International Journal of Project Management, 28(8): 766–78.

29. Casey, W., and Peck, W. (2001). “Choosing the right PMO setup,” PMNetwork, 15(2): 40–47; Gale, S. (2009). “Delivering the goods,” PMNetwork, 23(7): 34–39.

30. Kerzner, H. (2003). Project Management, 8th ed. New York: Wiley; Englund, R. L., and Graham, R. J. (2001). “Implementing a project office for organizational change,” PMNetwork, 15(2): 48–52; Fleming, Q., and Koppelman, J. (1998). “Project teams: The role of the project office,” Cost Engineering, 40: 33–36.

31. Schein, E. (1985). Organizational Culture and Leadership: A Dynamic View. San Francisco, CA: Jossey-Bass, pp. 19–21; Schein, E. H. (1985). “How culture forms, develops and changes,” in Kilmann, R. H., Saxton, M. J., and Serpa, R. (Eds.), Gaining Control of the Corporate Culture. San Francisco, CA: Jossey-Bass, pp. 17–43; Elmes, M., and Wilemon, D. (1989). “Organizational culture and project leader effec- tiveness,” Project Management Journal, 19(4): 54–63.

32. Kirsner, S. (1998, November). “Designed for innovation,” Fast Company, pp. 54, 56; Daft, R. L. (2001). Organization Theory and Design, 7th ed. Mason, OH: Southwestern.

33. “Australian London 2012 Olympic swim team ‘toxic’” (2013, February 19). BBC News Asia,. news/world-asia-21501881.

34. Kilmann, R. H., Saxton, M. J., and Serpa, R. (1985). Gaining Control of the Corporate Culture. San Francisco, CA: Jossey-Bass.

35. “The US must do as GM has done.” (1989). Fortune, 124(2): 70–79.

36. Hillier, B. (2013, July 24), “Gibeau: ‘You get the best games from small teams with strong cultures,’” VG 24/7. www. from-small-teams-with-strong-cultures/; Takahashi, D. (2013, July 23). “EA exec Frank Gibeau: Betting on next- gen consoles, mobile, and doing right by consumers,” Venture Beat. eas-frank-gibeau-on-interview-part-1.

37. Staw, B. M., and Ross, J. (1987, March–April). “Knowing when to pull the plug,” Harvard Business Review, 65: 68–74.

38. Smith, D. K., and Alexander, R. C. (1988). Fumbling the Future: How Xerox Invented, Then Ignored, the First Personal Computer. New York: Macmillan; Kharbanda, O. P., and Pinto, J. K. (1996). What Made Gertie Galdop? New York: Van Nostrand Reinhold.

Notes 75


3 ■ ■ ■

Project Selection and Portfolio Management

Chapter Outline Project Profile

Project Selection Procedures: A Cross-Industry Sampler

introduction 3.1 Project Selection 3.2 APProAcheS to Project Screening

And Selection Method One: Checklist Model Method Two: Simplified Scoring Models Limitations of Scoring Models Method Three: The Analytical

Hierarchy Process Method Four: Profile Models

3.3 finAnciAl ModelS Payback Period Net Present Value Discounted Payback Internal Rate of Return Choosing a Project Selection Approach

Project Profile Project Selection and Screening at GE:

The Tollgate Process 3.4 Project Portfolio MAnAgeMent

Objectives and Initiatives Developing a Proactive Portfolio Keys to Successful Project Portfolio

Management Problems in Implementing Portfolio

Management Summary Key Terms Solved Problems Discussion Questions Problems Case Study 3.1 Keflavik Paper Company Case Study 3.2 Project Selection at Nova

Western, Inc. Internet Exercises Notes

Chapter Objectives After completing this chapter, you should be able to:

1. Explain six criteria for a useful project selection/screening model. 2. Understand how to employ checklists and simple scoring models to select projects. 3. Use more sophisticated scoring models, such as the Analytical Hierarchy Process. 4. Learn how to use financial concepts, such as the efficient frontier and risk/return models. 5. Employ financial analyses and options analysis to evaluate the potential for new project

investments. 6. Recognize the challenges that arise in maintaining an optimal project portfolio for an

organization. 7. Understand the three keys to successful project portfolio management.

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Portfolio Management (PMBoK sec. 1.4.2)

Project Profile

Project Selection Procedures: A cross-industry Sampler

The art and science of selecting projects is one that organizations take extremely seriously. Firms in a variety of indus- tries have developed highly sophisticated methods for project screening and selection to ensure that the projects they choose to fund offer the best promise of success. As part of this screening process, organizations often evolve their own particular methods, based on technical concerns, available data, and corporate culture and preferences. The following list gives you a sense of the lengths to which some organizations go with project selection:

• Hoechst AG, a pharmaceutical firm, uses a scoring portfolio model with 19 questions in five major categories when rating project opportunities. The five categories include probability of technical success, probability of commercial success, reward to the company, business strategy fit, and strategic leverage (ability of the project to employ and elevate company resources and skills). Within each of these factors are a number of specific questions, which are scored on a 1 to 10 scale by management.

• At German industrial giant Siemens, every business unit in each of the 190 countries in which the company oper- ates uses a system entitled “[email protected]” for categorizing projects that employs a two-digit code. Each project is awarded a letter from A to F, indicating its significance to the company, and a number from 0 to 3, indicating its overall risk level. Larger or riskier projects (e.g., an “A0”) require approval from Siemens’s main board in Germany, but many of the lesser projects (e.g., an “F3”) can be approved by local business units. Too many A0s in the portfolio can indicate mounting risks while too many F3 projects may signal a lack of economic value overall.

• The Royal Bank of Canada has developed a scoring model to rate its project opportunities. The criteria for the port- folio scoring include project importance (strategic importance, magnitude of impact, and economic benefits) and ease of doing (cost of development, project complexity, and resource availability). Expected annual expenditure and total project spending are then added to this rank-ordered list to prioritize the project options. Decision rules are used (e.g., projects of low importance that are difficult to execute get a “no-go” rating).

• The Weyerhaeuser corporate research and development (R&D) program has put processes in place to align and prioritize R&D projects. The program has three types of activities: technology assessment (changes in external en- vironment and impact to the company), research (building knowledge bases and competencies in core technical areas), and development (development of specific commercial opportunities). Four key inputs are considered when establishing priorities: significant changes in the external environment; long-term future needs of lead customers; business strategies, priorities, and technology needs; and corporate strategic direction.

• Mobil Chemical uses six categories of projects to determine the right balance of projects that will enter its portfo- lio: (1) cost reductions and process improvements; (2) product improvements, product modifications, and customer satisfaction; (3) new products; (4) new platform projects and fundamental/breakthrough research projects; (5) plant support; and (6) technical support for customers. Senior management reviews all project proposals and determines the division of capital funding across these six project types. One of the key decision variables involves a comparison of “what is” with “what should be.”

• The Texas Department of Transportation identifies several criteria in its project selection process. Infrastructure and building projects are selected by the Texas Transportation Commission based on the following criteria: safety, main- tenance and preservation of the existing system, congestion relief, access and mobility, economic vitality, efficient system management and operations, and any additional transportation goals identified in the statewide long-range transportation plans. These projects must adhere to all department design standards as well as applicable state and federal law and regulations.1

• At 3M’s Traffic Control Materials Division, during project screening and selection, management uses a project vi- ability chart to score project alternatives. As part of the profile and scoring exercise, personnel must address how the project accomplishes strategic project objectives and critical business issues affecting a specific group within the target market. Projected project return on investment is always counterbalanced with riskiness of the project option.

• Exxon Chemical’s management begins evaluating all new project proposals in light of the business unit’s strategy and strategic priorities. Target spending is decided according to the overall project mix portfolio. As the year progresses, all projects are reprioritized using a scoring model. As significant differences between projected and actual spending are uncovered, the top management group makes adjustments for the next year’s portfolio.2

Project Profile 77

78 Chapter 3 • Project Selection and Portfolio Management


All organizations select projects they decide to pursue from among numerous opportunities. What criteria determine which projects should be supported? Obviously, this is no simple decision. The consequences of poor decisions can be enormously expensive. Recent research suggests that in the realm of information technology (IT), companies squander nearly $100 billion a year on projects that are created but never used by their intended clients. How do we make the most reasonable choices in selecting projects? What kind of information should we collect? Should decisions be based strictly on financial analysis, or should other criteria be considered? In this chapter, we will try to answer such questions as we take a closer look at the process of project selection.

We will examine a number of different approaches for evaluating and selecting potential projects. The various methods for project selection run along a continuum from highly qualita- tive, or judgment-based approaches to those that rely on quantitative analysis. Of course, each approach has its benefits and drawbacks, which must be considered in turn.

We will also discuss a number of issues related to the management of a project portfolio— the set of projects that an organization is considering/undertaking at any given time. For example, Rubbermaid, Inc., routinely undertakes hundreds of new product development projects simul- taneously, always searching for opportunities with strong commercial prospects. When a firm is pursuing multiple projects, the challenges of strategic decision making, resource management, scheduling, and operational control are magnified.

3.1 Project SelectIon

Firms are literally bombarded with opportunities, but no organization enjoys infinite resources with which to pursue every opportunity that presents itself. Choices must be made, and to best ensure that they select the most viable projects, many managers develop priority systems—guidelines for balancing the opportunities and costs entailed by each alternative. The goal is to balance the compet- ing demands of time and advantage.3 The pressures of time and money affect most major decisions, and decisions are usually more successful when they are made in a timely and efficient manner. For example, if your firm’s sales department recognizes a commercial opportunity it can exploit, you need to generate alternative approaches to the project quickly to capitalize on the prospect. Time wasted is generally opportunity lost. On the other hand, you need to be careful: You want to be sure that, at least as far as possible, you are making the best choice among your options. Thus organi- zational decision makers develop guidelines—selection models—that permit them to save time and money while maximizing the likelihood of success.

A number of decision models are available to managers responsible for evaluating and selecting potential projects. As you will see, they run the gamut from qualitative to quantitative and simple to complex. All firms, however, try to develop a screening model (or set of models) that will allow them to make the best choices among alternatives within the usual constraints of time and money.

Suppose you were interested in developing a model that allowed you to effectively screen proj- ect alternatives. How might you ensure that the model was capable of picking potential “winners” from the large set of possible project choices? After much consideration, you decide to narrow the focus for your screening model and create one that will allow you to select only projects that have high potential payoffs. All other issues are ignored in favor of the sole criterion of commercial profit- ability. The question is: Would such a screening model be useful? Souder4 identifies five important issues that managers should consider when evaluating screening models:

1. Realism: An effective model must reflect organizational objectives, including a firm’s strategic goals and mission. Criteria must also be reasonable in light of such constraints on resources as money and personnel. Finally, the model must take into account both commer- cial risks and technical risks, including performance, cost, and time. That is: Will the project work as intended? Can we keep to the original budget or is there a high potential for escalat- ing costs? Is there a strong risk of significant schedule slippage?

2. Capability: A model should be flexible enough to respond to changes in the conditions under which projects are carried out. For example, the model should allow the company to compare different types of projects (long-term versus short-term projects, projects of differ- ent technologies or capabilities, projects with different commercial objectives). It should be

3.1 Project Selection 79

robust enough to accommodate new criteria and constraints, suggesting that the screening model must allow the company to use it as widely as possible in order to cover the greatest possible range of project types.

3. Flexibility: The model should be easily modified if trial applications require changes. It must, for example, allow for adjustments due to changes in exchange rates, tax laws, building codes, and so forth.

4. Ease of use: A model must be simple enough to be used by people in all areas of the organi- zation, both those in specific project roles and those in related functional positions. Further, the screening model that is applied, the choices made for project selection, and the reasons for those choices should be clear and easily understood by organizational members. The model should also be timely: It should generate the screening information rapidly, and peo- ple should be able to assimilate that information without any special training or skills.

5. Cost: The screening model should be cost-effective. A selection approach that is expensive to use in terms of either time or money is likely to have the worst possible effect: causing organizational members to avoid using it because of the excessive cost of employing it. The cost of obtaining selection information and generating optimal results should be low enough to encourage use of the models rather than diminish their applicability.

Let’s add a sixth criterion for a successful selection model:

6. Comparability: The model must be broad enough to be applied to multiple projects. If a model is too narrowly focused, it may be useless in comparing potential projects or foster biases toward some over others. A useful model must support general comparisons of project alternatives.

Project selection models come in two general classes: numeric and nonnumeric.5 numeric models seek to use numbers as inputs for the decision process involved in selecting projects. These values can be derived either objectively or subjectively; that is, we may employ objective, external values (“The bridge’s construction will require 800 cubic yards of cement”) or subjective, internal values (“We will need to hire two code checkers to finish the software development within eight weeks”). Neither of these two input alternatives is necessarily wrong: An expert’s opinion on an issue may be subjective but very accurate. On the other hand, an incorrectly calibrated surveyor’s level can give objective but wrong data. The key is to remember that most selection processes for project screening involve a combination of subjective and objective data assessment and decision making. nonnumeric models, on the other hand, do not employ numbers as decision inputs, rely- ing instead on other data.

Companies spend great amounts of time and effort trying to make the best project selection decisions possible. These decisions are typically made with regard for the overall objectives that the company’s senior management staff have developed and promoted based on their strategic plan. Such objectives can be quite complex and may reflect a number of external factors that can affect a firm’s operations. For example, suppose the new head of Sylvania’s Lighting Division mandated that the strategic objective of the organization was to be sales growth at all costs. Any new project opportunity would be evaluated against this key strategic imperative. Thus, a project offering the potential for opening new markets might be viewed more favorably than a competing project promising a higher potential rate of return.

The list of factors that can be considered when evaluating project alternatives is enormous. Table 3.1 provides only a partial list of the various elements that a company must address, orga- nized into the general categories of risk and commercial factors, internal operating issues, and other factors. Although such a list can be long, in reality the strategic direction emphasized by top management often highlights certain criteria over others. In fact, if we apply Pareto’s 80/20 principle, which states that a few issues (20%) are vital and many (80%) are trivial, it may be fairly argued that, for many projects, less than 20% of all possible decision criteria account for over 80% of the decision about whether to pursue the project.

This being said, we should reflect on two final points regarding the use of any decision- making approach to project selection. First, the most complete model in the world is still only a partial reflection of organizational reality. The potential list of inputs into any project selection decision is literally limitless—so much so, in fact, that we must recognize this truth before explor- ing project selection lest we erroneously assume that it is possible, given enough time and effort, to identify all relevant issues that play a role. Second, embedded in every decision model are both

80 Chapter 3 • Project Selection and Portfolio Management

table 3.1 issues in Project Screening and Selection

1. Risk—Factors that reflect elements of unpredictability to the firm, including: a. Technical risk—risks due to the development of new or untested technologies b. Financial risk—risks from the financial exposure caused by investing in the project c. Safety risk—risks to the well-being of users or developers of the project d. Quality risk—risks to the firm’s goodwill or reputation due to the quality of the completed project e. Legal exposure—potential for lawsuits or legal obligation

2. Commercial—Factors that reflect the market potential of the project, including: a. Expected return on investment b. Payback period c. Potential market share d. Long-term market dominance e. Initial cash outlay f. Ability to generate future business/new markets

3. Internal operating issues—Factors that have an impact on internal operations of the firm, including: a. Need to develop/train employees b. Change in workforce size or composition c. Change in physical environment d. Change in manufacturing or service operations resulting from the project

4. Additional factors, including: a. Patent protection b. Impact on company’s image c. Strategic fit

objective and subjective factors. We may form opinions based on objective data; we also may derive complex decision models from subjective inputs. Acknowledging that there exists a place for both subjective and objective inputs and decisions in any useful screening model is worthwhile.

3.2 aPProacheS to Project ScreenIng and SelectIon

A project screening model that generates useful information for project choices in a timely and useful fashion at an acceptable cost can serve as a valuable tool in helping an organization make optimal choices among numerous alternatives.6 With these criteria in mind, let’s consider some of the more common project selection techniques.

Method one: checklist Model

The simplest method of project screening and selection is developing a checklist, or a list of cri- teria that pertain to our choice of projects, and then applying them to different possible projects. Let’s say, for example, that in our company, the key selection criteria are cost and speed to market. Because of our strategic competitive model and the industry we are in, we favor low-cost projects that can be brought to the marketplace within one year. We would screen each possible project against these two criteria and select the project that best satisfies them. But depending on the type and size of our possible projects, we may have to consider literally dozens of relevant criteria. In deciding among several new product development opportunities, a firm must weigh a variety of issues, including the following:

• Cost of development: What is a reasonable cost estimate? • Potential return on investment: What kind of return can we expect? What is the likely pay-

back period? • Riskiness of the new venture: Does the project entail the need to create new-generation tech-

nology? How risky is the venture in terms of achieving our anticipated specifications? • Stability of the development process: Are both the parent organization and the project team

stable? Can we expect this project to face funding cuts or the loss of key personnel, including senior management sponsors?

• Governmental or stakeholder interference: Is the project subject to levels of governmental oversight that could potentially interfere with its development? Might other stakeholders

3.2 Approaches to Project Screening and Selection 81

oppose the project and attempt to block completion? For example, environmental groups, one of the “intervenor” stakeholders, have a long history of opposing natural resource devel- opment projects and may work in opposition to our project objectives.7

• Product durability and future market potential: Is this project a one-shot opportunity, or could it be the forerunner of future opportunities? A software development firm may, for example, develop an application for a client in hopes that successful performance on this project will lead to future business. On the other hand, the project may be simply a one-time opportunity with little potential for future work with the customer.

This is just a partial list of criteria that may be relevant when we are selecting among proj- ect alternatives. A checklist approach to the evaluation of project opportunities is a fairly simple device for recording opinions and encouraging discussion. Thus, checklists may be best used in a consensus-group setting, as a method for initiating conversation, stimulating discussion and the exchange of opinions, and highlighting the group’s priorities.

exaMPle 3.1 Checklist

Let’s assume that SAP Corporation, a leader in the business applications software industry, is inter- ested in developing a new application package for inventory management and shipping control. It is trying to decide which project to select from a set of four potential alternatives. Based on past commercial experiences, the company feels that the most important selection criteria for its choice are cost, profit potential, time to market, and development risks. Table 3.2 shows a simple checklist model with only four project choices and the four decision criteria. In addition to developing the decision criteria, we create evaluative descriptors that reflect how well the project alternatives correspond to our key selection criteria. We evaluate each criterion (which is rated high, medium, or low) in order to see which project accumulates the highest checks—and thus may be regarded as the optimal choice.


Based on this analysis, Project Gamma is the best alternative in terms of maximizing our key criteria—cost, profit potential, time to market, and development risks.

table 3.2 Simplified checklist Model for Project Selection

Performance on criteria

Project criteria High Medium low

Project Alpha Cost X

Profit potential X

Time to market X

Development risks X

Project Beta Cost X

Profit potential X

Time to market X

Development risks X

Project Gamma Cost X

Profit potential X

Time to market X

Development risks X

Project Delta Cost X

Profit potential X

Time to market X Development risks X

82 Chapter 3 • Project Selection and Portfolio Management

The flaws in a model such as that shown in Table 3.2 include the subjective nature of the high, medium, and low ratings. These terms are inexact and subject to misinterpretation or misunder- standing. Checklist screening models also fail to resolve trade-off issues. What if our criteria are differentially weighted—that is, what if some criteria are more important than others? How will rela- tive, or weighted, importance affect our final decision? Let’s say, for instance, that we regard time to market as our paramount criterion. Is Project Gamma, which is rated low on this criterion, still “better” than Project Beta or Delta, both of which are rated high on time to market though lower on other, less important criteria? Are we willing to make a trade-off, accepting low time to market in order to get the highest benefits in cost, profit potential, and development risks?

Because the simple checklist model does not deal satisfactorily with such questions, let’s turn next to a more complex screening model in which we distinguish more important from less impor- tant criteria by assigning each criterion a simple weight.

Method two: Simplified Scoring Models

In the simplified scoring model, each criterion is ranked according to its relative importance. Our choice of projects will thus reflect our desire to maximize the impact of certain criteria on our deci- sion. In order to score our simplified checklist, we assign a specific weight to each of our four criteria:

criterion importance Weight

Time to market 3

Profit potential 2

Development risks 2

Cost 1

Now let’s reconsider the decision that we made using the basic checklist approach illustrated in Table 3.2.

exaMPle 3.2 Scoring Models

SAP Corporation is attempting to determine the optimal project to fund using the criterion weight- ing values we developed above. As you can see in Table 3.3, although adding a scoring component to our simple checklist complicates our decision, it also gives us a more precise screening model— one that more closely reflects our desire to emphasize certain criteria over others.


In Table 3.3, the numbers in the column labeled Importance Weight specify the numerical values that we have assigned to each criterion: Time to market always receives a value of 3, profit potential a value of 2, development risk a value of 2, and cost a value of 1. We then assign relative values to each of our four dimensions.

The numbers in the column labeled Score replace the Xs of Table 3.2 with their assigned score values:

High = 3 Medium = 2 Low = 1

In Project Alpha, for example, the High rating given Cost becomes a 3 in Table 3.3 because High is here valued at 3. Likewise, the Medium rating given Time to market in Table 3.2 becomes a 2. But notice what happens when we calculate the numbers in the column labeled Weighted Score. When we multiply the numerical value of Cost (1) by its rating of High (3), we get a Weighted Score of 3. But when we multiply the numerical value of Time to market (3) by its rating of Medium (2), we get a Weighted Score of 6. Once we add the numbers in the Weighted Score column for each project in Table 3.3 and examine the totals, Project Beta (with a total score of 19) is the best alternative, compared to the other options: Project Alpha (with a total score of 13), Project Gamma (with a total score of 18), and Project Delta (with a total score of 16).

3.2 Approaches to Project Screening and Selection 83

table 3.3 Simple Scoring Model

(A) (B) (A) : (B)

Project criteria importance

Weight Score Weighted


Project Alpha

Cost 1 3 3

Profit potential 2 1 2

Development risk 2 1 2

Time to market 3 2 6

total Score 13

Project Beta

Cost 1 2 2

Profit potential 2 2 4

Development risk 2 2 4

Time to market 3 3 9

total Score 19

Project Gamma

Cost 1 3 3

Profit potential 2 3 6

Development risk 2 3 6

Time to market 3 1 3

total Score 18

Project Delta

Cost 1 1 1

Profit potential 2 1 2

Development risk 2 2 4

Time to market 3 3 9

total Score 16

Thus, the simple scoring model consists of the following steps:

• Assign importance weights to each criterion: The first step is to develop logic for differenti- ating among various levels of importance and to devise a system for assigning appropriate weights to each criterion. Relying on collective group judgment may help to validate the rea- sons for determining importance levels. The team may also designate some criteria as “must” items. Safety concerns, for example, may be stipulated as nonnegotiable. In other words, all projects must achieve an acceptable safety level or they will not be considered further.

• Assign score values to each criterion in terms of its rating (High = 3, Medium = 2, Low = 1): The logic of assigning score values is often an issue of scoring sensitivity—of making differences in scores distinct. Some teams, for example, prefer to widen the range of possible values—say, by using a 1-to-7 scale instead of a 1-to-3 scale—in order to ensure a clearer distinc- tion among scores and, therefore, among project choices. Such decisions will vary according to the number of criteria being applied and, perhaps, the team members’ experience with the accuracy of outcomes produced by a given approach to screening and selection.

• Multiply importance weights by scores to arrive at a weighted score for each criterion: The weighted score reflects both the value that the team assigns to each criterion and the ratings that the team gives each criterion for the project.

• Add the weighted scores to arrive at an overall project score: The final score for each project represents the sum of all its weighted criteria.

84 Chapter 3 • Project Selection and Portfolio Management

The pharmaceutical company Hoechst Marion Roussel uses a scoring model for selecting projects that identifies not only five main criteria—reward, business strategy fit, strategic leverage, probability of commercial success, and probability of technical success—but also a number of more specific subcriteria. Each of these 19 subcriteria is scored on a scale of 1 to 10. The score for each criterion is then calculated by averaging the scores for each criterion. The final project score is deter- mined by adding the average score of each of the five subcategories. Hoechst has had great success with this scoring model, both in setting project priorities and in making go/no-go decisions.8

The simple scoring model has some useful advantages as a project selection device. First, it is easy to use in tying critical strategic goals for the company to various project alternatives. In the case of the pharmaceutical company Hoechst, the company has assigned several categories to strategic goals for its project options, including business strategy fit and strategic leverage. These strategic goals become a critical hurdle for all new project alternatives. Second, the simple scoring model is easy to comprehend and use. With a checklist of key criteria, evaluation options (high, medium, and low), and attendant scores, top managers can quickly grasp how to employ this technique.

limitations of Scoring Models

The simple scoring model illustrated here is an abbreviated and unsophisticated version of the weighted-scoring approach. In general, scoring models try to impose some structure on the decision- making process while, at the same time, combining multiple criteria.

Most scoring models, however, share some important limitations. A scale from 1 to 3 may be intuitively appealing and easy to apply and understand, but it is not very accurate. From the perspective of mathematical scaling, it is simply wrong to treat evaluations on such a scale as real numbers that can be multiplied and summed. If 3 means High and 2 means Medium, we know that 3 is better than 2, but we do not know by how much. Furthermore, we cannot assume that the difference between 3 and 2 is the same as the difference between 2 and 1. Thus, in Table 3.3, if the score for Project Alpha is 13 and the score for Project Beta is 19, may we assume that Beta is 46% better than Alpha? Unfortunately, no. Critics of scoring models argue that their ease of use may blind novice users to the false assumptions that sometimes underlie them.

From a managerial perspective, another drawback of scoring models is the fact that they depend on the relevance of the selected criteria and the accuracy of the weight given them. In other words, they do not ensure that there is a reasonable link between the selected and weighted crite- ria and the business objectives that prompted the project in the first place.

For example As a means of selecting projects, the Information Systems steering committee of a large bank has adopted three criteria: contribution to quality, financial performance, and service. The bank’s strategy is focused on customer retention, but the criteria selected by the committee do not reflect this fact. As a result, a project aimed at improving service to potential new markets might score high on service even though it would not serve existing customers (the people whose business the bank wants to retain). Note, too, that the criteria of quality and service may overlap, leading managers to double-count and overestimate the value of some factors.9 Thus, the bank has employed a project selection approach that neither achieves its desired ends nor matches its overall strategic goals.

Method three: the analytical hierarchy Process

The Analytical hierarchy Process (AhP) was developed by Dr. Thomas Saaty10 to address many of the technical and managerial problems frequently associated with decision making through scoring models. An increasingly popular method for effective project selection, the AHP is a four-step process.

StructurIng the hIerarchy of crIterIa The first step consists of constructing a hierarchy of criteria and subcriteria. Let’s assume, for example, that a firm’s IT steering committee has selected three criteria for evaluating project alternatives: (1) financial benefits, (2) contribution to strategy, and (3) contribution to IT infrastructure. The financial benefits criterion, which focuses on the tangible benefits of the project, is further subdivided into long-term and short-term benefits. Contribution to strategy, an intangible factor, is subdivided into three subcriteria: (a) increasing market share for product X, (b) retaining existing customers for product Y, and (c) improving cost management.

3.2 Approaches to Project Screening and Selection 85

Table 3.4 is a representational breakdown of all these criteria. Note that subdividing rele- vant criteria into a meaningful hierarchy gives managers a rational method for sorting among and ordering priorities. Higher-order challenges, such as contribution to strategy, can be broken down into discrete sets of supporting requirements, including market share, customer retention, and cost management, thus building a hierarchy of alternatives that simplifies matters. Because the hierar- chy can reflect the structure of organizational strategy and critical success factors, it also provides a way to select and justify projects according to their consistency with business objectives.11 This illustrates how we can use meaningful strategic issues and critical factors to establish logic for both the types of selection criteria and their relative weighting.

Recently, a large U.S. company used the AHP to rank more than a hundred project proposals worth millions of dollars. Because the first step in using the AHP is to establish clear criteria for selection, 10 managers from assorted disciplines, including finance, market- ing, management information systems, and operations, spent a full day establishing the hier- archy of criteria. Their challenge was to determine the key success criteria that should be used to guide project selection, particularly as these diverse criteria related to each other (relative weighting). They found that, in addition to clearly defining and developing the criteria for evaluating projects, the process also produced a more coherent and unified vision of organiza- tional strategy.

allocatIng WeIghtS to crIterIa The second step in applying AHP consists of allocating weights to previously developed criteria and, where necessary, splitting overall criterion weight among subcriteria. Mian and Dai12 and others have recommended the so-called pairwise compari- son approach to weighting, in which every criterion is compared with every other criterion. This procedure, argue the researchers, permits more accurate weighting because it allows managers to focus on a series of relatively simple exchanges—namely, two criteria at a time.

The simplified hierarchy in Figure 3.1 shows the breakdown of criterion weights across the same three major criteria that we used in Table 3.4. As Figure 3.1 shows, Finance (that is, financial benefits) received a weighting value of 52%, which was split between Short-term benefits (30%) and Long-term benefits (70%). This configuration means that long-term financial benefits receives an over- all weighting of (0.52) * (0.7) = 36.4%.

table 3.4 Hierarchy of Selection criteria choices

first level Second level

1. Financial benefits 1A: Short-term 1B: Long-term

2. Contribution to strategy 2A: Increasing market share for product X; 2B: Retaining existing customers for product Y; 2C: Improving cost management

3. Contribution to IT infrastructure

Rank Information Systems Project Proposals

Goal (1.000)

Information Technology





Very Good




Market Share


Cost Mgmt.





fIgure 3.1 Sample AHP with rankings for Salient Selection criteria

Source: J. K. Pinto and I. Millet. (1999). Successful Information System Implementation: The Human Side, 2nd ed., figure on page 76. Newtown Square, PA: Project Management Institute. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

86 Chapter 3 • Project Selection and Portfolio Management

The hierarchical allocation of criteria and splitting of weights resolves the problem of dou- ble counting in scoring models. In those models, criteria such as service, quality, and customer satisfaction may be either separate or overlapping factors, depending on the objectives of the organization. As a result, too little or too much weight may be assigned to a given criterion. With AHP, however, these factors are grouped as subcriteria and share the weight of a common higher-level criterion.

aSSIgnIng nuMerIcal ValueS to eValuatIon dIMenSIonS For the third step, once the hierar- chy is established, we can use the pairwise comparison process to assign numerical values to the dimensions of our evaluation scale. Figure 3.2 is an evaluation scale with five dimensions: Poor, Fair, Good, Very Good, and Excellent. In this figure, for purposes of illustration, we have assigned the values of 0.0, 0.10, 0.30, 0.60, and 1.00, respectively, to these dimensions. Naturally, we can change these values as necessary. For example, if a company wants to indicate a greater discrep- ancy between Poor and Fair, managers may increase the range between these two dimensions. By adjusting values to suit specific purposes, managers avoid the fallacy of assuming that the differences between numbers on a scale of, say, 1 to 5 are equal—that is, assuming that the differ- ence between 4 and 5 is the same as the difference between 3 and 4. With the AHP approach, the “best” outcome receives a perfect score of 1.00 and all other values represent some proportion relative to that score.

When necessary, project managers are encouraged to apply different scales for each crite- rion. Note, for example, that Figure 3.2 uses scale points ranging from Poor to Excellent. Suppose, however, that we were interviewing a candidate for our project team and one of the criterion items was “Education level.” Clearly, using a scale ranging from Poor to Excellent makes no sense, so we would adjust the scales to make them meaningful; for example, using levels such as “High School,” “Some College,” “College Graduate,” and so forth. Allocating weights across dimensions gives us a firmer understanding of both our goals and the methods by which we are comparing opportunities to achieve them.

eValuatIng Project ProPoSalS In the final step, we multiply the numeric evaluation of the project by the weights assigned to the evaluation criteria and then add the results for all crite- ria. Figure 3.3 shows how five potential projects might be evaluated by an AHP program offered by Expert Choice, a maker of decision software.13 Here’s how to read the key features of the spreadsheet:

• The second row specifies the value assigned to each of five possible ratings (from Poor = 1 = .000 to Excellent = 5 = 1.000).

• The fourth row specifies the five decision criteria and their relative weights (Finance/Short- Term = .1560, Strategy/Cost Management = .0816, and so forth). (Note that three criteria have been broken down into six subcriteria.)

• The second column lists the five projects (Perfect Project, Aligned, etc.). • The third column labeled “Total” gives a value for each alternative. This number is found by

multiplying each evaluation by the appropriate criterion weight and summing the results across all criteria evaluations.


Poor 0.00000 0.000













Very Good


Priority Bar Graph

fIgure 3.2 Assigning Numerical Values to labels

Source: J. K. Pinto and I. Millet. (1999). Successful Information System Implementation: The Human Side, 2nd ed., figure on page 77. Newtown Square, PA: Project Management Institute. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

3.2 Approaches to Project Screening and Selection 87


Poor 1 (.000)

Fair 2 (.100)


1 Perfect Project 1.000 Excellent Excellent Excellent Excellent Excellent Excellent








Very Good Very Good Very Good Very Good Very Good Very Good

Very GoodFairPoor














Not Aligned

All Very Good








8 9




Short-Term Long-Term


Market Share Retention Cost Management



Good 3 (.300)

Very Good 4 (.600)

Excellent 5 (1.000)


fIgure 3.3 the Project rating Spreadsheet

Source: J. K. Pinto and I. Millet. (1999). Successful Information System Implementation: The Human Side, 2nd ed., figure on page 78. Newtown Square, PA: Project Management Institute. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

To illustrate how the calculations are derived, let us take the Aligned project as an example. Remember that each rating (Excellent, Very Good, Good, etc.) carries with it a numerical score Figure 3.2. These scores, when multiplied by the evaluation criteria and then added together, yield:

(.1560)(.3) + (.3640)(1.0) + (.1020)(.3) + (.1564)(1.0) + (.0816)(.3) + (.1400)(1.0) = .762

The Perfect Project, as another example, was rated Excellent on all six dimensions and thus received a total score of 1.000. Also, compare the evaluations of the Aligned and Not Aligned project choices. Although both projects received an equal number of Excellent and Good rankings, the Aligned proj- ect was clearly preferable because it was rated higher on criteria viewed as more important and thus more heavily weighted.

Unlike the results of typical scoring models, the AHP scores are significant. The Aligned proj- ect, for example, which scored 0.762, is almost three times better than the Mixed project, with its score of 0.284. This feature—the ability to quantify superior project alternatives—allows project managers to use AHP scores as input to other calculations. We might, for example, sort projects by the ratios of AHP scores to total their development costs. Let’s say that based on this ratio, we find that the Not Aligned project is much cheaper to initiate than the Aligned project. This finding may suggest that from a cost/benefit perspective, the Not Aligned project offers a better alternative than the Aligned project.

The AHP methodology can dramatically improve the process of developing project propos- als. In firms that have incorporated AHP analysis, new project proposals must contain, as part of their core information, a sophisticated AHP breakdown listing the proposed project, alternatives, and projected outcomes. The Analytical Hierarchy Process offers a true advantage over traditional scoring models, primarily because it reduces many of the technical and managerial problems that plague such approaches.

The AHP does have some limitations, however. First, current research suggests that the model does not adequately account for “negative utility”; that is, the fact that certain choice options do not contribute positively to the decision goals but actually lead to negative results. For example, suppose that your company identified a strong project option that carried a prohibitively expensive price tag. As a result, selecting this project is really not an option because it would be just too high an investment. However, using the AHP, you would first need to weigh all positive elements, develop your screening score, and then compare this score against negative aspects, such as cost. The result can lead to bias in the project scoring calculations.14 A second limitation is that the AHP requires that all criteria be fully exposed and accounted for at the beginning of the selection process. Powerful members of the orga- nization with political agendas or pet projects they wish to pursue may resist such an open selection process.

88 Chapter 3 • Project Selection and Portfolio Management

Method four: Profile Models

Profile models allow managers to plot risk/return options for various alternatives and then select the project that maximizes return while staying within a certain range of minimum acceptable risk. “Risk,” of course, is a subjective assessment: It may be difficult to reach overall agreement on the level of risk associated with a given project. Nevertheless, the profile model offers another way of evaluating, screening, and comparing projects.15

Let’s return to our example of project screening at SAP Corporation. Suppose that instead of the four project alternatives for the new software project we discussed earlier, the firm had identi- fied six candidates for development. For simplicity’s sake, managers chose to focus on the two criteria of risk and reward.

In Figure 3.4, the six project alternatives are plotted on a graph showing perceived Risk on the y-axis and potential Return on the x-axis. Because of the cost of capital to the firm, we will specify some minimum desired rate of return. All projects will be assigned some risk factor value and be plotted relative to the maximum risk that the firm is willing to assume. Figure 3.4, therefore, graphi- cally represents each of our six alternatives on a profile model. (Risk values have been created here simply for illustrative purposes.) In our example, SAP can employ a variety of measures to assess the likely return offered by this project, including discounted cash flow analysis and internal rate of return expectations. Likewise, it is increasingly common for firms to quantify their risk assessment of various projects, enabling us to plot them along the y-axis. The key lies in employing identical evaluation criteria and quantification approaches across all projects to be profiled on the graph. Clearly, when project risks are unique or we have no way of comparing the relative risks from proj- ect to project, it is impossible to accurately plot project alternatives.

In Figure 3.4, we see that Project X2 and Project X3 have similar expected rates of return. Project X3, however, represents a better selection choice. Why? Because SAP can achieve the same rate of return with Project X3 as it can with Project X2 but with less risk. Likewise, Project X5 is a superior choice to X4: Although they have similar risk levels, X5 offers greater return as an investment. Finally, while Project X6 offers the most potential return, it does so at the highest level of risk.

The profile model makes use of a concept most widely associated with financial management and investment analysis—the efficient frontier. In project management, the efficient frontier is the set of project portfolio options that offers either a maximum return for every given level of risk or the minimum risk for every level of return.16 When we look at the profile model in Figure 3.4, we note that certain options (X1, X3, X5, X6) lie along an imaginary line balancing optimal risk and return combinations. Others (X2 and X4), however, are less desirable alternatives and would therefore be considered inferior choices. The efficient frontier serves as a decision-making guide by establishing the threshold level of risk/return options that all future project choices must be evaluated against.

R is



Maximum Desired Risk

Minimum Desired Return



X4 X5



Efficient Frontier

fIgure 3.4 Profile Model

3.2 Approaches to Project Screening and Selection 89








8%6% 10% 12% 16% 20% 24% 28% 32%


Maximum Allowable Risk

Efficient Frontier



Minimum Desired Return





fIgure 3.5 efficient frontier for our firm

One advantage of the profile model is that it offers another method by which to compare proj- ect alternatives, this time in terms of the risk/return trade-off. Sometimes it is difficult to evaluate and compare projects on the basis of scoring models or other qualitative approaches. The profile model, however, gives managers a chance to map out potential returns while considering the risk that accompanies each choice. Thus, profile models give us a method for eliminating alternatives that either carry too much risk or promise too little return.

On the other hand, profile models also have disadvantages:

1. They limit decision criteria to just two—risk and return. Although an array of issues, includ- ing safety, quality, and reliability, can come under the heading of “risk,” the approach still necessarily limits the decision maker to a small set of criteria.

2. In order to be evaluated in terms of an efficient frontier, some value must be attached to risk. Expected return is a measure that is naturally given to numerical estimate. But because risk may not be readily quantified, it may be misleading to designate “risk” artificially as a value for comparison among project choices.

exaMPle 3.3 Profile Model

Let’s consider a simple example. Suppose that our company has identified two new project alter- natives and we wish to use risk/return analysis to determine which of the two projects would fit best with our current project portfolio. We assess return in terms of the profit margin we expect to achieve on the projects. Risk is evaluated at our company in terms of four elements: (1) technical risk—the technical challenge of the project, (2) capital risk—the amount invested in the project, (3) safety risk—the risk of accidents or employee safety, and (4) goodwill risk—the risk of losing cus- tomers or diminishing our company’s image. The magnitude of each of these types of risk is deter- mined by applying a “low, medium, high” risk scale where 1 = low, 2 = medium, and 3 = high.

After conducting a review of the likely profitability for both of the projects and evaluating their riskiness, we conclude the following:

risk return Potential

Project Saturn 10 23%

Project Mercury 6 16%

Figure 3.5 shows our firm’s efficient frontier for the current portfolio of projects. How would we evaluate the attractiveness of either Project Saturn or Project Mercury?

90 Chapter 3 • Project Selection and Portfolio Management


When we consider the two choices, Projects Saturn and Mercury, in terms of their projected risk and return, we can chart them on our profile model relative to other projects that we are undertak- ing. Figure 3.5 illustrates the placement of the two new project options. Note that Project Saturn, although within our maximum risk limit, does not perform as well as the other projects in our cur- rent portfolio (it has a higher risk rating for its projected return than other comparable projects). On the other hand, Project Mercury offers us a 16% rate of return for a lower level of risk than the current efficient frontier, suggesting that this project is an attractive option and a better alternative than Project Saturn.

3.3 fInancIal ModelS

Another important series of models rely on financial analysis to make project selection decisions. In this section, we will examine three commonly used financial models: discounted cash flow analy- sis, net present value, and internal rate of return.

Financial models are all predicated on the time value of money principle. The time value of money suggests that money earned today is worth more than money we expect to earn in the future. In other words, $100 that I receive four years from now is worth significantly less to me than if I were to receive that money today. In the simplest example, we can see that putting $100 in a bank account at 3% interest will grow the money at a compounded rate each year. Hence, at the end of year 1, the initial investment will be worth $103. After two years, it will have grown to $106.09, and so on. The principle also works in reverse: To calculate the present value of $100 that I expect to have in the bank in four years’ time, I must first discount the amount by the same interest rate. Hence, assuming an inter- est rate of 3%, I need only invest $88.85 today to yield $100 in four years.

We expect future money to be worth less for two reasons: (1) the impact of inflation, and (2) the inability to invest the money. Inflation, as we know, causes prices to rise and hence erodes con- sumers’ spending power. In 1900, for example, the average house may have cost a few thousand dollars to build. Today housing costs have soared. As a result, if I am to receive $100 in four years, its value will have decreased due to the negative effects of inflation. Further, not having that $100 today means that I cannot invest it and earn a return on my money for the next four years. Money that we cannot invest is money that earns no interest. In real terms, therefore, the present value of money must be discounted by some factor the farther out into the future I expect to receive it. When deciding among nearly identical project alternatives, if Project A will earn our firm $50,000 in two years and Project B will earn our company $50,000 in four years, Project A is the best choice because we will receive the money sooner.

Payback Period

The project payback period is the estimated amount of time that will be necessary to recoup the investment in a project, that is, how long will it take for the project to pay back its initial investment and begin to generate positive cash flow for the company. In determining the pay- back period for a project, we employ a discounted cash flow analysis, based on the principle of the time value of money. The goal of the discounted cash flow (dcf) analysis is to estimate cash outlays and expected cash inflows resulting from investment in a project. All potential costs of development (most of which are contained in the project budget) are assessed and projected prior to the decision to initiate the project. They are then compared with all expected sources of revenue from the project. For example, if the project is a new chemical plant, pro- jected revenue streams will be based on expected capacity, production levels, sales volume, and so forth.

We then apply to this calculation a discount rate based on the firm’s cost of capital. The value of that rate is weighted across each source of capital to which the firm has access (typically, debt and equity markets). In this way we weight the cost of capital, which can be calculated as follows:

Kfirm = (wd)(kd)(1 - t) + (we)(ke)

3.3 Financial Models 91

The weighted cost of capital is the percentage of capital derived from either debt (wd) or equity (we) multiplied by the percentage costs of debt and equity (kd and ke, respectively). (The value t refers to the company’s marginal tax rate: Because interest payments are tax deductible, we calculate the cost of debt after taxes.)

There is a standard formula for payback calculations:

Payback period = investment/annual cash savings

The reciprocal of this formula can be used to calculate the average rate of return for the project. However, note that the above formula only works in simple circumstances when cash flows (or annual cash savings) are the same for each year. So, for example, if we invested $150,000 and would receive $30,000 a year in annual savings, the payback period is straightforward:

Payback period = +150,000/+30,000 = 5 years

On the other hand, when projected cash flows from annual savings are not equal, you must determine at what point the cumulative cash flow becomes positive. Thus:

Cumulative cashflow(CF) = (Initial investment) + CF(year 1) + CF(year 2) + p

Once cost of capital has been calculated, we can set up a table projecting costs and revenue streams that are discounted at the calculated rate. The key is to determine how long it will take the firm to reach the breakeven point on a new project. Breakeven point represents the amount of time neces- sary to recover the initial investment of capital in the project. Shorter paybacks are more desirable than longer paybacks, primarily because the farther we have to project payback into the future, the greater the potential for additional risk.

exaMPle 3.4 Payback Period

Our company wants to determine which of two project alternatives is the more attractive invest- ment opportunity by using a payback period approach. We have calculated the initial investment cost of the two projects and the expected revenues they should generate for us (see Table 3.5). Which project should we invest in?


For our example, the payback for the two projects can be calculated as in Table 3.6. These results suggest that Project A is a superior choice over Project B, based on a shorter projected payback pe- riod (2.857 years versus 4.028 years) and a higher rate of return (35% versus 24.8%).

table 3.5 initial outlay and Projected revenues for two Project options

Project A Project B

revenues outlays revenues outlays

Year 0 $500,000 $500,000 Year 1 $ 50,000 $ 75,000 Year 2 150,000 100,000 Year 3 350,000 150,000 Year 4 600,000 150,000 Year 5 500,000 900,000

92 Chapter 3 • Project Selection and Portfolio Management

table 3.6 comparison of Payback for Projects A and B

Project A Year cash flow cum. cash flow 0 ($500,000) ($ 500,000)

1 50,000 (450,000)

2 150,000 (300,000)

3 350,000 50,000

4 600,000 650,000

5 500,000 1,150,000

Payback = 2.857 years

Rate of Return = 35%

Project B Year cash flow cum. cash flow 0 ($500,000) ($ 500,000)

1 75,000 (425,000)

2 100,000 (325,000)

3 150,000 (175,000)

4 150,000 (25,000)

5 900,000 875,000

Payback = 4.028 years

Rate of Return = 24.8%

net Present Value

The most popular financial decision-making approach in project selection, the net present value (nPv) method, projects the change in the firm’s value if a project is undertaken. Thus a positive NPV indicates that the firm will make money—and its value will rise—as a result of the project. Net present value employs discounted cash flow analysis, discounting future streams of income to estimate the present value of money.

The simplified formula for NPV is as follows:

NPV(project) = I0 + a t

n = 1 Ft/(1 + r + pt)t


Ft = net cash flow for period t r = required rate of return I = initial cash investment (cash outlay at time 0) pt = inflation rate during period

The optimal procedure for developing an NPV calculation consists of several steps, including the construction of a table listing the outflows, inflows, discount rate, and discounted cash flows across the relevant time periods. We construct such a table in Example 3.5 (see Table 3.7).

exaMPle 3.5 Net Present Value

Assume that you are considering whether or not to invest in a project that will cost $100,000 in ini- tial investment. Your company requires a rate of return of 10%, and you expect inflation to remain relatively constant at 4%. You anticipate a useful life of four years for the project and have projected future cash flows as follows:

Year 1: $20,000 Year 2: $50,000 Year 3: $50,000 Year 4: $25,000

3.3 Financial Models 93


We know the formula for determining NPV:

NPV = I0 + a t

n = 1 Ft/(1 + r + p)t

We can now construct a simple table to keep a running score on discounted cash flows (both in- flows and outflows) to see if the project is worth its initial investment. We already know that we will need the following categories: Year, Inflows, Outflows, and NPV. We will also need two more categories:

Net flows: the difference between inflows and outflows Discount factor: the reciprocal of the discount rate (1/(1 + r + p)t)

In Table 3.7, if we fill in the Discount Factor column assuming that r = 10% and p = 4%, we can begin work on the NPV. Note that Year 0 means the present time, and Year 1 the first year of operation.

How did we arrive at the Discount Factor for Year 3? Using the formula we set above, we cal- culated the appropriate data:

Discount factor = (1/(1 + .10 + .04)3) = .6749

Now we can supply the data for the Inflows, Outflows, and Net Flow columns. Finally, we complete the table by multiplying the Net Flow amount by the Discount Factor. The

results give us the data for the NPV column of our table. The sum of the discounted cash flows (their net present value) shown in Table 3.8 gives us the NPV of the project. The total is a positive number, indicating that the investment is worthwhile and should be pursued.

table 3.7 running Score on Discounted cash flows

Year inflows outflows Net flow Discount factor NPV

0 $100,000 $(100,000) 1.0000

1 $20,000 20,000 0.8772

2 50,000 50,000 0.7695

3 50,000 50,000 0.6749

4 25,000 25,000 0.5921

table 3.8 Discounted cash flows and NPV (i)

Year inflows outflows Net flow Discount factor NPV

0 $100,000 $(100,000) 1.0000 $(100,000)

1 $20,000 20,000 0.8772 17,544

2 50,000 50,000 0.7695 38,475

3 50,000 50,000 0.6749 33,745

4 25,000 25,000 0.5921 14,803

Total $ 4,567

Net present value is one of the most common project selection methods in use today. Its principal advantage is that it allows firms to link project alternatives to financial performance, better ensuring that the projects a company chooses to invest its resources in are likely to generate profit. Among its disadvantages is the difficulty in using NPV to make accurate long- term predictions. For example, suppose that we were considering investing in a project with

94 Chapter 3 • Project Selection and Portfolio Management

an expectation that it would continue to generate returns during the next 10 years. In choosing whether or not to invest in the project today, we must make some assumptions about future interest rates, inflation, and our required rate of return (rrr) for the next 10 years. In uncer- tain financial or economic times, it can be risky to make long-term investment decisions when discount rates may fluctuate.

discounted Payback

Now that we have considered the time value of money, as shown in the NPV method, we can apply this logic to the simple payback model to create a screening and selection model with a bit more power. Remember that with NPV we use discounted cash flow as our means to decide whether or not to invest in a project opportunity. Now, let’s apply that same principle to the discounted pay- back method. With this method, the time period in which we are interested is the length of time until the sum of the discounted cash flows is equal to the initial investment.

A simple example will illustrate the difference between straight payback and discounted payback methods. Suppose we require a 12.5% return on new investments, and we have a proj- ect opportunity that will cost an initial investment of $30,000 with a promised return per year of $10,000. Under the simple payback model, the initial investment should be paid off in only three years. However, as Table 3.9 demonstrates, when we discount our cash flows at 12.5% and start adding them, it actually takes four years to pay back the initial project investment.

The advantage of the discounted payback method is that it allows us to make a more “intel- ligent” determination of the length of time needed to satisfy the initial project investment. That is, while simple payback is useful for accounting purposes, discounted payback is actually more rep- resentative of the financial realities that all organizations must consider when pursuing projects. The effects of inflation and future investment opportunities matter with individual investment decisions; hence, these factors should also matter when evaluating project opportunities.

Internal rate of return

internal rate of return (irr) is an alternative method for evaluating the expected outlays and income associated with a new project investment opportunity. The IRR method asks the simple question: What rate of return will this project earn? Under this model, the project must meet some required “hurdle” rate applied to all projects under consideration. Without detailing the math- ematics of the process, we will say that IRR is the discount rate that equates the present values of a project’s revenue and expense streams. If a project has a life of time t, the IRR is defined as:

IO = a t

n = 1


(1 + IRR)t


ACFt = annual after-tax cash flow for time period t IO = initial cash outlay n = project’s expected life IRR = project’s internal rate of return

table 3.9 Discounted Payback Method

Project cash flow* Year Discounted Undiscounted

1 $8,900 $10,000 2 7,900 10,000 3 7,000 10,000 4 6,200 10,000 5 5,500 10,000

Payback Period 4 Years 3 Years

*Cash flows rounded to the nearest $100.

3.3 Financial Models 95

The IRR is found through a straightforward process, although it requires tables representing present value of an annuity in order to determine the project’s rate of return. Alternatively, many pocket calculators can determine IRR quickly. Without tables or access to a calculator, it is neces- sary to employ an iterative process to identify the approximate IRR for the project.

exaMPle 3.6 Internal Rate of Return

Let’s take a simple example. Suppose that a project required an initial cash investment of $5,000 and was expected to generate inflows of $2,500, $2,000, and $2,000 for the next three years. Further, assume that our company’s required rate of return for new projects is 10%. The question is: Is this project worth funding?


Answering this question requires four steps:

1. Pick an arbitrary discount rate and use it to determine the net present value of the stream of cash inflows.

2. Compare the present value of the inflows with the initial investment; if they are equal, you have found the IRR.

3. If the present value is larger (or less than) than the initial investment, select a higher (or lower) discount rate for the computation.

4. Determine the present value of the inflows and compare it with the initial investment. Con- tinue to repeat steps 2–4 until you have determined the IRR.

Using our example, we know:

Cash investment = $5,000 Year 1 inflow = $2,500 Year 2 inflow = $2,000 Year 3 inflow = $2,000 Required rate of return = 10%

step one: try 12%.

Discount factor

Year inflows at 12% NPV

1 $2,500 .893 $2,233 2 2,000 .797 1,594 3 2,000 .712 1,424

Present value of inflows 5,251 Cash investment –5,000 Difference $ 251

decision: Present value difference at 12% is 250.50, which is too high. Try a higher discount rate.

step two: try 15%.

Discount factor Year inflows at 15% NPV

1 $2,500 .870 $2,175 2 2,000 .756 1,512 3 2,000 .658 1,316

Present value of inflows 5,003 Cash investment 5,000 Difference $ 3

decision: Present value difference at 15% is $3, which suggests that 15% is a close approximation of the IRR.

96 Chapter 3 • Project Selection and Portfolio Management

If the IRR is greater than or equal to the company’s required rate of return, the project is worth funding. In Example 3.6, we found that the IRR is 15% for the project, making it higher than the hurdle rate of 10% and a good candidate for investment. The advantage of using IRR analysis lies in its ability to compare alternative projects from the perspective of expected return on investment (ROI). Projects having higher IRR are generally superior to those having lower IRR.

The IRR method, however, does have some disadvantages. First, it is not the rate of return for a project. In fact, the IRR equals the project’s rate of return only when project-generated cash inflows can be reinvested in new projects at similar rates of return. If the firm can reinvest revenues only on lower-return projects, the “real” return on the project is something less than the calculated IRR. Several other problems with the IRR method make NPV a more robust determinant of project viability:17

• IRR and NPV calculations typically agree (that is, make the same investment recommenda- tions) only when projects are independent of each other. If projects are not mutually exclu- sive, IRR and NPV may rank them differently. The reason is that NPV employs a weighted average cost of capital discount rate that reflects potential reinvestment while IRR does not. Because of this distinction, NPV is generally preferred as a more realistic measure of invest- ment opportunity.

• If cash flows are not normal, IRR may arrive at multiple solutions. For example, if net cash outflows follow a period of net cash inflows, IRR may give conflicting results. If, following the completion of plant construction, it is necessary to invest in land reclamation or other incidental but significant expenses, an IRR calculation may result in multiple return rates, only one of which is correct.

choosing a Project Selection approach

What can we conclude from our discussion of project selection methods? First and foremost, we have learned to focus on the method that we use in making selection decisions. Have we been consistent and objective in considering our alternatives? The author has worked in a consulting and training capacity with a number of firms that have experienced recurrent problems in their project selections (they kept picking losers). Why? One reason was their failure to even attempt objectivity in their selection methods. Proposed projects, often “sacred cows” or the pet ideas of senior managers, were pushed to the head of the line or, worse, financially “tweaked” until they yielded satisfactory conclusions. Team members knew in advance that such projects would fail because the projects had been massaged to the point at which they seemingly optimized the selection criteria. The key to project selection lies in being objective about the process. If you operate according to the “GIGO” principle—garbage in/garbage out—you’ll soon be up to your knees in garbage.

A second conclusion we can draw is that although a wide variety of selection methods exist, certain ones may be more appropriate for specific companies and project circumstances. Some projects require sophisticated financial evidence of their viability. Others may only need  to demonstrate no more than an acceptable profile when compared to other options. In other words, any of the previously discussed selection methods may be appropriate under certain situations. Some experts, for example, favor weighted scoring models on the grounds that they offer a more accurate reflection of a firm’s strategic goals without sacrificing long- term effectiveness for short-term financial gains.18 They argue that such important, nonfi- nancial criteria should not be excluded from the decision-making process. In fact, research suggests that although very popular, financial selection models, when used exclusively, do not yield optimal portfolios.19 On the other hand, when they are combined with scoring models into a more comprehensive selection procedure, they can be highly effective. It is also criti- cal to match the types of projects we are selecting from to the appropriate screening method. Is it possible to estimate future return on investment? Potential risk? These issues should be carefully thought through when developing a suitable screening model. Perhaps the key lies

3.3 Financial Models 97

in choosing a selection algorithm broad enough to encompass both financial and nonfinan- cial considerations. Regardless of the approach that a company selects, we can be sure of one thing: Making good project choices is a crucial step in ensuring good project management downstream.

Project Profile

Project Selection and Screening at Ge: the tollgate Process

General Electric has developed a highly sophisticated approach to project screening and selection that the company calls the Tollgate Process. As you can see from Figure 3.6, Tollgate involves a series of seven formal procedural check- points (labeled 100 to 700) established along the project development time line. Therefore, Tollgate is more than just a project selection methodology; it involves controlling the selection and development of the project as it moves through its life cycle. Each stage in this control process is carefully monitored.

Each of the seven Tollgate stages can be broken down into a so-called process map that guides manag- ers and teams in addressing specific necessary elements in the completion of a stage. These elements are the substeps that guide project screening in order to ensure that all projects conform to the same set of internal GE standards.

Figure 3.7 lays out the process flow map that is used to evaluate the progress each project makes at the vari- ous stages to final completion. Note that teams must complete all action substeps at each Tollgate stage. Once they have completed a given stage, a cross-functional management review team provides oversight at a review conference. Approval at this stage permits the team to proceed to the next stage. Rejection means that the team must back up and deal with any issues that the review team feels it has not addressed adequately. For example, suppose that the project fails a technical conformance test during field testing at the system verification stage. The technical failure would re- quire the team to cycle back to the appropriate point to analyze the cause for the field test failure and begin remedial steps to correct it. After a project team has received approval from the review team, it needs the approval of senior management before moving on to the next Tollgate stage. Rejection at this point by senior management often effec- tively kills the project.

New Product Introduction Process Seven Stages

Identify Customer Require- ments

Proposal Negotiation/ Resource Planning

Systems Design

Detailed Design

System Verification

Production/ Release

100 200 300 400 500 600 700

fIgure 3.6 Ge’s tollgate Process Source: Used with permission of General Electric Company.


98 Chapter 3 • Project Selection and Portfolio Management

Some critics argue that formalized and sophisticated review processes such as Tollgate add excessive layers of bureaucratic oversight to the project screening process. In fact, the sheer number of actions, steps, checklists, and mana- gerial reviews stipulated by the Tollgate process can add significant delays to projects—a critical concern if a project is needed to address an immediate problem. On the other hand, proponents of such techniques argue that the benefits— standardization across business units, comprehensive step-by-step risk analysis, clear links to top management—more than compensate for potential problems. At GE, the company credits Tollgate with promoting significant improvements in early problem discovery and “real-time” risk management.

Cross-Functional Section Management

Review Team

Senior Leadership Team (SLT)

Senior Mgmt. Review or

CEO Override

Tollgate Review

Tollgate Stage

Project Team

Review, Cost, Schedule, Risk Actions and Plans

Actions, Comments, Direction on Risk Issues, Status, Remedial Actions to Maintain Process Integrity

Approval to Continue Tollgate Process to Next Stage with Risk Mitigation and Action Plans

Checksheets Completed or Risk Issue for Incomplete Items

Risk Management Plans with Risk Score Card and Summary Sheet

Project Team

Reject Stop Work and Inform Customer




Project Team Works Issues Raised During the Review; After Three Rejections the Project Team Must Go to Senior Management for ApprovalProject Team

fIgure 3.7 the Ge tollgate review Process flow Map Source: Used with permission of General Electric Company.

3.4 Project PortfolIo ManageMent

Project portfolio management is the systematic process of selecting, supporting, and man- aging a firm’s collection of projects. According to the Project Management Institute, a company’s project portfolio consists of its projects, programs, subportfolios, and operations managed as a group to achieve strategic objectives.20 Projects are managed concurrently under a single umbrella and may be either related or independent of one another. The key to port- folio management is realizing that a firm’s projects share a common strategic purpose and the same scarce resources.21 For example, Pratt & Whitney Jet Engines, a subsidiary of United Technologies Corporation, is similar to other major jet engine manufacturers in creating a wide portfolio of engine types, from those developed for helicopters to those for jet aircraft, from civilian use to military consumption. Although the products share common features, the tech- nical challenges ensure that the product line is highly diverse. The concept of project portfolio management holds that firms should not manage projects as independent entities, but rather should regard portfolios as unified assets. There may be multiple objectives, but they are also shared objectives.22

Cooper23 has suggested that project portfolio management should have four goals: (1) max- imizing the value of the portfolio—the goal is to ensure that the total worth of projects in the pipeline yields maximum value to the company; (2) achieving the right balance of projects in the portfolio—there should be a balance between high-risk and low-risk, short-term and long-term, genuine new products and product improvement projects; (3) achieving a strategically aligned portfolio—leading companies have a clear product innovation strategy that directs their R&D proj- ect investments; and (4) resource balancing—having the right number of projects in the portfolio is critical. Too many firms invest in too many different projects that they cannot simultaneously support. Overextension just drains resources and causes top management to constantly shift their view from new project venture to new project venture, without providing sufficient support for any of them.

3.4 Project Portfolio Management 99

Artto24 notes that in a project-oriented company, project portfolio management poses a con- stant challenge between balancing long-term strategic goals and short-term needs and constraints. Managers routinely pose such questions as the following:

• What projects should the company fund? • Does the company have the resources to support them? • Do these projects reinforce future strategic goals? • Does this project make good business sense? • Is this project complementary to other company projects?

objectives and Initiatives

Each of the questions in the previous list has both short-term and long-term implications, and, taken together, they constitute the basis for both strategic project management and effective risk management. Portfolio management, therefore, entails decision making, prioritization, review, realignment, and reprioritization of a firm’s projects. Let’s consider each of these tasks in more detail.

decISIon MakIng The decision on whether or not to proceed in specific strategic directions is often influenced by market conditions, capital availability, perceived opportunity, and acceptable risk. A variety of project alternatives may be considered reasonable alternatives during portfolio development.

PrIorItIzatIon Because firms have limited resources, they typically cannot fund every project opportunity. Thus they must prioritize. For this task, several criteria may be used:

• Cost: Projects with lower development costs are more favorable because they come with less upfront risk.

• Opportunity: The chance for a big payout is a strong inducement for funding. • Top management pressure: Political pressure from top management (say, managers with pet

projects) can influence decisions. • Risk: Project payouts must justify some level of acceptable risk; those that are too risky are

scratched. • Strategic “fit”: If a firm has a policy of pursuing a family of products, all opportunities are

evaluated in terms of their complementarity—that is, either their strategic fit with existing product lines or their ability to augment the current product family.

• Desire for portfolio balance: A firm may want to offset risky initiatives by funding other projects. The Boston Consulting Group’s product matrix framework, for example, balances company product lines in terms of relative market share and product growth, suggesting that firms can maintain a strategic balance within their portfolios between products with differ- ent profiles. A firm might use its profitable but low-growth products to fund investment into projects with high growth prospects. Portfolio balance supports developing a strategy that allows companies the ability to balance or offset risk, explore alternative market opportuni- ties, and fund innovation in other product lines.

reVIeW All project alternatives are evaluated according to the company’s prioritization scheme. Projects selected for the firm’s portfolio are the ones that, based on those priorities, offer maximum return. For example, at the start of the current economic downturn, DHL Express started evaluat- ing its project portfolio through a new lens. The organization’s portfolio review board decided that all ongoing projects had to meet the following criteria: deliver return on investment (ROI) in 2009, be “mission-critical” to running the business, and address government or regulatory issues required to keep the business operational. Following an extensive portfolio review, a number of projects were temporarily discontinued.

realIgnMent When portfolios are altered by the addition of new projects, managers must re- examine company priorities. In the wake of new project additions, a number of important ques- tions should be considered. Does the new project conform to strategic goals as characterized by the project portfolio, or does it represent a new strategic direction for the firm? Does a new

100 Chapter 3 • Project Selection and Portfolio Management

project significantly alter the firm’s strategic goals? Does the portfolio now require additional rebalancing? The decision to change a portfolio by adding new projects restarts the analysis cycle in which we must again reexamine the portfolio for signs of imbalance or updating.

rePrIorItIzatIon If strategic realignment means shifting the company’s focus (i.e., creating new strategic directions), then managers must also reprioritize corporate goals and objectives. In this sense, then, portfolio management means managing overall company strategy. For example, Bayer Corporation, a global pharmaceutical giant, has found its corporate identity becoming less distinct due to the wide variety of acquisitions and other brands under which it markets its products. The company recently announced its intention to gradually eliminate many of the other brands that it owns under the “Bayer product umbrella” in order to emphasize the Bayer label. They found, after thorough analysis, that supporting a diverse set of brands in the Bayer Group was having the effect of diluting their signature brand. Consumers were confused about what Bayer actually made and that confusion was in danger of altering their perceptions of the quality of Bayer products.

developing a Proactive Portfolio

Portfolio management, therefore, is an important component in strategic project management. In addition to managing specific projects, organizations plan for profitability, and the road to prof- itability often runs through the area of strategic project management. One of the most effective methods for aligning profit objectives and strategic plans is the development of a proactive project portfolio, or an integrated family of projects, usually with a common strategic goal. Such a portfo- lio supports overall strategic integration, rather than an approach that would simply move from project opportunity to opportunity.

A useful model that has been applied to project portfolio management links the two issues of commercial potential and technical feasibility in judging among potential project alternatives to select for a firm’s portfolio. This portfolio classifies projects among four distinct types, depending on where they fall in the matrix (see Figure 3.8):25

1. Bread and butter projects are those with a high probability of technical feasibility and a modest likelihood for commercial profitability. These projects are typically evolutionary improve- ments to existing product lines or modest extensions to existing technology. A new release of a software product or “new and improved” laundry detergent are examples of bread and butter projects.

2. Pearls are projects that offer a strong commercial potential and are technically feasible. These projects can be used to gain strategic advantage in the marketplace. Pearls involve revolu- tionary commercial applications that have the potential to revolutionize a field while relying on well-known or understood technology. Examples of pearls are projects that involve new applications of existing technology, such as sonar imaging systems to detect deep-water oil reserves.

3. Oysters are early-stage projects that have the potential to unleash significant strategic and commercial advantages for the company that can solve the technical challenges. Because oys- ter projects involve unknown or revolutionary technologies, they are still at the early stages of possible success. If these technical challenges can be overcome, the company stands to make a great deal of money. An example of an oyster project is developing viable fusion power generation or extended life batteries for electric cars.

4. White elephant projects are a combination of low technical feasibility coupled with low commercial impact. The question could be asked: Why would a firm select white elephant projects that combine the worst of profitability and technical feasibility? The answer is that they do not deliberately select projects of this sort. Most white elephants start life as bread and butter projects or oysters that never live up to their potential. As a result, although originally undertaken with high hopes, white elephants end up consuming resources and wasting time, but they are often maintained with rationalizations such as, “We’ve already spent too much on it to just kill it now,” or “Influential members of the organization support it.”

Project matrixes like the one in Figure 3.8 are a useful means for companies to take a hard look at the current state of their project portfolio. Is there a good balance among project types?

3.4 Project Portfolio Management 101

Are there some obvious white elephants that need to be killed? Should the firm be investing in more (or fewer) strategic projects at the expense of bread and butter projects? Balancing tech- nical risk and potential return are twin goals of the project portfolio matrix and this process should be redone periodically to ensure that the state of the company’s portfolio is always updated.

It is also important to avoid making snap judgments or quick opinions of project oppor- tunities in order to classify them on the grid. Classifying your portfolio of projects into a matrix means that a company uses comprehensive and careful methods to identify projects of various types—white elephants, bread and butter, oysters, and pearls. Should we use quantitative scor- ing or screening models? Financial models? Some combination of several methods? Any of these approaches can be a useful starting point for classifying the current projects in the portfolio and identifying the value of potential new investments.

Consider the example of the large pharmaceutical firm Pfizer.26 Pfizer and its competi- tors routinely manage large families of projects in an integrated manner. The overall integration of project management efforts helps the company’s managers deal with certain realities of the pharmaceutical industry, such as extremely high development costs and long lead times for new products. In fact, as Table 3.10 shows, the lead time for bringing a new drug to market can easily stretch over 15 years, and the success rate of a drug being commercially developed is estimated to be less than 0.002%.

Therefore, at any particular point in time, Pfizer has numerous projects under research and development, a smaller number of projects entering various stages of clinical trials, and finally, an even smaller line of projects already on the market. Each step in the cycle is fraught with risks and uncertainties. Will a drug work in clinical trials? Will it have mini- mal negative side effects? Can it be produced in a cost-effective manner? Is it’s release time- sensitive (is there, for instance, a limited market opportunity of which to take advantage)? Often the answers to such questions will reduce Pfizer’s ongoing portfolio of development projects.

Commercial Potential – Why do it?

Low Net Present Value Given Success

Maintain competitiveness

Gain strategic advantage

White Elephants Oysters

Bread and Butter Pearls


H ig

h P

ro b

a b

ili ty

o f S

u c c e s s

L o


T e c h

n ic

a l

F e a si

b il

it y –

H o

w e

a sy

i s

it ?

fIgure 3.8 Project Portfolio Matrix

Source: D. Matheson, D. and J. E. Matheson. (1998). The Smart Organization: Creating Value through Strategic R&D. Boston, MA: Harvard Business School Press.

102 Chapter 3 • Project Selection and Portfolio Management

Under the risky circumstances of this industry, in which development time is lengthy, the financial repercussions of failure are huge, and success is never certain, pharmaceutical firms must practice highly sophisticated project portfolio management. Because failure rates are high and washouts constant, the need to take advantage of new product opportunities is critical. Only in this way can the company ensure a steady supply of new products in the pipeline.

The pitfalls and possibilities of the pharmaceuticals development process are illustrated in Figure 3.9. Drug companies compensate for the lengthy lead times necessary to get final approval

table 3.10 Phases in New Drug Development

Phase Duration % of Success contents

Discovery 4–7 yrs 1% Research a selected pool of molecules in computer models and test tubes.

Preclinical research

Test on animals and in test tubes to research the safety, possible indications, toxicology, and metabolism of the molecule.

Phase I 1 yr 70%–75% Small clinical studies on healthy volunteers to study the safety and ADME characteristics of the molecule.

Phase II 2 yrs 50% Small studies on patients with the target disease to study the efficacy, dosage, and formulation of the drug.

Phase III 3 yrs 75%–85% Large clinical studies on patients to confirm the results of phase II. The most expensive phase in the project.

Marketing Application (MA)

1.5–3 yrs 75%–80% Compile marketing authorization application (MAA) and send to the authorities. After the authorization the drug may be sold and marketed.

Total 12–16 yrs < 0.002%

Source: M. Lehtonen (2001). “Resource allocation and project portfolio management in pharmaceutical R&D,” in Artto, Martinsuo, and Aalto (Eds.), Project Portfolio Management: Strategic Management through Projects, pp. 107–140, figure on page 112. Helsinki, Finland: Project Management Association.

B u s in

e s s

L a u n c h

Product support



Time to market

Proof of Concept

D is

c o

v e ry

Start Phase I

Selection of molecule

Time to approval

Name of phase







fIgure 3.9 the flow of New Drug Development over time

Source: M. Lehtonen. (2001). “Resource allocation and project portfolio management in pharmaceutical R&D,” in Artto, Martinsuo, and Aalto (Eds.), Project Portfolio Management: Strategic Management through Projects, pp. 107–140, figure on page 120. Helsinki, Finland: Project Management Association.

3.4 Project Portfolio Management 103

of new products by simultaneously funding and managing scores of development efforts. Unfortunately, only a small proportion of an R&D portfolio will show sufficient promise to be advanced to the clinical trial stage. Many projects are further weeded out during this phase, with very few projects reaching the stage of commercial rollout.

Pfizer uses portfolio management to manage the flow of new drug development projects, much as Samsung and Erickson use it to keep track of product pipelines that include mobile phones, baseband modems, and firewall systems. Scott Paper manages a large portfolio of products and new project initiatives through the same portfolio management approaches. Project portfolios are necessary because a certain percentage of projects will be canceled prior to full funding, others will be eliminated during development, and still others will fail commercially. This cycle leaves only a few projects to account for a firm’s return on all of its investments. In short, any company that puts all its R&D eggs in one project basket runs huge risks if that project fails during development or proves disappointing in the marketplace. As a rule, therefore, companies guarantee themselves fallback options, greater financial stability, and the chance to respond to multiple opportunities by constantly creating and updating portfolios of projects.

Although there are no standard “rules” for the projects a company’s portfolio should contain, research into portfolio management across industries has found that for companies in certain industries, there may be general guidelines for the types of projects routinely being developed. For example, in a study of the IT industry, researchers found that the average firm’s project portfolio budget consists of 47% spent on infrastructure projects (intended to support essential elements of the organization, its networks, PCs, development tools, training and help desk support, and maintenance). The remaining 53% of the IT portfolio budget is spent on application projects, including “frontier” projects to alter the competitive landscape, enhancement projects to support better corporate performance, and utility applications for improving internal company processes. For the majority of IT firms, nearly 67% of their portfolio budget is spent on infrastructure and utility projects that make no direct business performance improvement but are nevertheless essential for the smooth-running operations of a company.27 This example demonstrates that it is possible to use research to determine the optimal mix of alternative project types within the portfolios of firms in other industries as a means to guide portfolio- balancing decisions.

keys to Successful Project Portfolio Management

Although examples of successfully managed portfolios abound, few researchers have investigated the key reasons why some companies are better at it than others. Brown and Eisenhardt28 studied six firms in the computer industry; all were involved in multiple project development activities. They determined that successfully managed project portfolios usually reflect the following three factors:

flexIble Structure and freedoM of coMMunIcatIon Multiple-project environments can- not operate effectively when they are constrained by restrictive layers of bureaucracy, narrow communication channels, and rigid development processes. Successful portfolios emerge from environments that foster flexibility and open communication. When project teams are allowed to improvise and experiment on existing product lines, innovative new product ideas are more likely to emerge.

loW-coSt enVIronMental ScannIng Many firms devote a lot of time and money in efforts to hit product “home runs.” They put their faith (and financing) in one promising project and aim to take the marketplace by storm, often without sufficiently analyzing alternative opportunities or future commercial trends. As a rule, successful project portfolio strategies call for launching a number of low-cost probes into the future, the idea behind environmental scanning—developing and market-testing a number of experimental product prototypes, sometimes by entering strategic alliances with potential partners. Successful firms do not rely on home runs and narrowly con- centrated efforts. They are constantly building and testing new projects prior to full-scale devel- opment. Rubbermaid, for example, routinely brings dozens of new product ideas to the market, samples the commercial response, and uses the resulting information to improve potential winners and discard products that don’t measure up.

104 Chapter 3 • Project Selection and Portfolio Management

tIMe-Paced tranSItIon Successful portfolio management requires a sense of timing, especially as firms make transitions from one product to the next. Successful firms use project portfolio plan- ning routinely to develop long lead times and plan ahead in order to make the smoothest possible transition from one product to another, whether the product lines are diverse or constitute creating a follow-on upgrade. Gillette, for example, has made a lucrative business out of developing and selling new models of shaving razors. Gillette’s product life cycle planning is highly sophisticated, allowing it to make accurate predictions of the likely life cycle of current products and the timing necessary for beginning new product development projects to maintain a seamless flow of con- sumer products.

Problems in Implementing Portfolio Management

What are some of the common problems in creating an effective portfolio management system? Although numerous factors can adversely affect the practice of portfolio management, recent research seems to suggest that the following are among the most typical problem areas.29

conSerVatIVe technIcal coMMunItIeS In many organizations, there is a core of technical professionals—project engineers, research scientists, and other personnel—who develop project prototypes. A common phenomenon is this group’s unwillingness, whether out of pride, organiza- tional inertia, or due to arguments supporting pure research, to give up project ideas that are too risky, too costly, or out of sync with strategic goals. Often, when top management tries to trim the portfolio of ongoing projects for strategic reasons, they find engineers and scientists reluctant to accept their reasoning. Data General Corporation, a manufacturer of computers and IT products, found itself increasingly under the dominance of its hardware engineering department, a group intent on pursuing their own new product goals and fostering their own vision for the organiza- tion. By the mid-1990s, with one product after another resulting in significant losses, the company could not continue to operate independently and was acquired by EMC Corporation.

out-of-Sync ProjectS and PortfolIoS Sometimes after a firm has begun realigning and repri- oritizing its strategic outlook, it continues to develop projects or invest in a portfolio that no longer accurately reflects its new strategic focus. Strategy and portfolio management must accurately re- flect a similar outlook. When strategy and portfolio management are out of alignment, one or both of two things will probably happen: Either the portfolio will point the firm toward outmoded goals or the firm’s strategy will revert to its old objectives.

unProMISIng ProjectS The worst-case scenario finds a company pursuing poor-quality or unnecessary projects. Honda, for example, has been pursuing hydrogen fuel technology for over 10 years and is marketing its FCX car in southern California with compressed hydrogen as its fuel source. Unfortunately, while the efficiency of the engine is high, the current difficulties in the technology make the FCX a questionable project choice to continue to support. The tanker trucks that replenish gasoline stations carrying hydrogen refueling pumps can carry about 300 fill-ups. However, hydrogen takes up much more space and requires high-pressure cylinders that weigh 65 times as much as the hydrogen they contain. Therefore, one giant, 13-ton hydrogen delivery truck can carry only about 10 fill-ups! By ignoring this critical flaw in the hydrogen economy idea Honda has a product is grossly inefficient compared to electric cars. Well-to-wheel efficiency analysis of the Honda FCX shows that the Tesla pure electric car is three times more efficient while producing only one-third the CO2 emissions.30

When portfolio management is geared to product lines, managers routinely rebalance the portfolio to ensure that there are a sufficient number of products of differing types to offset those with weaknesses. Revenues from “cash cows,” for example, can fund innovative new products. Sometimes critical analysis of a portfolio requires hard decisions, project cancellations, and real- located resources. But it is precisely this ongoing attention to the portfolio that prevents it from becoming weighted down with unpromising projects.

Scarce reSourceS A key resource for all projects is human capital. In fact, personnel costs comprise one of the highest sources of project expense. Additional types of resources include any raw materials, financial resources, or supplies that are critical to successfully completing the project. Before spending large amounts of time creating a project portfolio, organizations

thus like to ensure that the required resources will be available when needed. A principal cause of portfolio underperformance is a lack of adequate resources, especially personnel, to support required development.

Portfolio management is the process of bringing an organization’s project management practices into line with its overall corporate strategy. By creating complementary projects and creating synergies within its project portfolio, a company can ensure that its project manage- ment teams are working together rather than at cross-purposes. Portfolio management is also a visible symbol of the strategic direction and commercial goals of a firm. Taken together, the proj- ects that a firm chooses to promote and develop send a clear signal to the rest of the company about priorities, resource commitment, and future directions. Finally, portfolio management is an alternative method for managing overall project risk by seeking a continuous balance among various families of projects, between risks and return trade-offs, and between efficiently run projects and nonperformers. As more and more organizations rely on project management to achieve these ends, it is likely that more and more firms will take the next logical step: organiz- ing projects by means of portfolio management.


1. explain six criteria for a useful project selection/ screening model. No organization can pursue every opportunity that presents itself. Choices must be made, and to best ensure that they select the most viable projects, firms develop priority systems or guidelines—selection/screening models (or a set of models) that will help them make the best choices within the usual constraints of time and money— that is, help them save time and money while maxi- mizing the likelihood of success.

A number of decision models are available to managers who are responsible for evaluat- ing and selecting potential projects. Six impor- tant issues that managers should consider when evaluating screening models are: (1) Realism: An effective model must reflect organizational objec- tives, must be reasonable in light of constraints on resources such as money and personnel, and must take into account both commercial risks and technical risks. (2) Capability: A model should be flexible enough to respond to changes in the con- ditions under which projects are carried out and robust enough to accommodate new criteria and constraints. (3) Flexibility: The model should be easily modified if trial applications require chang- es. (4) Ease of use: A model must be simple enough to be used by people in all areas of the organiza- tion, and it should be timely in that it generates information rapidly and allows people to assimi- late that information without any special training or skills. (5) Cost: The cost of gathering, storing, and arranging information in the form of useful reports or proposals should be relatively low in relation to the costs associated with implement- ing a project (i.e., the cost of the models must be low enough to encourage their use rather than diminish their applicability). (6) Comparability:

The model must be broad enough that it can be applied to multiple projects and support general comparisons of project alternatives.

2. understand how to employ checklists and sim- ple scoring models to select projects. Checklists require decision makers to develop a list of the cri- teria that are deemed important when considering project alternatives. For example, a firm may decide that all project alternatives must be acceptable on criteria such as return on investment, safety, cost of development, commercial opportunities, and stake- holder acceptability. Once the list of criteria is cre- ated, all project alternatives are evaluated against it and assigned a rating of high, medium, or low depending on how well they satisfy each criterion in the checklist. Projects that rate highest across the relevant criteria are selected. Checklists are use- ful because they are simple and require the firm to make trade-off decisions among criteria to deter- mine which issues are most important in selecting new projects. Among their disadvantages are the subjective nature of the rating process and the fact that they assume equal weighting for all criteria when some, in fact, may be much more important than others in making the final decision.

Simple scoring models are similar to checklists except that they employ criterion weights for each of the decision criteria. Hence, all project alterna- tives are first weighted by the importance score for the criterion, and then final scores are evaluated against one another. The advantage of this method is that it recognizes the fact that decision criteria may be weighted differently, leading to better choices among project alternatives. The disadvantages of the method arise from the difficulty in assigning meaningful values to scoring anchors such as “High

= 3, Medium = 2, Low = 1.” Thus, there is some

Summary 105

106 Chapter 3 • Project Selection and Portfolio Management

uncertainty in the interpretation of the results of sim- ple scoring models using weighted rankings. The usefulness of these models depends on the relevance of the selected criteria and the accuracy of the weight given to them.

3. use more sophisticated scoring models, such as the Analytical hierarchy Process. The Analytical Hierarchy Process (AHP) is a four-step process that allows decision makers to understand the nature of project alternatives in making selection decisions. Using the AHP, decision makers (a) structure the hierarchy of criteria to be used in the decision pro- cess, (b) allocate weights to these criteria, (c) assign numerical values to all evaluation dimensions, and (d) use the scores to evaluate project alternatives. The AHP has been shown to create more accurate decision alternatives and lead to more informed choices, provided the organization’s decision mak- ers develop accurate decision criteria and evaluate and weight them honestly.

4. learn how to use financial concepts, such as the efficient frontier and risk/return models. Many projects are selected as a result of their perceived risk/return trade-off potential. That is, all projects entail risk (uncertainty), so project organizations seek to balance higher risk with comparatively higher expectations of return when consider- ing which projects to fund. The efficient frontier concept allows projects to be evaluated against each other by assessing the potential returns for each alternative compared to the risk the firm is expected to undertake in producing the project. The efficient frontier is the set of project portfolio options that offers either a maximum return for every given level of risk or the minimum risk for every level of return.

5. employ financial analyses and options analysis to evaluate the potential for new project invest- ments. Financial analyses using discounted cash flows and internal rates of return allow us to apply the concept of the time value of money to any deci- sion we have to make regarding the attractiveness of various project alternatives. The time value of money

suggests that future streams of return from a project investment should at least offset the initial invest- ment in the project plus provide some required rate of return imposed by the company. Options analy- sis takes this process one step further and considers alternatives in which an investment is either made or foregone, depending upon reasonable alternative investments the company can make in the future. Each of these financial models argues that the prin- cipal determinant of an attractive project investment must be the money it promises to return. Clearly, therefore, a reasonably accurate estimate of future streams of revenue is required for financial models to create meaningful results.

6. recognize the challenges that arise in maintain- ing an optimal project portfolio for an organiza- tion. A  number of challenges are associated with managing a portfolio of projects, including (a) con- servative technical communities that refuse to sup- port new project initiatives, (b) out-of-sync projects and portfolios in which the projects no longer align with overall strategic portfolio plans, (c) unpromis- ing projects that unbalance the portfolio, and (d) scarce resources that make it impossible to support new projects.

7. understand the three keys to successful project portfolio management. There are three keys to suc- cess project portfolio management. First, firms need to create or make available a flexible structure and freedom of communication by reducing excessive bureaucracy and administrative oversight so that the portfolio management team maximum has flexibil- ity in seeking out and investing in projects. Second, use of successful portfolio management strategies allows for low-cost environmental scanning, which launches a series of inexpensive “probes” into the future to develop and test-market project alterna- tives. Finally, successful portfolio management requires a time-paced transition strategy based on a sense of the timing necessary to successfully transi- tion from one product to the next, whether the next product is a direct offshoot of the original or an addi- tional innovative product for the firm’s portfolio.

Key Terms

Analytical Hierarchy Process (AHP) (p. 84) Checklist (p. 80) Discounted cash flow (DCF) method (p. 90) Discounted payback method (p. 94) Efficient frontier (p. 88)

Internal rate of return (IRR) (p. 94) Lead time (p. 101) Net present value (NPV) method (p. 92) Nonnumeric models (p. 79) Numeric models (p. 79) Pairwise comparison approach (p. 85)

Payback period (p. 90) Present value of money (p. 90) Profile models (p. 88) Project portfolio (p. 78) Project portfolio management (p. 98) Project screening model (p. 80)

Required rate of return (RRR) (p. 94) Risk/return (p. 88) Simplified scoring model (p. 82) Time value of money (p. 90)

3.1 Net PreSeNt VAlUe Your firm is trying to decide whether to invest in a new proj- ect opportunity based on the following information. The initial cash outlay will total $250,000 over two years. The firm expects to invest $200,000 immediately and the final $50,000 in one year’s time. The company predicts that the project will gen- erate a stream of earnings of $50,000, $100,000, $200,000, and $75,000 per year, respectively, starting in Year 2. The required rate of return is 12%, and the expected rate of inflation over the life of the project is forecast to remain steady at 3%. Should you invest in this project?


In order to answer this question, we need to organize the fol- lowing data in the form of a table:

Total outflow = $250,000 Total inflow = $400,000 Required rate of return (r) = 12% Inflation rate (p) = 3% Discount factor = 1/(1 + r + p)t

The result is shown in Table 3.11. Because the discounted revenue stream is positive ($11,725), the project would be a good investment and should be pursued.

3.2 DiScoUNteD PAYBAck Your firm has the opportunity to invest $75,000 in a new project opportunity but due to cash flow concerns, your boss wants to know when you can pay back the original invest- ment. Using the discounted payback method, you determine that the project should generate inflows of $30,000, $30,000, $25,000, $20,000, and $20,000 respectively for an expected five years after completion of the project. Your firm’s required rate of return is 10%.


To answer this question, it is helpful to organize the information into a table. Remember that:

Total outflow = $75,000 Required rate of return = 10% Discount factor = 1/(1 + .10)t

Year cash flow Discount

factor Net


0 ($75,000) 1.00 ($75,000)

1 30,000 .91 27,300

2 30,000 .83 24,900

3 25,000 .75 18,750

4 20,000 .68 13,600

5 20,000 .62 12,400

Payback = 3.3 years

3.3 iNterNAl rAte of retUrN Suppose that a project required an initial cash investment of $24,000 and was expected to generate inflows of $10,000, $10,000, and $10,000 for the next three years. Further, assume that our company’s required rate of return for new projects is 12%. Is this project worth funding? Would it be a good invest- ment if the company’s required rate of return were 15%? Use the following figures to determine the answers to these ques- tions:

Cash investment = $24,000 Year 1 inflow = $10,000 Year 2 inflow = $10,000 Year 3 inflow = $10,000 Required rate of return = 12%

table 3.11 Discounted cash flows and NPV (ii)

Year inflows outflows Net flow Discount factor NPV

0 $ 0 $200,000 $(200,000) 1.0000 $(200,000)

1 0 50,000 (50,000) .8696 (43,480) 2 50,000 0 50,000 .7561 37,805 3 100,000 0 100,000 .6575 65,750 4 200,000 0 200,000 .5718 114,360 5 75,000 0 75,000 .4972 37,290

total $ 11,725

Solved Problems

Solved Problems 107

108 Chapter 3 • Project Selection and Portfolio Management


step one: trying 10%.

Discount factor

Year inflows at 10% NPV

1 $10,000 .909 $ 9,090

2 10,000 .826 8,260

3 10,000 .751 7,510

Present value of inflows 24,860

Cash investment −24,000

Difference $ 860

decision: Present value difference at 10% is $860, which is too high. Try a higher discount rate.

step two: using 12%.

Discount factor

Year inflows at 12% NPV

1 $10,000 .893 $ 8,930

2 10,000 .797 7,970

3 10,000 .712 7,120

Present value of inflows 24,020

Cash investment −24,000

Difference $ 20

decision: Present value difference at 12% is $20, which suggests that 12% is a close approximation of the IRR. This project would be a good investment at 12%, but it would not be acceptable if the firm’s required rate of return were 15%.

Discussion Questions

1. If you were to prioritize the criteria for a successful screening model, which criteria would you rank at the top of your priority list? Why?

2. What are the benefits and drawbacks of checklists as a method for screening project alternatives?

3. How does use of the Analytical Hierarchy Process (AHP) aid in project selection? In particular, what as- pects of the screening process does the AHP seem to address and improve directly?

4. What are the benefits and drawbacks of the profile model for project screening? Be specific about the problems that may arise in identifying the efficient frontier.

5. How are financial models superior to other screening models? How are they inferior?

6. How does the options model address the problem of nonrecoverable investment in a project?

7. What advantages do you see in the GE Tollgate screen- ing approach? What disadvantages do you see? How would you alter it?

8. Why is project portfolio management particularly chal- lenging in the pharmaceutical industry?

9. What are the keys to successful project portfolio management?

10. What are some of the key difficulties in successfully implementing project portfolio management practices?


3.1 checklist. Suppose that you are trying to choose which of two IT projects to accept. Your company employs three primary selection criteria for evaluating all IT projects: (1) proven technology, (2) ease of transition, and (3)  projected cost savings.

One option, Project Demeter, is evaluated as:

Technology high Ease of transition low Projected cost savings high

The second option, Project Cairo, is evaluated as:

Technology medium Ease of transition high Projected cost savings high

Construct a table identifying the projects, their evaluative criteria, and ratings. Based on your analysis, which project would you argue in favor of adopting? Why?

3.2 checklist. Consider the following information in choosing among the four project alternatives below (labeled A, B, C, and D). Each has been assessed according to four criteria:

• Payoff potential • Lack of risk

• Safety • Competitive advantage

Project A is rated:

Payoff potential high Safety high

Lack of risk low Competitive advantage


Project B is rated:

Payoff potential low Safety medium

Lack of risk medium Competitive advantage


Project C is rated:

Payoff potential medium Safety low

Lack of risk medium Competitive advantage


Project D is rated:

Payoff potential high Safety medium

Lack of risk high Competitive advantage


Construct a project checklist model for screening these four alternatives. Based on your model, which project is the best choice for selection? Why? Which is the worst? Why?

3.3 scoring Model. Suppose the information in Problem 2 was supplemented by importance weights for each of the four assessment criteria, where 1 = low importance and 4 = high importance:

Assessment criteria importance Weights

1. Payoff potential 4

2. Lack of risk 3

3. Safety 1

4. Competitive advantage 3

Assume, too, that evaluations of high receive a score of 3, medium 2, and low 1. Recreate your project scoring model and reassess the four project choices (A, B, C, and D). Now which project alternative is the best? Why?

3.4 scoring Model. Now assume that for Problem 3, the im- portance weights are altered as follows:

Assessment criteria importance Weights

1. Payoff potential 1

2. Lack of risk 1

3. Safety 4

4. Competitive advantage 2

How does this new information alter your decision? Which project now looks most attractive? Why?

3.5 screening Model. Assume that the following criteria rel- evant to the process of screening various project opportu- nities are weighted in importance as follows:

Quality (7) Cost (3) Speed to market (5) Visibility (1) Reliability (7)

Our company has four project alternatives that satisfy these key features as follows:

Alpha Beta Gamma Delta

Quality 1 3 3 5

Cost 7 7 5 3

Speed 5 5 3 5

Visibility 3 1 5 1

Reliability 5 5 7 7

Construct a project screening matrix to identify among these four projects the most likely candidate to be implemented.

3.6 screening Model. Assume that the following criteria rel- evant to the process of screening various construction proj- ect opportunities are weighted in importance as follows:

Safety (10) Speed to completion (5)

Sustainable development (4) Infrastructure modifications (3) Traffic congestion (5) Cost (8)

Our company has four project alternatives that satisfy these key features as follows:

Midtown Uptown Downtown Suburb

Safety 6 5 3 8

Speed 3 4 2 5

Sustainable 7 7 5 4

Infrastructure 4 5 4 1

Traffic 2 4 1 8

Cost 5 5 3 6

Construct a project screening matrix to identify among these four projects the most likely candidate to be implemented.

3.7 Profile Model. Assume the project profile model shown in Figure 3.10. Define the efficient frontier. The dotted lines represent the minimum return and the maximum risk that the company will accept. Which projects would be suitable for retaining and which should be dropped from the com- pany’s portfolio? Why?

3.8 Profile Model. Using the information from the profile model in Problem 7, construct an argument as to why proj- ect B is preferable to project C.

3.9 discounted Payback. Your company is seriously consider- ing investing in a new project opportunity, but cash flow is tight. Top management is concerned about how long it will take for this new project to pay back the initial investment of $50,000. You have determined that the project should gener- ate inflows of $30,000, $30,000, $40,000, $25,000, and $15,000 for the next five years. Your firm’s required rate of return is 15%. How long will it take to pay back the initial investment?

3.10 net Present value. Assume that your firm wants to choose between two project options:

• Project A: $500,000 invested today will yield an expected income stream of $150,000 per year for five years, start- ing in Year 1.

• Project B: an initial investment of $400,000 is expected to produce this revenue stream: Year 1 = 0, Year 2 = $50,000, Year 3 = $200,000, Year 4 = $300,000, and Year 5 = $200,000.



Risk F




fIgure 3.10 Project Profile Model (Problem 7)

Problems 109

110 Chapter 3 • Project Selection and Portfolio Management

Assume that a required rate of return for your company is 10% and that inflation is expected to remain steady at 3% for the life of the project. Which is the better investment? Why?

3.11 net Present value. Your vice president of Management Information Systems informs you that she has re- searched the possibility of automating your organiza- tion’s order-entry system. She has projected that the new system will reduce labor costs by $35,000 each year over the next five years. The purchase price (including installation and testing) of the new system is $125,000. What is the net present value of this investment if the discount rate is 10% per year?

3.12 net Present value. A company has four project investment alternatives. The required rate of return on projects is 20%, and inflation is projected to remain at 3% into the foresee- able future. The pertinent information about each alterna- tive is listed in the following chart:

Which project should be the firm’s first priority? Why? If the company could invest in more than one project, indi- cate the order in which it should prioritize these project alternatives.

3.13 Portfolio Management. Crown Corporation is interested in expanding its project portfolio. This firm, which special- izes in water conservation and land reclamation projects, anticipates a huge increase in the demand for home fuel cells as an alternative to current methods of energy gen- eration and usage. Although fuel-cell projects involve dif- ferent technologies than those in which Crown currently specializes, the profit potential is very large. Develop a list of benefits and drawbacks associated with this potential expansion of Crown’s project portfolio. In your opinion, do the risks outweigh the advantages from such a move? Justify your answer.

Project carol Year investment revenue Streams

0 $ 500,000 $ 0 1 50,000

2 250,000 3 350,000

Project George Year investment revenue Streams

0 $ 250,000 $ 0 1 75,000 2 75,000 3 75,000 4 50,000

Project thomas Year investment revenue Streams

0 $1,000,000 $ 0 1 200,000 2 200,000 3 200,000 4 200,000 5 200,000 6 200,000

Project Anna Year investment revenue Streams

0 $ 75,000 $ 0 1 15,000 2 25,000 3 50,000 4 50,000 5 150,000

3.14 Project screening. Assume you are the IT manager for a large urban health care system. Lately you have been bombarded with requests for new projects, including sys- tem upgrades, support services, automated record keep- ing, billing, and so forth. With an average of 50 software and hardware support projects going on at any time, you have decided that you must create a system for screening new project requests from the various departments within

the health care system. Develop a project selection and screening system similar to GE’s Tollgate process. What elements would you include in such a system? How many steps would you recommend? At what points in the pro- cess should “gates” be installed? How might a tollgate system for a software development company differ from one used by an architectural firm specializing in the de- velopment of commercial office buildings?

CaSe STuDy 3.1 Keflavik Paper Company

In recent years, Keflavik Paper Company has been having problems with its project management process. A number of commercial projects, for example, have come in late and well over budget, and product perfor- mance has been inconsistent. A comprehensive anal- ysis of the process has traced many of the problems back to faulty project selection methods.

Keflavik is a medium-sized corporation that manufactures a variety of paper products, including specialty papers and the coated papers used in the photography and printing industries. Despite cycli- cal downturns due to general economic conditions, the firm’s annual sales have grown steadily though slowly. About five years ago, Keflavik embarked on a project-based approach to new product opportu- nities. The goal was to improve profitability and generate additional sales volume by developing new commercial products quickly, with better tar- geting to specific customer needs. The results so far have not been encouraging. The company’s project development record is spotty. Some projects have been delivered on time, but others have been late; budgets have been routinely overrun; and product performance has been inconsistent, with some proj- ects yielding good returns and others losing money.

Top management hired a consultant to analyze the firm’s processes and determine the most efficient way to fix its project management procedures. The con- sultant attributed the main problems not to the project management processes themselves, but to the manner in which projects are added to the company’s portfo- lio. The primary mechanism for new project selection focused almost exclusively on discounted cash flow models, such as net present value analysis. Essentially, if a project promised profitable revenue streams, it was approved by top management.

One result of this practice was the develop- ment of a “family” of projects that were often almost completely unrelated. No one, it seems, ever asked whether projects that were added to the portfolio fit with other ongoing projects. Keflavik attempted to expand into coated papers, photographic products, shipping and packaging materials, and other lines that strayed far from the firm’s original niche. New projects were rarely measured against the firm’s strategic mission, and little effort was made to eval- uate them according to its technical resources. Some new projects, for example, failed to fit because they required significant organizational learning and new technical expertise and training (all of which

was expensive and time-consuming). The result was a portfolio of diverse, mismatched projects that was difficult to manage.

Further, the diverse nature of the new product line and development processes decreased organiza- tional learning and made it impossible for Keflavik’s project managers to move easily from one assignment to the next. The hodgepodge of projects made it dif- ficult for managers to apply lessons learned from one project to the next. Because the skills acquired on one project were largely nontransferable, project teams routinely had to relearn processes whenever they moved to a new project.

The consultant suggested that Keflavik rethink its project selection and screening processes. In order to lend some coherence to its portfolio, the firm needed to include alternative screening mechanisms. All new projects, for instance, had to be evaluated in terms of the company’s strategic goals and were required to demonstrate complementarity with its current portfolio. He further recommended that in order to match project managers with the types of projects that the company was increasingly under- taking, it should analyze their current skill sets. Although Keflavik has begun implementing these and other recommendations, progress so far has been slow. In particular, top managers have found it hard to reject opportunities that offer positive cash flow. They have also had to relearn the importance of project prioritization. Nevertheless, a new prioritiza- tion scheme is in place, and it seems to be improving both the selection of new project opportunities and the company’s ability to manage projects once they are funded.


1. Keflavik Paper presents a good example of the dangers of excessive reliance on one screening technique (in this case, discounted cash flow). How might excessive or exclusive reliance on other screening methods discussed in this chap- ter lead to similar problems?

2. Assume that you are responsible for maintaining Keflavik’s project portfolio. Name some key cri- teria that should be used in evaluating all new projects before they are added to the current portfolio.

3. What does this case demonstrate about the ef- fect of poor project screening methods on a firm’s ability to manage its projects effectively?


Case Study 3.1 111

112 Chapter 3 • Project Selection and Portfolio Management

CaSe STuDy 3.2 Project Selection at Nova Western, Inc.

Phyllis Henry, vice president of new product devel- opment, sat at her desk, trying to make sense of the latest new project proposals she had just received from her staff. Nova Western, Inc., a large developer of business software and application programs, had been experiencing a downturn in operating revenues over the past three quarters. The senior management team was feeling pressure from the board of direc- tors to take steps to correct this downward drift in revenues and profitability. The consensus opinion was that Nova Western needed some new product ideas, and fast.

The report Phyllis was reading contained the results of a project screening conducted by two independent groups within the new product devel- opment department. After several weeks of analysis, it appeared that two top contenders had emerged as the optimal new project opportunities. One project, code-named Janus, was championed by the head of software development. The other project idea, Gemini, had the support of the business applications organization. Phyllis’s original charge to her staff was to prepare an evaluation of both projects in order to decide which one Nova Western should support. Because of budget restrictions, there was no way that both projects could be funded.

The first evaluation team used a scoring model, based on the key strategic categories at Nova Western, to evaluate the two projects. The catego- ries they employed were: (1) strategic fit, (2) prob- ability of technical success, (3) financial risk, (4) potential profit, and (5) strategic leverage (ability of the project to employ and enhance company resources and technical capabilities). Using these categories, the team evaluated the two projects as shown here. Scores were based on: 1 = low, 2 = medium, and 3 = high.

Project janus

category importance Score Weighted Score

1. Strategic fit 3 2 6

2. Probability of technical success 2 2 4

3. Financial risk 2 1 2

4. Potential profit 3 3 9

5. Strategic leverage 1 1 1

Score = 22

Project Gemini

category importance Score Weighted


1. Strategic fit 3 3 9

2. Probability of technical success 2 2 4

3. Financial risk 2 2 4

4. Potential profit 3 3 9

5. Strategic leverage 1 2 2

Score = 28

The results obtained by this first team suggested that Project Gemini would the best choice for the next new project.

The second team of evaluators presented an NPV analysis of the two projects to Phyllis. In that analysis, the evaluators assumed a required rate of return of 15% and an anticipated inflation rate of 3% over the life of the project. The findings of this team were as follows:

Project janus

Initial investment = $250,000 Life of the project = 5 years Anticipated stream of future cash flows:

Year 1 = $ 50,000 Year 2 = 100,000 Year 3 = 100,000 Year 4 = 200,000 Year 5 = 75,000 Calculated NPV = $ 60,995

Project Gemini

Initial investment = $400,000 Life of the project = 3 years Anticipated stream of future cash flows:

Year 1 = $ 75,000 Year 2 = 250,000 Year 3 = 300,000 Calculated NPV = $ 25,695

Thus, according to this analysis, Project Janus would be the project of choice.

The analyses of the two projects by different means yielded different findings. The scoring model indicated that Project Gemini was the best alternative,

and the financial screening favored the higher pro- jected NPV of Project Janus. Phyllis, who was due to present her recommendation to the full top manage- ment team in the afternoon, was still not sure which project to recommend. The evaluations seemed to present more questions than answers.


1. Phyllis has called you into her office to help her make sense of the contradictions in the two project evaluations. How would you explain the

reasons for the divergence of opinion from one technique to the next? What are the strengths and weaknesses of each screening method?

2. Choose the project that you think, based on the two analyses, Nova Western should select. Defend your choice.

3. What does this case suggest to you about the use of project selection methods in organizations? How would you resolve the contradictions found in this example?

Internet exercises

3.1 Go to the Web sites for the following organizations:

a. Merck & Company Pharmaceuticals: about/

b. Boeing Corporation: companyoffices/aboutus/

c. Rolls-Royce, Plc.: d. ExxonMobil, Inc.:


Based on your review of the companies’ posted mission and strategic goals, what types of projects would you

expect them to pursue? If you worked for one of these firms and sought to maintain strategic alignment with their project portfolio, what project options would you suggest?

3.2 Access the Web site tools/portfolio/. What is IBM’s philosophy regarding project portfolio management as demonstrated by this software product? What do they mean by stating that their goal is to help clients overcome the influence of the loudest voice in the room and use objective information to support decision making?


1. Texas Department of Transportation (2013). Project Selection Process.

2. Foti, R. (2002). “Priority decisions,” PMNetwork, 16(4): 24–29; Crawford, J. K. (2001). “Portfolio management: Overview and best practices,” in J. Knutson (Ed.), Project Management for Business Professionals. New York: Wiley, pp. 33–48; Wheatley, M. (2009). “Making the cut,” PMNetwork, 23(6): 44–48; Texas Department of Transportation. (2013). Project Selection Process, txdot-info/fin/utp/2013_psp.pdf.

3. Pascale, S., Carland, J. W., and Carland, J. C. (1997). “A comparative analysis of two concept evaluation meth- ods for new product development projects,” Project Management Journal, 28(4): 47–52; Wheelwright, S. C., and Clark, K. B. (1992, March–April). “Creating project plans to focus product development,” Harvard Business Review, 70(2): 70–82.

4. Souder, W. E., and Sherman, J. D. (1994). Managing New Technology Development. New York: McGraw-Hill; Souder, W. E. (1983). Project Selection and Economic Appraisal. New York: Van Nostrand Reinhold.

5. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Management, 5th ed. New York: Wiley.

6. Khorramshahgol, R., Azani, H., and Gousty, Y. (1988). “An integrated approach to project evaluation and selec- tion,” IEEE Transactions on Engineering Management, EM-35(4): 265–70; Raz, T. (1997). “An iterative screening

methodology for selecting project alternatives,” Project Management Journal, 28(4): 34–39.

7. Cleland, D. I. (1988). “Project stakeholder manage- ment,” in Cleland, D. I., and King, W. R. (Eds.), Project Management Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp. 275–301.

8. Artto, K. A., Martinsuo, M., and Aalto, T. (Eds.) (2001). Project Portfolio Management: Strategic Management Through Projects. Helsinki: Project Management Association; Artto, K. A. (2001). “Management of project-oriented organiza- tion—Conceptual analysis,” in Artto, K. A., Martinsuo, M., and Aalto, T. (Eds.), Project Portfolio Management: Strategic Management Through Projects. Helsinki: Project Management Association.

9. Pinto, J. K., and Millet, I. (1999). Successful Information System Implementation: The Human Side, 2nd ed. Newtown Square, PA: Project Management Institute.

10. Saaty, T. L. (1996). The Analytical Hierarchy Process. Pittsburgh, PA: RWS Publications.

11. Millet, I. (1994, February 15). “Who’s on first?” CIO Magazine, pp. 24–27.

12. Mian, S. A., and Dai, C. X. (1999). “Decision-making over the project life cycle: An analytical hierarchy approach,” Project Management Journal, 30(1): 40–52.

13. Foreman, E. H., Saaty, T. L., Selly, M., and Waldron, R. (1996). Expert Choice. McLean, VA: Decision Support Software.

Notes 113

114 Chapter 3 • Project Selection and Portfolio Management

14. Millet, I., and Schoner, B. (2005). “Incorporating negative values into the Analytical Hierarchy Process,” Computers and Operations Research, 12(3): 163–73.

15. Evans, D. A., and Souder, W. E. (1998). “Methods for selecting and evaluating projects,” in Pinto, J. K. (Ed.), The Project Management Institute Project Management Handbook. San Francisco, CA: Jossey-Bass.

16. Reilly, F. K. (1985). Investment Analysis and Portfolio Management, 2nd ed. Chicago, IL: The Dryden Press.

17. Keown, A. J., Scott, Jr., D. F., Martin, J. D., and Petty, J. W. (1996). Basic Financial Management, 7th ed. Upper Saddle River, NJ: Prentice Hall; Evans, D. A., and Souder, W. E. (1998). “Methods for selecting and evaluating projects,” in Pinto, J. K. (Ed.), The Project Management Institute Project Management Handbook. San Francisco, CA: Jossey-Bass.

18. Meredith, J. R., and Mantel, S. J. (2003). Project Management, 5th ed. New York: Wiley.

19. Cooper, R. G. (2007). Doing it Right: Winning with New Products. Product Development Institute. www.iirusa. com/upload/wysiwyg/2008-M-Div/M2004/White_ Papers/Doing-it-right.pdf.

20. Project Management Institute (2013). A Guide to the Project Management Body of Knowledge, 5th ed. Newtown Square, PA: PMI.

21. Dye, L. D., and Pennypacker, J. S. (Eds.) (1999). Project Portfolio Management: Selecting and Prioritizing Projects for Competitive Advantage. West Chester, PA: Center for Business Practices.

22. Elton, J., and Roe, J. (1998, March–April). “Bringing dis- cipline to project management,” Harvard Business Review, 76(2): 153–59.

23. Cooper, R. G. (2007), as cited in note 19. 24. Artto, K. A. (2001). “Management of project-oriented

organization—Conceptual analysis,” in Artto, K. A., Martinsuo, M., and Aalto, T. (Eds.), Project Portfolio Management: Strategic Management Through Projects. Helsinki: Project Management Association.

25. Matheson, D., and Matheson, J. E. (1998). The Smart Organization: Creating Value through Strategic R&D. Boston, MA: Harvard Business School Press; Cooper, R. G., Edgett, S. J., and Kleinschmidt, E. J. (2001), Portfolio Management for New Products, 2nd ed. Cambridge, MA: Perseus Press.

26. Lehtonen, M. (2001). “Resource allocation and project portfolio management in pharmaceutical R&D,” in Artto, K. A., Marinsuo, M., and Aalto, T. (Eds.). (2001). Project Portfolio Management: Strategic Management Through Projects. Helsinki: Project Management Association, pp. 107–140.

27. Light, M., Rosser, B., and Hayward, S. (2005). Realizing the Benefits of Project and Portfolio Management. Stamford, CT: Gartner. gartner_PPM_magic_quadrant_2009.pdf

28. Brown, S. L., and Eisenhardt, K. M. (1997). “The art of continuous change: Linking complexity theory and time- paced evolution in relentlessly shifting organizations,” Administrative Science Quarterly, 42(1): 1–34.

29. Cooper, R., and Edgett, S. (1997). “Portfolio manage- ment in new product development: Less from the leaders I,” Research Technology Management, 40(5): 16–28; Longman, A., Sandahl, D., and Speir, W. (1999). “Preventing project proliferation,” PMNetwork, 13(7): 39–41; Dobson, M. (1999). The Juggler’s Guide to Managing Multiple Projects. Newtown Square, PA: Project Management Institute.

30. Blakeslee, T. R. (2008, September 2). “The elephant under the rug: Denial and failed energy projects,” www.renewableenergy- under-the-rug-denial-and-failed-energy-projects-53467; Baime, A. J. (2014, January 14). “Life with a Hydrogen Fuel Cell Honda,” Wall Street Journal. http://online.wsj. com/news/articles/SB100014240527023045495045793206 41877168558.


4 ■ ■ ■

Leadership and the Project Manager

Chapter Outline Project Profile

Leading by Example for the London Olympics—Sir John Armitt

introduction 4.1 leaders Versus Managers 4.2 How tHe Project Manager leads

Acquiring Project Resources Motivating and Building Teams Having a Vision and Fighting Fires Communicating

Project ManageMent researcH in Brief Leadership and Emotional Intelligence

4.3 traits of effectiVe Project leaders Conclusions About Project Leaders

Project Profile Dr. Elattuvalapil Sreedharan, India’s Project

Management Guru 4.4 Project cHaMPions

Champions—Who Are They? What Do Champions Do? How to Make a Champion

4.5 tHe new Project leadersHiP Project Managers in Practice

Bill Mowery, CSC Project Profile

The Challenge of Managing Internationally

4.6 Project ManageMent ProfessionalisM

Summary Key Terms Discussion Questions Case Study 4.1 In Search of Effective Project

Managers Case Study 4.2 Finding the Emotional

Intelligence to Be a Real Leader Case Study 4.3 Problems with John Internet Exercises PMP Certification Sample Questions Notes

Chapter Objectives After completing this chapter, you should be able to: 1. Understand how project management is a “leader-intensive” profession. 2. Distinguish between the role of a manager and the characteristics of a leader. 3. Understand the concept of emotional intelligence as it relates to how project managers lead. 4. Recognize traits that are strongly linked to effective project leadership. 5. Identify the key roles project champions play in project success. 6. Recognize the principles that typify the new project leadership. 7. Understand the development of project management professionalism in the discipline.

116 Chapter 4 • Leadership and the Project Manager

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Responsibilities and Competencies of the Project Manager (PMBoK sec. 1.7.1) 2. Interpersonal Skills of the Project Manager (PMBoK sec. 1.7.2) 3. Manage Project Team (PMBoK sec. 9.4) 4. Project Communications Management (PMBoK sec. 10) 5. Manage Stakeholder Engagement (PMBoK sec. 13.3)

Project Profile

leading by example for the london olympics—Sir john Armitt

England’s John Armitt had run major contractor, including pioneering pioneered UK’s first high-speed-rail system, and steer- ing the national railroad infrastructure company out of bankruptcy, when he was named chairman of the Olympic Delivery Authority (ODA), charged with building all infrastructure and facilities for London’s 2012 Olympic and Paralympic games.

“I was immediately interested,” he says. When London won the bid to develop the 2012 Olympics, the challenges it faced were significant. London is a

city that is heavily congested, with little open ground or natural sites left for development. The challenge of putting up multiple stadiums, sporting venues, Olympic Village structures, and transportation infrastructure defines the complex- ity of the massive project, all under the requirement that the completed work meet a fixed deadline. More than $10 billion worth of construction later, London’s widely acclaimed Olympics were enhanced by complete and fully function- ing facilities. A 600-acre urban site had been converted into a multi-venue park and athletes’ village on schedule and $1.6 billion under budget. In addition, not one life was lost during 70 million worker hours, and the project’s accident rate was well below the UK average. For his performance in steering the complex development project, Armitt was granted a knighthood from Queen Elizabeth II for his services.

Following some high-profile, troubled UK projects and the steady history of Olympic Games cost overruns (see the Sochi Olympics case in Chapter 8), the preparations for these games came under intense scrutiny. Armitt dealt with numerous external interests aiming to create “an atmosphere of calm,” allowing his team to focus on the task.

Described as a “stabilizing influence, giving confidence that the project could be delivered,” Armitt brought high credibility and a history of competence to his role in leading the development effort. Both politicians and executives involved in the multiple construction projects lauded his leadership. Ray O’Rourke, chairman and chief executive of Laing O’Rourke construction, was particularly complementary, noting that the success of London 2012 was a result of the careful leadership, continual presence, and understanding of the requirements needed to complete this enormous

Figure 4.1 Sir john Armitt

Source: Philip Wolmuth/Alamy

Introduction 117

undertaking. According to O’Rourke, perhaps Armitt’s biggest impact lay in his ability to manage the politics and inter- ests of numerous project stakeholders throughout the development of the Olympic sites.

When asked about the keys to making the Olympic project so successful, Armitt pointed to his approach to man- aging projects, honed through years of experience and overcoming multiple challenges. “What was different about the Olympics was the level of collaboration across all the projects. This came because of the recognition that to deliver these projects successfully, the client had a responsibility to provide the leadership,” he noted. Much of the project’s success comes from the clarity of the ODA’s vision, the leadership the ODA provided, and the way two years were set aside at the start for planning and preparation. Sir John says the credit belongs to the whole team. When he joined in 2007, construction was at an early stage, but the program “was in good shape,” he says.

Although Armitt is modest about his contribution, others associated with the London Games success are much more generous in pointing to his critical role in making the process come together. They note that, thanks to Armitt’s leadership in coordinating the work of hundreds of professionals, the project has consistently met targets throughout the building phase and set new benchmarks for sustainable construction and technical expertise. He was pivotal in all aspects of the Olympic and Paralympic Games infrastructure project, including finance, engineering, environment, management, and external relations, as well as acting as an ambassador for the project in explaining its complexities to the public. He is perhaps most proud of the long-term outcomes from the development: “The big opportunity was to take 600 acres of wasteland, a very heavily contaminated, rundown part of the east side of the city, and transform it into what is now going to be a new, magical place in London for the next 100 years.”

On the heels of his Olympic triumph, Sir John is not slowing down. He was appointed chair of a national commission to review how Britain could improve its poor record of project planning and delivery and assess the current state of the UK’s infrastructure, including transport, energy, telecommunications, and water infrastructure. For example, he recently warned about the dangers of energy brownouts throughout England if the needed construction of power plants contin- ues to be delayed due to political pressures. Finding major problems with a national infrastructure that was ranking 24th internationally in overall quality, Sir John has been an advocate of taking politicians out of the equation. For too long, he observed, politicians ducked the hard choices, delaying crucial decisions and repairs to the nation’s infrastructure because they were politically unpopular or lacked broad-based support. The Armitt review’s key recommendation is for a prop- erly independent body, along the lines of the Office of Budget Responsibility or the Committee on Climate Change, that would take the electoral cycle and political cowardice out of big infrastructure decisions.

“We need to find ministers who are prepared to say to their departments, ‘You are free to make mistakes. You are free to mentally allocate some of what you are doing to the 70/30 projects where, in fact, there is a good 30% chance that it will not work—but the 70% is worth going for, so let’s go for that. If it goes wrong, you won’t be hanged, but you will actually be praised for having a go. Because we are willing to take a risk, there will be certain things that will be successful.’” As he noted, innovation carries risk, but it can also deliver big wins.

“If you want to innovate, you have to accept that there are risks, and so you need flexibility in your budget,” states Armitt. “And you need to be open and honest about that.”1


Leadership is often recognized by its accomplishments. After cofounding Apple in 1976, Steven Jobs served as both a visible spokesperson for the corporation for many years, as well as the guid- ing hand behind many of its most significant product developments. Starting with his work in developing many of the technical and crowd-pleasing features of the Macintosh computer in 1984, Jobs always made his presence felt, often to the discomfort of other members of the organization who found his leadership style abrasive and demanding. In fact, less than two years after the suc- cess of the Macintosh, Jobs was fired from the company he started. His return as an older and wiser executive a decade later sparked a resurgence in a company that was nearly bankrupt, devoid of new ideas, and without a strong sense of strategic direction. At the time of his return, Apple’s market capitalization was $3 billion. However, over the following 15 years (until his death in 2011), Jobs spearheaded some of the most innovative new electronic consumer products ever conceived, revaluing the firm at over $350 billion. His impact on iconic products such as the iPhone, iPad, and iPod left him with a reputation as a visionary technology leader and helped make Apple one of the most profitable and valuable corporations in the world.

The situation Jeff Immelt faced as CEO of General Electric was very different. Taking over for the charismatic and highly successful Jack Welch, Immelt inherited a company that was quite liter- ally the face of American business, phenomenally successful, and perhaps the most valued brand in the world. Immelt set about recasting the corporation along his own vision. By most accounts, his record has been mixed. Stock prices have been sluggish and a number of acquisitions did not

118 Chapter 4 • Leadership and the Project Manager

pan out and had to be resold (notably, GE’s purchase of NBC Universal). On the other hand, he has been quick to lead the firm’s recovery from the Great Recession of 2009 and has been instrumental in rebuilding the company’s reputation as one of the most admired firms in the world. Coupled with his leadership of President Obama’s Council on Jobs and Competitiveness, Immelt remains a widely recognized head of a highly respected organization. By his own account, his tenure at GE has been challenging and demanding, but he also expects to leave the firm on solid footing when he retires.

Leadership is a difficult concept to examine because we all have our own definition of lead- ership, our own examples of leaders in actions, and our own beliefs about what makes leaders work. The topic of leadership has generated more than 30,000 articles and thousands of books. Although there are many definitions of leadership, one useful definition that we will employ in this chapter is that leadership is the ability to inspire confidence and support among the people who are needed to achieve organizational goals.2 For the project manager, leadership is the process by which she influences the project team to get the job done!

True leadership from the project manager has been shown time and again to be one of the most important characteristics in successful project management. The impact of good leader- ship is felt within the team and has an effect on other functional managers and important project stakeholders.3 In fact, project management has been viewed as one of the most “leader-intensive” undertakings within an organization.4

4.1 Leaders Versus Managers

Most leaders are quick to reject the idea that they were, by themselves, responsible for the suc- cesses attained or the important changes undertaken within their organizations. For them, leader- ship involves an awareness of a partnership, an active collaboration between the leader and the team. In project management, successful team leaders are often those who were best able to create the partnership attitude between themselves and their teams. As Peter Block5 notes, the idea of leadership as partnership is critical to project management because it highlights the important manner in which all leaders are ultimately dependent on their teams to achieve project goals. Four things are necessary to promote the partnership idea between the project manager and the team:

1. Exchange of purpose: Partnerships require that every worker be responsible for defining the project’s vision and goals. A steady dialogue between the project manager and team mem- bers can create a consistent and widely shared vision.

2. A right to say no: It is critical that all members of the project team feel they have the ability to disagree and to offer contrary positions. Supporting people’s right to voice their disagree- ments is a cornerstone of a partnership. Losing arguments is acceptable; losing the right to disagree is not.

3. Joint accountability: In a partnership, each member of the project team is responsible for the project’s outcomes and the current situation, whether it is positive or shows evidence of problems. The project is shared among multiple participants and the results of the project are also shared.

4. Absolute honesty: Partnerships demand authenticity. An authentic atmosphere promotes straightforwardness and honesty among all participants. Because we respect each team mem- ber’s role on the project, we make an implicit pact that all information, both good and bad, becomes community information. Just as honesty is a cornerstone of successful marriages, it is critical in project team relationships.

Leadership is distinguishable from other management roles in a number of ways. A manager is an individual who has received a title within the organization that permits her to plan, organize, direct, and control the behavior of others within her department or area of oversight. Although leadership may be part of the manager’s job, the other management roles are more administrative in nature. Leadership, on the other hand, is less about administration and more about interper- sonal relationships. Leadership involves inspiring, motivating, influencing, and changing behav- iors of others in pursuit of a common goal. Leaders embrace change; managers support the status quo. Leaders aim for effectiveness; managers aim for efficiency. Figure 4.2 illustrates some of the distinctions between typical management behavior and the kinds of processes with which leaders are engaged. Although leaders need to recognize the importance of managerial duties, it is often difficult for managers to recognize the nonstandard, interpersonal nature of leadership. However,

4.2 How the Project Manager Leads 119

this is not to say that leadership is merely an innate characteristic that some of us have and others do not. Most research and common experience seem to indicate that leadership behaviors can be taught. That is the good news: Leadership can be learned. And a number of properties and models of leadership are quite relevant for project managers.

Although we will use the term project manager throughout the chapter, we do so only because it has become the common designation for the head or leader of a project team. A much better description would be “project leader.” Successful project managers are successful project leaders.

This chapter will examine both the general concept of organizational leadership and the spe- cial conditions under which project managers are expected to operate. What is it about projects that make them a unique challenge to manage? Why is leadership such an integral role in success- ful project management? The more we are able to understand the dynamics of this concept, the better able we will be to effectively manage our implementation projects and train a future genera- tion of managers in the tasks and skills required for them to perform their jobs.

4.2 How tHe Project Manager Leads

The wide range of duties that a project manager is expected to take on covers everything from direct supervision to indirect influence, from managing “hard” technical details to controlling “soft” people issues, from developing detailed project plans and budgets to adjudicating team member quarrels and smoothing stakeholder concerns. In short, the project manager’s job encap- sulates, in many ways, the role of a mini-CEO, someone who is expected to manage holistically, focusing on the complete project management process from start to finish. In this section, we will examine a variety of the duties and roles that project managers must take on as they work to suc- cessfully manage their projects.

acquiring Project resources

Project resources refer to all personnel and material resources necessary to successfully accomplish project objectives. Many projects are underfunded in the concept stage. This lack of resource sup- port can occur for several reasons, including:

1. The project’s goals are deliberately vague. Sometimes a project is kicked off with its overall goals still somewhat “fluid.” Perhaps the project is a pure research effort in a laboratory or an information technology project designed to explore new possibilities for chip design or com- puter speed. Under circumstances such as these, companies sponsor projects with a deliber- ately “fuzzy” mandate, in order to allow the project team maximum flexibility.


demand respect

maintain the status quo focus on systems

strive for control

short-term view

focused on the bottom lineimitate

do things right

state their position


command respect

develop new processes focus on people

inspire trust

have long-term goal

focused on potentialoriginate

do the right thing

earn their position



Figure 4.2 Differences Between Managers and leaders

120 Chapter 4 • Leadership and the Project Manager

2. The project lacks a top management sponsor. As we will learn, having a project champion in the top management of the organization can be very helpful to project development, par- ticularly in gaining support for the project with sufficient resources. On the other hand, when no powerful sponsor emerges for the project, it may face underfunding compared to other projects competing for scarce company resources.

3. The project requirements were deliberately understated. It is not uncommon for project resource needs to be purposely understated at the outset in order to get them accepted by the organization. Contractors bidding on work for governmental agencies are known to some- times underbid to win these jobs and then renegotiate contracts after the fact or find other ways to increase profit margins later.

4. So many projects may be under development that there is simply not enough money to go around. A common reason for lack of resource support for a project is that the company is constantly developing so many projects that it cannot fund all of them adequately. Instead, the company adopts a “take it or leave it” attitude, presenting project managers with the option of either accepting insufficient funding or receiving none at all.

5. An attitude of distrust between top management and project managers. Sometimes projects receive low funding because top management is convinced that project managers are deliber- ately padding their estimates to gain excessive funding.

Regardless of the reasons for the lack of project resources, there is no doubt that many projects face extremely tight budgets and inadequate human resources.

Project managers, however, do have some options open to them as they seek to supplement their project’s resource support. If the resource problem is a personnel issue, they may seek alter- native avenues to solve the difficulty. For example, suppose that you were the project manager for an upgrade to an existing software package your company uses to control materials flow and warehousing in manufacturing. If trained programmers were simply unavailable to work on your upgrade project, you might seek to hire temporary contract employees. People with specialized skills such as programming can often be acquired on a short-term basis to fill gaps in the availability of in-house personnel to do the same assignments. The key point to remember is that recognizing and responding to resource needs is a critical function of project leadership.

Another common tactic project managers use in the face of resource shortfalls is to rely on negotiation or political tactics to influence top management to provide additional support. Because resources must often be negotiated with top management, clearly the ability to successfully negoti- ate and apply influence where the project manager has no direct authority is a critical skill. Again, leadership is best demonstrated by the skills a project manager uses to maintain the viability of the project, whether dealing with top management, clients, the project team, or other significant stakeholders.

Motivating and Building teams

The process of molding a diverse group of functional experts into a cohesive and collaborative team is not a challenge to be undertaken lightly. Team building and motivation present enor- mously complex hurdles, and dealing comfortably with human processes is not part of every man- ager’s background. For example, it is very common within engineering or other technical jobs for successful employees to be promoted to project manager. They typically become quickly adept at dealing with the technical challenges of project management but have a difficult time understand- ing and mastering the human challenges. Their background, training, education, and experiences have prepared them well for technical problems but have neglected the equally critical behavioral elements in successful project management.

In considering how to motivate individuals on our project teams, it is important to recognize that motivation ultimately comes from within each of us; it cannot be stimulated solely by an external presence. Each of us decides, based on the characteristics of our job, our work environ- ment, opportunities for advancement, coworkers, and so forth, whether we will become motivated to do the work we have been assigned. Does that imply that motivation is therefore outside of the influence of project managers? Yes and no. Yes, because motivation is an individual decision: We cannot make someone become motivated. On the other hand, as one career army officer puts it, “In the army, we can’t force people to do anything, but we can sure make them wish they had done it!” Underlying motivation is typically something that team members desire, whether it comes from a

4.2 How the Project Manager Leads 121

challenging work assignment, opportunity for recognition and advancement, or simply the desire to stay out of trouble. Successful project managers must recognize that one vital element in their job description is the ability to recognize talent, recruit it to the project team, mold a team of inter- active and collaborative workers, and apply motivational techniques as necessary.

Having a Vision and Fighting Fires

Successful project managers must operate on boundaries. The boundary dividing technical and behavioral problems is one example, and project managers need to be comfortable with both tasks. Another boundary is the distinction between being a strategic visionary and a day-to-day firefighter. Project managers work with conceptual plans, develop the project scope in line with organizational directives, and understand how their project is expected to fit into the company’s project portfolio. In addition, they are expected to keep their eyes firmly fixed on the ultimate prize: the completed project. In short, project managers must be able to think strategically and to consider the “big picture” for their projects. At the same time, however, crises and other project challenges that occur on a daily basis usually require project managers to make immediate, tacti- cal decisions, to solve current problems, and to be detail-oriented. Leaders are able to make the often daily transition from keeping an eye on the big picture to dealing with immediate, smaller problems that occur on a fairly regular basis.

One executive in a project organization highlighted this distinction very well. He stated, “We seek people who can see the forest for the trees but at the same time, are intimately familiar with the species of each variety of tree we grow. If one of those trees is sick, they have to know the best formula to fix it quickly.” His point was that a visionary who adopts an exclusively strategic view of the project will discover that he cannot deal with the day-to-day “fires” that keep cropping up. At the same time, someone who is too exclusively focused on dealing with the daily challenges may lose the ultimate perspective and forget the overall picture or the goals that define the project. The balance between strategic vision and firefighting represents a key boundary that successful project managers must become comfortable occupying.


Former president Ronald Reagan was labeled “The Great Communicator.” He displayed a seem- ingly natural and fluent ability to project his views clearly, to identify with his audience and shape his messages accordingly, and to not waver or contradict his basic themes. Project managers require the same facility of communication. In Chapter 2 we examined the role of stakeholder management in successful projects. These stakeholders can have a tremendous impact on the likelihood that a project will succeed or fail; consequently, it is absolutely critical to maintain strong contacts with all stakeholders throughout the project’s development. There is a common saying in project manage- ment regarding the importance of communication with your company’s top management: “If they know nothing of what you are doing, they assume you are doing nothing.” The message is clear: We must take serious steps to identify relevant stakeholders and establish and maintain communica- tions with them, not sporadically but continually, throughout the project’s development.

Negotiating is another crucial form of communicating. We will discuss the process of nego- tiation in detail in Chapter 6; however, it is important to recognize that project leaders must become adept at negotiating with a wide variety of stakeholders. Leaders negotiate with clients over critical project specifications (for example, a builder may negotiate with house buyers over the number of windows or the type of flooring that will be laid in the kitchen); they negotiate with key organizational members, such as department heads, for resources or budget money; they negotiate with suppliers for prices and delivery dates for materials. In fact, the total num- ber of ways in which project leaders routinely engage in negotiation is difficult to count. They understand that within many organizations, their authority and power to impose their will auto- cratically is limited. As a result, negotiation is typically a constant and necessary form of com- munication for effective project leaders.

Communicating also serves other valuable purposes. Project managers have been described as “mini billboards,” the most visible evidence of the status of their project. The ways in which project managers communicate, the messages they send (intentional or unintentional), and the manner in which they discuss their projects send powerful signals to other important stakehold- ers about the project. Whether through developing good meeting and presentation skills, a facility

122 Chapter 4 • Leadership and the Project Manager

for writing and speaking, or through informal networking, project managers must recognize the importance of communication and become adept at it.

One of the most critical means by which project managers can communicate is through their ability to run productive meetings. Meeting skills are important because project managers spend a large amount of time in meetings—meetings with team members, top management, clients, and other critical project stakeholders. Meetings serve a number of purposes for the project team, including:6

1. They define the project and the major team players. 2. They provide an opportunity to revise, update, and add to all participants’ knowledge base,

including facts, perceptions, experience, judgments, and other information pertinent to the project.

3. They assist team members in understanding how their individual efforts fit into the overall whole of the project as well as how they can each contribute to project success.

4. They help all stakeholders increase their commitment to the project through participation in the management process.

5. They provide a collective opportunity to discuss the project and decide on individual work assignments.

6. They provide visibility for the project manager’s role in managing the project.

As a result of the wide variety of uses meetings serve, the ability of project managers to become adept at running them in an efficient and productive manner is critical. Meetings are a key method for communicating project status, collectivizing the contributions of individual team members, developing a sense of unity and esprit de corps, and keeping all important project stakeholders up-to-date concerning the project status.7

Two forms of leadership behaviors are critical for effectively running project meetings. The first type of behavior is task-oriented; that is, it is intended to emphasize behaviors that contribute to completing project assignments, planning and scheduling activities and resources, and providing the necessary support and technical assistance. Task-oriented behavior seeks to get the job done. At the same time, effective project leaders are also concerned about group maintenance behavior. Group maintenance suggests that a project manager cannot act at the expense of concern for the team. Group maintenance behavior consists of supportive activities, including showing confidence and trust, acting friendly and supportive, working with subordinates to understand their problems, and recognizing their accomplishments. Group maintenance behavior increases cohesiveness, trust, and commitment, and it satisfies all team members’ needs for recognition and acceptance.

Table 4.1 identifies some of the critical task and group maintenance behaviors that occur in productive project meetings. Among the important task-oriented behaviors are structuring

taBLe 4.1 task and Group Maintenance Behaviors for Project Meetings8

task-oriented Behavior Specific outcome

1. Structuring process Guide and sequence discussion

2. Stimulating communication Increase information exchange

3. Clarifying communication Increase comprehension

4. Summarizing Check on understanding and assess progress

5. Testing consensus Check on agreement

Group Maintenance Behavior Specific outcome

1. Gatekeeping Increase and equalize participation

2. Harmonizing Reduce tension and hostility

3. Supporting Prevent withdrawal, encourage exchange

4. Setting standards Regulate behavior

5. Analyzing process Discover and resolve process problems

Source: Gary A. Yukl. Leadership in Organizations, 5th ed., p. 329. Copyright © 2002. Adapted by permission of Pearson Education, Inc., Upper Saddle River, NJ.

4.2 How the Project Manager Leads 123

the flow of discussion to ensure that a proper meeting agenda is followed, stimulating conversa- tion among all meeting participants, clarifying and summarizing decisions and perceptions, and testing consensus to identify points of agreement and discord. The project manager is the key to achieving effective task behaviors, particularly through a clear sense of timing and pacing.9 For example, pushing for consensus too quickly or stifling conversation and the free flow of ideas will be detrimental to the development of the project team and the outcomes of meetings. Likewise, continually stimulating conversation even after agreement has been achieved only serves to pro- long a meeting past the point where it is productive.

Among the group maintenance behaviors that effective project leaders need to consider in running meetings are gatekeeping to ensure equal participation, harmonizing to reduce ten- sion and promote team development, supporting by encouraging an exchange of views, regulat- ing behavior through setting standards, and identifying and resolving any “process” problems that cause meeting participants to feel uncomfortable, hurried, or defensive. Group maintenance behaviors are just as critical as those related to task and must be addressed as part of a successful meeting strategy. Taken together, task and group maintenance goals allow the project manager to gain the maximum benefit from meetings, which are so critical for project communication and form a constant demand on the project manager’s time.

Although running productive meetings is a critical skill for project leaders, they also need to recognize that face-to-face opportunities to communicate are not always possible. In situations where team members are geographically dispersed or heavily committed to other activities, find- ing regular times for progress meetings can be difficult. As we will discuss in Chapter 6 on virtual teams, modern international business often requires that meetings be conducted virtually, through platforms such as Skype or Adobe Connect. These electronic media and new technologies have shifted the manner in which many business communications are handled. That is, project leaders must possess the ability to handle modern electronic forms of communication, including e-mail, Twitter, and Facebook social networking sites, and emerging methods for online communication. For example, it is becoming more common for project leaders to set up social networking or group collaboration sites for their projects, including project team Facebook accounts, Twitter feeds, and Yammer collaboration spaces. These sites can create an atmosphere of teamwork and help pro- mote networking, while also maximizing the ways in which project leaders can communicate with members of their team. In short, although project team meetings remain one of the most useful methods for leaders to effectively communicate with their subordinates and other stakeholders, it is not a requirement that their meetings have to be face-to-face to be effective.

Table 4.2 paints a portrait of the roles project leaders play in project success by ranking the nine most important characteristics of effective project managers in order of importance. The data are based on a study of successful American project managers as perceived by project team members.10 Note that the most important is the willingness of the project manager to lead by example, to highlight the project’s goals, and to first commit to the challenge before calling upon other team members to make a similar commitment.

Equally interesting are findings related to the reasons why a project manager might be viewed as ineffective. These reasons include both personal quality flaws and organizational factors. Table 4.3

taBLe 4.2 characteristics of Project Managers Who lead

rank characteristics of an effective Project Manager

1 Leads by example

2 Visionary

3 Technically competent

4 Decisive

5 A good communicator

6 A good motivator

7 Stands up to top management when necessary

8 Supports team members

9 Encourages new ideas

124 Chapter 4 • Leadership and the Project Manager

Box 4.1

Project Management research in Brief

Leadership and Emotional Intelligence

An interesting perspective on leadership has emerged in recent years as greater levels of research have exam- ined the traits and abilities associated with effective project leadership. While characteristics such as technical skill, analytical ability, and intelligence are all considered important traits in project managers, an additional concept, the idea of emotional intelligence, has been suggested as a more meaningful measure of leadership effectiveness. Emotional intelligence refers to leaders’ ability to understand that effective leadership is part of the emotional and relational transaction between subordinates and themselves. There are five elements that characterize emotional intelligence: (1) self-awareness, (2) self-regulation, (3) motivation, (4) empathy, and (5) social skill. With these traits, a project manager can develop the kind of direct, supportive relationships with the project team members that are critical to creating and guiding an effective team.

Self-AwAreneSS. Self-awareness implies having a deep understanding of one’s own strengths and weak- nesses, ego needs, drives, and motives. To be self-aware means to have a clear perspective of one’s self; it does not mean to be excessively self-centered or self-involved. When I am self-aware, I am capable of interacting better with others because I understand how my feelings and attitudes are affecting my behavior.

Self-regulAtion. A key ability in successful leaders is their willingness to keep themselves under control. One way each of us practices self-control is our ability to think before we act—in effect, to suspend judgment. Effective leaders are those individuals who have developed self-regulation; that is, the ability to reflect on events, respond to them after careful consideration, and avoid the mistake of indulging in impulsive behavior.

MotivAtion. Effective project leaders are consistently highly motivated individuals. They are driven to achieve their maximum potential and they recognize that in order to be successful, they must also work with members of the project team to generate the maximum performance from each of them. There are two important traits of effective managers with regard to motivation: First, they are always looking for ways to keep score; that is, they like concrete or clear markers that demonstrate progress. Second, effective project managers consistently strive for greater and greater challenges.

eMpAthy. One important trait of successful project managers is their ability to recognize the differences in each of their subordinates, make allowances for those differences, and treat each team member in a manner that is designed to gain the maximum commitment from that person. empathy means the willingness to consider other team members’ feelings in the process of making an informed decision.

SociAl Skill. The final trait of emotional intelligence, social skill, refers to a person’s ability to manage relation- ships with others. Social skill is more than simple friendliness; it is friendliness with a purpose. Social skill is our ability to move people in a direction we think desirable. Among the offshoots of strong social skills are the manner in which we demonstrate persuasiveness, rapport, and building networks.

Emotional intelligence is a concept that reflects an important point: Many of the most critical project man- agement skills that define effective leadership are not related to technical prowess, native analytical ability, or IQ. Of much greater importance are self-management skills, as reflected in self-awareness, self-regulation, and motivation and relationship management skills, shown through our empathy and social abilities. Remember: Project management is first and foremost a people management challenge. Once we understand the role that leadership behaviors play in effective project management, we can better identify the ways in which we can use leadership to promote our projects.11

taBLe 4.3 characteristics of Project Managers Who Are Not leaders

Personal flaws Percentage organizational factors Percentage

Sets bad example 26.3% Lack of top management support 31.5%

Not self-assured 23.7 Resistance to change 18.4

Lacks technical expertise 19.7 Inconsistent reward system 13.2

Poor communicator 11.8 A reactive organization rather than a proactive, planning one 9.2

Poor motivator 6.6 Lack of resources 7.9

4.3 Traits of Effective Project Leaders 125

lists the most important personal flaws and the organizational factors that render a project man- ager  ineffective. These factors are rank-ordered according to the percentage of respondents who identified them.

4.3 traits oF eFFectiVe Project Leaders

A great deal of research on organizational leadership has been aimed at uncovering the traits that are specific to leaders. Because leaders are not the same thing as managers, they are found in all walks of life and occupying all levels of organizational hierarchies. A study that sought to uncover the traits that most managers believe leaders should possess is particularly illuminating. A large sample survey was used to ask a total of 2,615 managers within U.S. corporations what they con- sidered to be the most important characteristics of effective leaders.12

The results of this survey are intriguing. A significant majority of managers felt that the most important characteristic of superior leaders was basic honesty. They sought leaders who say what they mean and live up to their promises. In addition, they sought competence and intelligence, vision, inspiration, fairness, imagination, and dependability, to list a few of the most important characteristics. These traits offer an important starting point for better understanding how lead- ers operate and, more importantly, how the other members of the project team or organization expect them to operate. Clearly, the most important factors we seek in leaders are the dimensions of trust, strength of character, and the intelligence and competence to succeed. The expectation of success is also important; the majority of followers do not tag along after failing project managers for very long.

Research also has been done that is specifically related to project managers and the leadership traits necessary to be successful in this more specialized arena. Three studies in particular shed valuable light on the nature of the special demands that project managers face and the concomitant nature of the leadership characteristics they must develop. One study analyzed data from a number of sources and synthesized a set of factors that most effective project leaders shared in common.13 It identified five important characteristics for proficient project management: oral communication skills; influencing skills; intellectual capabilities; the ability to handle stress; and diverse manage- ment skills, including planning, delegation, and decision making. These findings correlate with the fact that most project managers do not have the capacity to exercise power that derives from formal positional authority; consequently, they are forced to develop effective influencing skills.

The second study also identified five characteristics closely associated with effective project team leaders:14

• Credibility: Is the project manager trustworthy and taken seriously by both the project team and the parent organization?

• Creative problem-solver: Is the project manager skilled at problem analysis and identification? • Tolerance for ambiguity: Is the project manager adversely affected by complex or ambiguous

(uncertain) situations? • Flexible management style: Is the project manager able to handle rapidly changing situations? • Effective communication skills: Is the project manager able to operate as the focal point for

communication from a variety of stakeholders?

The final study of necessary abilities for effective project managers collected data from 58 firms on their project management practices and the skills most important for project managers.15 The researchers found seven essential project manager abilities, including:

1. Organizing under conflict: Project managers need the abilities to delegate, manage their time, and handle conflict and criticism.

2. Experience: Having knowledge of project management and other organizational proce- dures, experience with technical challenges, and a background as a leader are helpful.

3. Decision making: Project managers require sound judgment, systematic analytical ability, and decision-making skills.

4. Productive creativity: This ability refers to the need for project managers to show creativ- ity; develop and implement innovative ideas; and challenge the old, established order.

5. Organizing with cooperation: Project managers must be willing to create a positive team atmosphere, demonstrate a willingness to learn, and engage in positive interpersonal contact.

126 Chapter 4 • Leadership and the Project Manager

6. Cooperative leadership: This skill refers to the project manager’s ability to motivate others, to cooperate, and to express ideas clearly.

7. Integrative thinking: Project managers need to be able to think analytically and to involve others in the decision-making process.

conclusions about Project Leaders

Given the wide-ranging views, it is important to note the commonalities across these studies and to draw some general conclusions about the nature of project leadership. The specific conclusions that have practical relevance to selecting and training effective project leaders suggest several themes, including:

• Effective project managers must be good communicators. • Project leaders must possess the flexibility to respond to uncertain or ambiguous situations

with a minimum of stress. • Strong project leaders work well with and through their project team. • Good project leaders are skilled at various influence tactics.

Although examining the traits of successful leaders, and specifically project leaders, is valu- able, it presents only part of the picture. One key to understanding leadership behavior is to focus on what leaders do rather than who they are.

Project Profile

Dr. elattuvalapil Sreedharan, india’s Project Management Guru

The capital of India, Delhi, is a city of amazing contrasts. Home to 17 million people, many living in abject poverty, the city boasts some of the country’s leading high-tech centers for industry and higher learning. Traffic snarls are notorious, and pollution levels are high as the city’s 7,500 buses slowly navigate crowded streets. Like other urban centers in India, Delhi desperately needs enhanced infrastructure and a commuter rail system. Unfortunately, India’s track record for large-capital projects is poor; there are many examples of projects that have run well over budget and behind schedule. A recent example highlights the continuing problems with managing infrastructure projects in India. Delhi launched

Figure 4.3 Dr. e. Sreedharan in one of the Delhi Metro tunnels

Source: Prakash Singh/AFP/Getty Images

4.4 Project Champions 127

a multiyear project to host the Commonwealth Games in the fall of 2010, a sporting event bringing together athletes from 71 territories and countries associated with the former British Empire. Unfortunately, problems with sanitation, inadequate construction, numerous delays, and poor planning left the country with a very visible black eye and rein- forced the popular view that large-scale infrastructure projects in India are, at best, a chancy venture.

Set against this backdrop, when the city announced its intention to develop a metro system, the rest of the coun- try was hesitant of its chances of success. After all, Calcutta’s metro had taken 22 years to create a mere 17-kilometer stretch, had overrun its budget by a multiple of 14, and had resulted in building collapses and multiple deaths from the construction. What chance did Delhi have of doing better? In fact, Delhi’s Metro system has been a huge success, and it has recently completed the second phase of the $2.3 billion project, with current daily ridership of 2.2 million passengers, earning the Metro organization nearly $900,000 a day in revenues. Not only that, the rail line planned for this phase, covering nearly 160 kilometers, with 132 operational stations, is running well ahead of schedule. So unex- pected was this circumstance that it led BusinessWeek magazine to label the project’s leader, Elattuvalapil Sreedharan, “a miracle worker.”

Sreedharan came to the project with an already enviable record of managing projects throughout India. In 1963, he had been given six months to repair the Pamban Bridge. Sreedharan, barely 30 at the time, took 46 days to finish the job. In the 1990s, he was in charge of Konkan Railway, a 760-kilometer stretch cutting across the Western Ghats mountain range. Nearly 150 bridges and 92 tunnels had to be built. He took seven years from the initial survey until the launch. Clearly, Mr. Sreedharan has determined the secrets to making projects work. So what has been the secret of Sreedharan’s success, especially in a land where so many before him have failed in similar ventures?

First, he says, is the importance of accountability. “One of the biggest impediments to the timely completion of infrastructure projects in India today is a lack of focus and accountability.” Poor performers are not held responsible for failure to hit their targets, so where is the incentive to be on time? According to Sreedharan, his organization took a different approach: “The organization’s mission and culture include clearly defined objectives and a vision, which was to complete the project on time and within the budget without causing inconvenience to the public.” Sreedharan also has almost an obsession with deadlines. Every officer in the Metro project keeps a digital board that shows the number of days left for the completion of the next target. Another critical element in his success has been meticulous advance planning. Sreedharan said, “All tenders (bids) from contractors are decided very fast, sometimes in 18 or 19 days. [I]t is essential to lay down the criteria for settling tenders clearly in advance.”

Finally, Sreedharan is adamant about transparency and constant communication with all project stakeholders. Under his watch, the project maintains open communication with all contractors, updating them about plans and hold- ing frequent meetings and workshops. A unique feature of the Delhi Metro project is that it has held nearly a hundred “community interaction programs” (CIPs), which are open forums during which local residents are given the chance to discuss aspects of the construction that could affect them. The CIP meetings are designed to allow advocacy groups, neighborhood organizations, and other stakeholders to share ideas, air grievances, and ask questions as the project moves forward. Regarding the questions from CIP meetings, Sreedharan comments, “Most of them are resolved on the spot, while necessary action and remedial measures are taken on the rest.” Sreedharan’s team has used this transpar- ency and open communication approach to allay the concerns of affected groups and spur their cooperation with the project rather than their antagonism.

The total project is designed to be rolled out in four phases, with a total coverage of 152 miles when finished. The final phase is due to be completed in 2020. The Metro project is currently in the midst of its phase three goals. In fact, work on the Metro is proceeding so smoothly that Sreedharan, now 80 years old, does not believe his presence is needed at the work site on a regular basis, knowing that the principles he established will continue to guide the work to its completion. Sreedharan retired in December 2011. He wanted to return to his ancestral village and live a placid life in Ponnani, on the southwestern Malabar Coast. As with so many successful people, retired life has not worked out the way he had planned. Kerala’s Chief Minister has already enlisted Sreedharan’s help in implementing the Kochi Metro project.

Sreedharan’s leadership principles echo beyond the challenge of infrastructure: “I believe that there are three basic qualities for a successful life,” he notes, “punctuality, integrity and good morals, and professional competence. The future of India will be in good hands if these qualities are assiduously nurtured by the youth of our nation.”16

4.4 Project cHaMPions

Dr. Thomas Simpson (not his real name) came back from a recent medical conference enthusiastic about an innovative technique that he felt sure was just right for his hospital. He had witnessed the use of information system technology that allowed doctors to link wirelessly with patient records, retrieve documentation, and place prescription orders online. With this system, a doctor could directly input symptoms and treatment protocols on a laptop in the patient’s room. The benefit of the new system was that it significantly upgraded the hospital’s approach to patient record keep- ing while providing the doctor with more immediate flexibility in treatment options.

128 Chapter 4 • Leadership and the Project Manager

As chief of the medical staff, Dr. Simpson had some influence in Grace Hospital, but he could not simply order the hospital to adopt the technology. Instead, over a period of six months, he worked tirelessly to promote the system, setting up information seminars with the software designers and question-and-answer sessions with the hospital’s administration and other impor- tant stakeholders. Eventually, his persistence paid off. The hospital adopted the technology and has been using it for the past two years. In spite of some start-up problems resulting from the need to transfer old paper records to the system, Grace Hospital now brags that it is “paper-record” free, and all because of Dr. Simpson’s efforts.

In this example, Dr. Simpson displayed all the qualities of a project champion. Champions, sometimes referred to as project sponsors, are well known both in the organizational theory lit- erature and within organizations themselves. A champion is an individual who “identifies with a new development (whether or not he made it), using all the weapons at his command, against the funded resistance of the organization. He functions as an entrepreneur within the organiza- tion, and since he does not have official authority to take unnecessary risks . . . he puts his job in the organization (and often his standing) on the line . . . . He (has) great energy and capacity to invite and withstand disapproval.”17

Champions possess some remarkable characteristics. First, it is assumed (in fact, almost expected) that champions will operate without the officially sanctioned approval of their organi- zations. Often they set themselves directly at odds with the established order or popular way of thinking. Standard operating procedures are anathema to champions, and they are usually unafraid of official disapproval. Second, champions have a true entrepreneurial talent for recognizing value in innovative ideas or products; they see things the typical organizational member does not. Third, champions are risk takers in every sense of the word. Their single-minded pursuit of truth in what- ever innovative form it may take often puts them at odds with entrenched bureaucrats and those who do not share their enthusiasm for a new product or idea.

Capturing the enthusiasm and fervor that champions have for their ideas is difficult. Tom Peters, best-selling author, describes champions as “fanatics” in their single-minded pursuit of their pet ideas. He states, “The people who are tenacious, committed champions are often a royal pain in the neck . . . . They must be fostered and nurtured—even when it hurts.”18 This statement captures the essence of the personality and impact of the champion: one who is at the same time an organizational gadfly and vitally important for project and organizational success.

champions—who are they?

Champions do not consistently occupy the same positions within organizations. Although senior managers often serve as champions, many members of the organization can play the role of implementation champion, with different systems or at different times with the same system implementation project. Among the most common specific types of champions are creative origi- nator, entrepreneur, godfather or sponsor, and project manager.19

creatiVe originator The creative originator is usually an engineer, scientist, or similar per- son who is the source of and driving force behind the idea. The fact that the individual who was behind the original development of the idea or technology can function as the project champion is hardly surprising. No one in the organization has more expertise or sense of vision where the new information system is concerned. Few others possess the technical or creative ability to develop the implementation effort through to fruition. Consequently, many organizations allow, and even actively encourage, the continued involvement of the scientist or engineer who originally devel- oped the idea upon which the project is based.

entrePreneur An entrepreneur is the person who adopts the idea or technology and actively works to sell the system throughout the organization, eventually pushing it to success. In many organizations, it is not possible, for a variety of reasons, for the creative originator or original project advocate to assume the role of champion. Often, scientists, technicians, and engineers are limited by their need to perform the specifically demarcated duties of their positions, and thereby precluded from becoming part of the project implementation team. In such situations, the indi- vidual who steps forward as the implementation champion is referred to as an organizational entre- preneur. The entrepreneur is an organizational member who recognizes the value of the original idea or technology and makes it a personal goal to gain its acceptance throughout the relevant

4.4 Project Champions 129

organizational units that would be employing it. Entrepreneurial champions are usually middle- to upper-level managers who may or may not have technical backgrounds. In addition to perform- ing their own duties within the organization, they are constantly on the lookout for innovative and useful ideas to develop.

“godFatHer” or sPonsor The project champion as godfather is a senior-level manager who does everything possible to promote the project, including obtaining the needed resources, coach- ing the project team when problems arise, calming the political waters, and protecting the project when necessary. A sponsor has elected to actively support acquisition and implementation of the new technology and to do everything in his power to facilitate this process. One of the most impor- tant functions of godfathers is to make it known throughout the organization that this project is under their personal guidance or protection. In addition to supplying this “protection,” the god- father engages in a variety of activities of a more substantial nature in helping the implementation effort succeed. Godfathers also use their influence to coach the team when problems arise in order to decrease the likelihood of political problems derailing the project.

Project Manager Another member of the organization who may play the role of champion is the project manager. At one time or another, almost every project manager has undertaken the role of champion. When one considers the definition of a project champion and the wide range of duties performed in that role, it becomes clear why the manager of the project is often in the position to engage in championing behaviors. Certainly, project managers are strongly identified with their projects, and to a degree their careers are directly tied to the successful completion of their projects. Project managers, however, may have limited effectiveness as champions if they do not possess a higher, organizationwide status that makes it possible for them to serve as project advocates at upper management levels. For example, a project manager may not have the authority to secure additional project resources or gain support throughout the larger organization.

what do champions do?

What exactly do champions do to aid the implementation process? Table 4.4 lists two sets of championing activities that were identified by one study through its survey of a sample of project managers.

taBLe 4.4 traditional and Nontraditional roles of Project champions

traditional Duties

Technical understanding Knowledge of the technical aspects involved in developing the project

Leadership Ability to provide leadership for the project team

Coordination and control Managing and controlling the activities of the team

Obtaining resources Gaining access to the necessary resources to ensure a smooth development process

Administrative Handling the important administrative side of the project

Nontraditional Duties

Cheerleader Providing the needed enthusiasm (spiritual driving force) for the team

Visionary Maintaining a clear sense of purpose and a firm idea of what is involved in creating the project

Politician Employing the necessary political tactics and networking to ensure broad acceptance and cooperation with the project

Risk taker Being willing to take calculated personal or career risks to support the project

Ambassador Maintaining good relations with all project stakeholders

Source: J. K. Pinto and D. P. Slevin. (1988). “The project champion: Key to implementation success,” Project Management Journal, 20(4): 15–20. Copyright © 1988 by Project Management Institute Publications. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

130 Chapter 4 • Leadership and the Project Manager

The first set of activities is commonly thought of as the “traditional” duties of managers. The champion can actively aid in the project development process by interpreting technical details, providing strong leadership, helping with project coordination and control, as well as supply- ing administrative help for the project team. It is important that the champion be familiar with the technical aspects of the project. Another important traditional activity of the project cham- pion is the procurement of necessary resources to enable team members to perform their tasks. Champions are often in an excellent position to make available a continual supply of logistical support for the project.

The second set of activities in which champions engage is referred to as the “nontraditional” side of management, which implies that these activities are not part of the usual roles identified in traditional management literature. That does not mean, however, that these activities are in any way unnecessary or eccentric. In fact, several champions have reported that these duties are just as important for project success as the more frequently identified, well-known requirements for successful management. Performing functions such as cheerleader, visionary, politician, risk taker, and ambassador is important for most project managers, and yet these roles tend to be deemphasized in literature, job specifications, and training programs. As one champion put it, “We can teach people those (traditional) skills easily enough, but experience is the best teacher for the other (nontraditional) duties. No one prepares you for the irrational side of this job. You have to pick it up as you go.”

In many organizations, the majority of a champion’s time is not engaged in performing the traditional side of project management duties, but rather is involved in the “nontraditional” activities. The champion is often the person with the vision, the cheerleader, or the driving force behind the project. Additionally, the champion is expected to take on the key political roles in attempting to play the right kinds of games, make the right contacts, and network with the neces- sary people to ensure a steady supply of resources necessary for the project to succeed. Finally, because champions, by definition, strongly identify with the project, much of their time is spent in networking with other organizational units, top management, and prospective clients (users) of the project. In this task, they take on an important ambassador/advocate role throughout the organization. In many cases, champions put their careers on the line to support and gain accep- tance of a new system and, as a result, become committed to aiding the project in every way pos- sible, through both traditional and nontraditional activities.

One question often asked is whether this type of behavior really plays an important role in successful project management. The answer is an emphatic “yes.” Aside from anecdotal and case study information, some compelling research studies have helped us better understand not only what champions do, but how important champions are for acquiring and gaining organizational acceptance of new projects.20 One study, for example, examined a series of new product devel- opments and start-ups at a variety of organizations.21 The relationship between the presence or absence of an identifiable organizational champion and the success of the project was studied for 45 new product development efforts. Of the 17 successful new product developments, all but one, or 94%, had a readily identifiable champion. These ventures were spearheaded by an individual that the majority of those involved in the project could point to and identify as that project’s spon- sor or champion. On the other hand, of the 28 projects that failed, only one was coupled with an identifiable project champion. Clearly, the results of this study point to the enormously important role that a champion can play in new product development.

How to Make a champion

All organizations differ in terms of the availability of individuals to take on the role of a project cham- pion. Although some organizations have a supply of enthusiastic personnel at all levels willing to serve as champions, the reality for most organizations is not nearly so upbeat. The fault, in this case, is not that these organizations have inadequate or unskilled people. Very often, the problem is that the organizations have failed to recognize the benefits to be derived from champions. Champions and a climate within which they can exist must be developed and nurtured by the organization.

Some important principles and options for organizations to recognize in the development and use of project champions include identify and encourage the emergence of champions, encour- age and reward risk takers, remember that champions are connected emotionally to their projects, and avoid tying champions too closely to traditional project management duties.22

4.5 The New Project Leadership 131

identiFy and encourage tHe eMergence oF cHaMPions In many companies, there are indi- viduals who demonstrate the enthusiasm and drive to champion new project ideas. It is important for these organizations to develop a culture that not only tolerates but actively promotes champi- ons. In many organizations, a creative originator who continually badgered upper management with a new project idea would likely offend some of the key top management team. However, for a firm to realize the full potential of its internal champions, it must create a culture of support in which champions feel they can work without excessive criticism or oversight.

encourage and reward risk takers Jack Welch, former CEO of General Electric, made it a personal crusade to actively encourage senior, middle, and even junior managers to take risks. His argu- ment was that innovation does not come without risk; if one cannot bear to take risks, one cannot inno- vate. The corollary to encouraging risk taking is to avoid the knee-jerk response of immediately seeking culprits and punishing them for project failures. Innovations are, by definition, risky ventures. They can result in tremendous payoffs, but they also have a very real possibility of failure. Organizations have to become more aware of the positive effects of encouraging individuals to take risks and assume championing roles in innovative projects. One project success will often pay for 10 project failures.

reMeMBer tHat cHaMPions are connected eMotionaLLy to tHeir Projects Champions bring a great deal of energy and emotional commitment to their project ideas; however, a potential downside of the use of powerful project champions is the fact that often they refuse to give up, even in the face of a genuine project failure. As a result, many companies keep pursuing “dogs” long after any hope for successful completion or commercial success is past. For example, Microsoft introduced their “Kin” cellphone in 2010 and marketed it particularly to teens and fans of social networking. The Kin was not a “smartphone,” it did not support apps or games, and it was expen- sive to operate. In spite of Microsoft’s best efforts, it quickly failed in the marketplace and was abandoned only two months after its introduction. Microsoft executive, Robbie Bach, mastermind behind the Kin device, left the company soon afterward.

don’t tie cHaMPions too tigHtLy to traditionaL Project ManageMent duties Project champions and project managers may be the same people, but often they are not. Many times classic champions, as Table 4.4 demonstrated, are more comfortable supporting a project through nontra- ditional activities. Because they tend to be visionaries, cheerleaders, and risk takers, they approach their goal with a single-minded strength of purpose and a sense of the overall design and strategy for the new technology. Rather than supporting the more routine aspects of project management, such as planning and scheduling, allocating resources, and handling the administrative details, the champions’ expertise and true value to the implementation process may be in their political connec- tions and contributions, that is, in employing their nontraditional management skills.

4.5 tHe new Project LeadersHiP

Project management requires us to harness our abilities to lead others. These skills may or (more likely) may not be innate; that is, for the majority of us, leadership is not something that we were born with. However, we know enough about the leadership challenge to recognize that leaders are as lead- ers do.23 The more we begin to recognize and practice appropriate leadership roles, the more naturally these activities will come to us. An article by one of the top writers on organizational leadership, Dr. Warren Bennis, summarizes four competencies that determine our success as project leaders:24

1. The new leader understands and practices the power of appreciation. These project leaders are connoisseurs of talent, more curators than creators. Appreciation derives from our abil- ity to recognize and reward the talent of others. Leaders may not be the best, most valuable, or most intelligent members of project teams. Their role is not to outshine others but to allow others to develop to their best potential.

2. The new leader keeps reminding people what’s important. This simple statement carries a powerful message for project managers. We need to remember that in pursuing a project, a host of problems, difficulties, annoyances, and technical and human challenges are likely to arise. Often numerous problems are uncovered during projects that were not apparent until after serious work began. Project managers must remember that one of their most important contributions is reminding people to keep their eyes fixed on the ultimate prize—in effect, continually reminding them what is important.

132 Chapter 4 • Leadership and the Project Manager

3. The new leader generates and sustains trust. The research by Kouzes and Posner cited earlier in this chapter contains a powerful message: The most important characteristic looked for in leaders is honesty.25 Leaders who generate trust and behave with authentic- ity, fairness, honesty, and caring will be successful in creating an environment in which the project team members strive to do their best. Trust plays a critical role in developing productive leader-member relationships.26 It is only by recognizing and applying trust- worthiness that we demonstrate the loyalty and commitment to our team members as individuals, that will bring out the best in them.

4. The new leader and the led are intimate allies. Earlier in this chapter we examined the con- cept of a partnership existing between the leader and followers. This point is important and should be emphasized in effective leadership behaviors. Project management leadership does not arise in order to control and dominate the project team, but as a natural method for sup- porting the team’s efforts. As we work to develop leadership abilities, it is important to first recognize the reasons why leadership is necessary for project success and then take the concrete steps needed to realize the vision of the project, something we can best do when we as leaders work in close harmony with our teams.

Box 4.2

Project Managers in Practice

Bill Mowery, CSC

“Project management, as a discipline, provides limitless opportunities across almost infinite combinations of industries, skills and alternatives and provides a career path that remains challenging and rewarding.” This statement comes from Bill Mowery, until recently, a Delivery Assurance Senior Manager in the Financial Services Group (FSG) of Computer Sciences Corporation (CSC).

Mowery’s job was a combination of project governance, working with the corporation’s Project Management Office (PMO), and special projects in support of strategic objectives. Project governance duties consist of monitoring and reporting on the status of the project portfolio of one of FSG’s divisions while pro- viding guidance on best practices and methods in project management. An important part of Mowery’s was as the “business architect” in support of FSG’s proprietary project tracking and reporting system. This system was developed to provide advanced capabilities in the automated collection and dissemination of project per- formance metrics. Mowery states, “Perhaps the most challenging part of my job pertained to ad hoc special projects that support the goals of both FSG and the corporate objectives of CSC as a whole. The opportunity to collaborate globally with my colleagues on a wide range of technology and business endeavors provided both challenge and variety in my career.”

Mowery’s career path into project management work seems to have been somewhat unintentional. After being trained in electronics and computer technology and earning an associate’s degree while serving in the U.S. Army, he began his civilian career in software engineering while pursuing undergraduate degrees in com- puter science and mathematics. As a contract programmer, he got his first taste of project management work, simply because he was the software contractor with the most seniority. This serendipitous introduction to this type of work led to a career that has kept him fascinated and engaged for the last 25 years. During this time, Mowery has worked in a variety of industries, including electronic product development, nuclear fuel process- ing, financial services, and material handling systems. One thing he has learned during his diverse career is that sound project management principles are critical regardless of the setting. As he points out, “While the industry and technology can change, the tenets of project management that lead to success remain a constant theme.”

Because of Mowery’s wealth of experience with running projects across so many settings over such an extended period, he served as a mentor for junior project managers in his organization, a role that he relished. “The aspect of my job I found most rewarding was the opportunity to collaborate and mentor within a large project management staff. When a project manager was faced with a unique challenge in project manage- ment and I could offer insight and advice that helped solve the problem, it provided a satisfying feeling that someone else didn’t have to learn something ‘the hard way.’”

When asked what advice he could offer to those interested in pursuing a career in project management, Mowery reflected, “The best advice that I can offer to anyone considering a career in project management is to have the patience of a rock, an empathetic personality, and a love of learning. Project management can be a complex field, and I often tell people that the more I learn, the less I know. This often confuses people, but simply put, the more I learn, the more I understand just how much more there is to know and discover in a fascinating and complex profession.”

4.5 The New Project Leadership 133

Figure 4.4 Bill Mowery, cSc

Source: Jeffrey Pinto/Pearson Education, Inc

Project Profile

the challenge of Managing internationally

As project management becomes an internationalized phenomenon, it is critical for successful leaders to recog- nize their management style and make necessary accommodations when dealing with project team members from other countries. The current generation of project managers is discovering that international work is not a mysterious or infrequent event; in fact, it is the everyday reality for project managers in many project-based orga- nizations. What are some of the important lessons that all project managers need to take to heart when working overseas? One list is offered by a successful project manager, Giancarlo Duranti. A native of Italy, Duranti has expe- rience leading teams in Brazil, Cuba, and Gambia. Among his suggestions for making the right leadership choices in foreign settings are:

1. Develop a detailed understanding of the environment. Educate yourself on the setting in which you will be work- ing by viewing documentaries and reading travel guides, tourist books, and even local newspapers. History is equally important: The better you understand the past of a particular culture, the sooner you can begin to understand team attitudes and perceptions.

2. Do not stereotype. It is easy to approach a foreign setting with preconceived notions about its people, culture, weather, and food. Without allowing ourselves to experience a setting for the “first time,” it is difficult to avoid form- ing easy and, ultimately, useless opinions.

3. Be genuinely interested in cultural differences. People are eager to share local and national traditions and, in turn, have a curiosity about yours. Demonstrating a real interest in their culture and sharing your own helps both sides to appreciate these differences rather than be separated by them.

4. Do not assume there is one way (yours) to communicate. Communication differences among cultures are profound. Remember, for example, that use of humor and ways of giving feedback, including correction, differ greatly among cultures. Learn to appreciate alternative means of exchanging information and to recognize what is “really” being said in various exchanges.

5. Listen actively and empathetically. Suspend judgment when listening and try to view each situation with some distance and perspective.27

134 Chapter 4 • Leadership and the Project Manager

4.6 Project ManageMent ProFessionaLisM

At the beginning of 2003, the U.S. Department of Energy (DOE) kicked off an internal initiative to create a project management career path within its organization. The launch followed similar moves by a variety of organizations, from firms as diverse as Ernst & Young (consulting) to NASA. Bruce Carnes at the Department of Energy explained the reasoning for this move:

Much of our work is accomplished through projects. In fact, our project managers are currently responsible for over 100 projects with a total value in excess of $20 billion, plus another $150 billion in environmental restoration work over the next several decades. It’s important for us to make sure that our project managers have the best skills possible, and that each person is treated as a critical DoE asset. Therefore, we need a cohesive career management plan to develop them, match their skills with assignments, track their performance, and reward them as appropriate.28

Embedded in this explanation are several important points that illustrate the growing professionalism of the project management discipline. Let’s consider them in turn.29

First, for more and more organizations, project work is becoming the standard. Projects are no longer simply additional and nonroutine components of organizational life; in many organiza- tions they are becoming the principal means by which the organizations accomplish their goals. Along with the increased recognition of the importance of using project management techniques comes the concomitant need to acquire, train, and maintain a cadre of project management profes- sionals who are dedicated to these work assignments.

Second, there is a critical need to upgrade the skills of those doing project work. It would be a mistake to continually apply organizational resources, particularly human resources, to projects without ensuring that they are learning and developing their project skills, and approaching these tasks with a solid foundation of knowledge. In short, one of the aspects of professionalism is to recognize that project management professionals are not an ad hoc feature of the organization, but a critical resource to be developed and maintained. Therefore, it is important to support these individuals as a resource that requires continual training and skill development.

Third, project management professionalism recognizes the need to create a clear career path for those who serve as project managers and support personnel. Historically, organizations “found” their project managers from among their line management staff and assigned them the responsi- bility to complete the project, always with the assumption that once the project was finished, the managers would return to their normal functional duties. In short, project management was a temporary assignment, and once it was completed, the manager was returned to “real” duties. In the new professionalism model, project management personnel view project work as a permanent career assignment, with managers moving from project to project, but always dedicated to this career path. Increasingly companies are officially distinguishing between their functional staff and their project management professionals, resisting the urge to move people back and forth between project assignments and functional duties.

This new professionalism mentality is typified by the experiences of NASA, particularly in the wake of the 1986 Challenger shuttle disaster. Following the lessons learned from that terrible event, NASA determined that there was a permanent need for a dedicated and embedded profes- sional project management group within the organization. Ed Hoffman, who serves as the director of NASA’s Academy of Program and Project Leadership, makes this point: “The NASA mind-set sees the project approach as the only way to do business. We are constantly charged with meeting cost and timeline challenges that require the cooperation of a variety of disciplines. Frankly, our folks would be confused by a functional approach.”30

What practical steps can organizations take to begin developing a core of project manage- ment professionals? Some of the suggested strategies include the following:

• Begin to match personalities to project work. Research suggests that certain personality types may be more accepting of project work than others.31 For example, outgoing, people-oriented individuals are felt to have a better likelihood of performing well on projects than quieter, more introverted people. Likewise, people with a greater capacity for working in an unstructured and dynamic setting are more attuned to project work than those who require structure and formal work rules. As a starting point, it may be useful to conduct some basic personality assessments of potential project resources to assess their psychological receptiveness to the work.

Summary 135

• Formalize the organization’s commitment to project work with training programs. There is little doubt that organizational members can recognize a firm’s commitment to projects by the firm’s willingness to support the training and development of personnel in the skills needed for them. For training to be effective, however, several elements are necessary. First, a corporatewide audit should be conducted to determine what critical skills are necessary for running projects. Second, the audit should determine the degree to which organizational members possess those skills. Third, where there are clear differences between the skill set needed and the skills available, project management training should first be targeted to reduce those gaps—in effect, bringing project management training into alignment with project management needs.

• Develop a reward system for project management that differentiates it from normal func- tional reward schedules. The types of rewards, whether promotions, bonuses, or other forms of recognition, available to project management personnel need to reflect the differences in the types of jobs they do compared to the work done by regular members of the organization. For example, in many project companies, performance bonuses are available for project team members but not for functional personnel. Likewise, raises or promotions in project firms are often based directly on the results of projects the team members have worked on. Thus, within the same organization, functional members may be promoted due to the amount of time they have been at one managerial level, while their project professional counterparts are promoted solely due to their accumulated performance on multiple projects.

• Identify a distinct career path for project professionals. One rather cynical project manager once noted to this author, “In our organization there are two career ladders. Unfortunately, only one of them has rungs!” His point was that excellent performance on projects did not earn individuals any rewards, particularly in terms of promotions. In his firm, projects were “a place where mediocre managers go to die.” Contrast this example with that of Bechtel Corporation, in which project management is viewed as a critical resource, project manage- ment personnel are carefully evaluated, and superior performance is rewarded. Most partic- ularly, Bechtel has a dual-track career path that allows successful project managers the same opportunities as other functional managers to move upward in the company.

Project professionalism recognizes that the enhanced interest in project management as a discipline has led to the need to create a resource pool of trained individuals for the organization to use. In short, we are seeing an example of supply and demand at work. As more and more organizations begin to apply project techniques in their operations, they will increase the need for sufficient, trained individuals to perform these tasks. One of the best sources of expertise in project management comes from inside these organizations, provided they take the necessary steps to nurture and foster an attitude of professionalism among their project management staff.

This chapter began with the proposition that project management is a “leader-intensive” undertaking; that is, few activities within organizations today depend more on the performance and commitment of a strong leader than do projects. Through exploration of the types of duties project managers must undertake, the characteristics of effective project leaders, the role of emo- tional intelligence in managing projects well, the concepts of project championing behavior, and the essence of the new project leadership, this chapter has painted a picture of the diverse and challenging duties that project managers are expected to undertake as they pursue project success. When we endeavor to develop our leadership skills to their highest potential, the challenge is sig- nificant but the payoffs are enormous.


1. Understand how project management is a “leader- intensive” profession. Project management is leader-intensive because the project manager, as the leader, plays a central role in the development of the project. The project manager is the conduit for infor- mation and communication flows, the principal planner and goal setter, the team developer, motiva- tor, and conflict resolver, and so forth. Without the

commitment of an energetic project leader, it is very unlikely the project will be successfully completed.

2. distinguish between the role of a manager and the characteristics of a leader. The manager’s role in an organization is characterized as one of positional authority. Managers receive titles that give them the right to exercise control over the behavior of others, they focus more on the administration and

136 Chapter 4 • Leadership and the Project Manager

organization of the project, and they seek efficiency and maintaining the status quo. Leaders focus on interpersonal relationships, developing and inspir- ing others with their vision of the project and the future. They embrace change, motivate others, com- municate by word and deed, and focus on the effec- tiveness of outcomes and long-term risk taking.

3. Understand the concept of emotional intelligence as it relates to how project managers lead. Five dimensions of emotional intelligence relate to project leadership: (1) self-awareness—one’s understanding of strengths and weaknesses that provides perspec- tive, (2) self-regulation—the ability to keep oneself under control by thinking before acting and sus- pending immediate judgment, (3) motivation—all successful leaders demonstrate first their own degree of motivation before they can inspire it in others, (4) empathy—the ability to recognize the differences in each subordinate and treat each team member in a way that is designed to gain the maximum com- mitment, and (5) social skill—friendliness with the purpose of moving people in a direction thought desirable.

4. recognize traits that are strongly linked to effec- tive project leadership. A number of leader- ship traits are strongly linked to effective project leadership, including (1) credibility or honesty, (2) problem-solving abilities, (3) tolerance for complex- ity and ambiguity, (4) flexibility in managing sub- ordinates, (5) communication skills, (6) creativity, (7) decision-making abilities, (8) experience, (9) the ability to work well through the project team, and (10) strong influence skills.

5. identify the key roles project champions play in project success. Champions are those individu- als within an organization who identify with a new project, using all the resources at their command to support it, even in the face of organizational resis- tance. Champions are risk takers because they are willing to work persistently in the face of resistance

or hostility to their idea from other members of the company. Research strongly supports the conten- tion that projects with an identifiable champion are more likely to be successful than those without. Among the traditional roles that champions play are those of technical understanding, leadership, coordination and control, obtaining resources, and administration. The nontraditional nature of the champion’s behavior includes engaging in activities such as being a cheerleader, project visionary, politi- cian, risk taker, and ambassador, all in support of the project.

6. recognize the principles that typify the new proj- ect leadership. Warren Bennis’s idea of the new project leadership is strongly based on relationship management through creating and maintaining a mutual commitment with each member of the proj- ect team. The four principles of the new project man- agement include (1) understanding and practicing the power of appreciation regarding each member of the project team, (2) continually reminding people of what is important through keeping focused on the “big picture,” (3) generating and sustaining trust with each member of the project team, and (4) recog- nizing that the leader and the led are natural allies, not opponents.

7. Understand the development of project manage- ment professionalism in the discipline. As proj- ect management has become increasingly popular, its success has led to the development of a core of professional project managers within many organi- zations. Recognizing the law of supply and demand, we see that as the demand for project management expertise continues to grow, the supply must keep pace. Professionalism recognizes the “institutional- ization” of projects and project management within organizations, both public and private. The prolif- eration of professional societies supporting project management is another indicator of the interest in the discipline.

Key Terms

Champion (p. 128) Creative originator (p. 128) Empathy (p. 124)

Entrepreneur (p. 128) Godfather or sponsor (p. 129)

Leadership (p. 118) Motivation (p. 120)

Professionalism (p. 134) Self-regulation (p. 124)

Discussion Questions

4.1 The chapter stressed the idea that project management is a “leader-intensive” undertaking. Discuss in what sense this statement is true.

4.2 How do the duties of project managers reinforce the role of leadership?

Case Study 4.2 137

4.3 What are some key differences between leaders and managers?

4.4 Discuss the concept of emotional intelligence as it relates to the duties of project managers. Why are the five ele- ments of emotional intelligence so critical to successful project management?

4.5 Consider the studies on trait theories in leadership. Of the characteristics that emerge as critical to effective leader- ship, which seem most critical for project managers? Why?

4.6 Consider the profile examples on project leaders Sir John Armitt and Dr. Sreedharan from the chapter. If you were to

summarize the leadership keys to their success in running projects, what actions or characteristics would you iden- tify as being critical? Why? What are the implications for you when you are given responsibility to run your own projects?

4.7 Why are project champions said to be better equipped to handle the “nontraditional” aspects of leadership?

4.8 Consider the discussion of the “new project leadership.” If you were asked to formulate a principle that could be ap- plied to project leadership, what would it be? Justify your answer.

CaSe STuDy 4.2 Finding the Emotional Intelligence to Be a Real Leader

Recently, Kathy Smith, a project manager for a large industrial construction organization, was assigned to oversee a multimillion-dollar chemical plant construc- tion project in Southeast Asia. Kathy had earned this assignment after completing a number of smaller con- struction assignments in North America over the past three years. This was her first overseas assignment and she was eager to make a good impression, particularly given the size and scope of the project. Successfully

completing this project would increase her visibility within the organization dramatically and earmark her as a candidate for upper management. Kathy had good project management skills; in particular, she was orga- nized and highly self-motivated. Team members at her last two project assignments used to joke that just try- ing to keep up with her was a full-time job.

Kathy wasted no time settling in to oversee the development of the chemical plant. Operating under


CaSe STuDy 4.1 In Search of Effective Project Managers

Pureswing Golf, Inc., manufactures and sells a full line of golf equipment, including clubs, golf balls, leisure- wear, and ancillary equipment (bags, rain gear, towels, etc.). The company competes in a highly competitive and fast-paced industry against better-known competitors, such as Nike, Taylor Made, Titleist, PING, Calloway, and Cleveland. Among the keys to success in this industry are the continuous introduction of new club models, innova- tive engineering and design, and speed to market. As a smaller company trying to stay abreast of stronger com- petitors, Pureswing places great emphasis on the project management process in order to remain profitable. At any time, the company will have more than 35 project teams developing new ideas across the entire product range.

Pureswing prefers to find promising engineers from within the organization and promote them to project manager. It feels that these individuals, hav- ing learned the company’s philosophy of competitive success, are best equipped to run new product intro- duction projects. For years, Pureswing relied on vol- unteers to move into project management, but lately it has realized that this ad hoc method for finding and

encouraging project managers is not sufficient. The failure rate for these project manager volunteers is over 40%, too high for a company of Pureswing’s size. With such steady turnover among the volunteers, suc- cessful managers have to pick up the slack—they often manage five or six projects simultaneously. Top man- agement, worried about burnout among these high- performing project managers, has decided that the firm must develop a coordinated program for finding new project managers, including creating a career path in project management within the organization.


1. Imagine you are a human resources professional at Pureswing who has been assigned to develop a program for recruiting new project managers. Design a job description for the position.

2. What qualities and personal characteristics support a higher likelihood of success as a project manager?

3. What qualities and personal characteristics would make it difficult to be a successful project manager?

138 Chapter 4 • Leadership and the Project Manager

her normal work approach, Kathy routinely required her staff and the senior members of the project team to work long hours, ignoring weekend breaks if impor- tant milestones were coming up, and generally adopt- ing a round the-clock work approach for the project. Unfortunately, in expecting her team, made up of local residents, to change their work habits to accommodate her expectations, Kathy completely misread the indi- viduals on her team. They bitterly resented her over- bearing style, unwillingness to consult them on key questions, and aloof nature. Rather than directly con- front her, however, team members began a campaign of passive resistance to her leadership. They would purposely drag their feet on important assignments or cite insurmountable problems when none, in fact, existed. Kathy’s standard response was to push herself and her project team harder, barraging subordinates with increasingly urgent communications demanding

faster performance. To her bewilderment, nothing seemed to work.

The project quickly became bogged down due to poor team performance and ended up costing the project organization large penalties for late delivery. Although Kathy had many traits that worked in her favor, she was seriously lacking in the ability to recog- nize the feelings and expectations of others and take them into consideration.


1. Discuss how Kathy lacked sufficient emotional intelligence to be effective in her new project manager assignment.

2. Of the various dimensions of emotional intelli- gence, which dimension(s) did she appear to lack most? What evidence can you cite to support this contention?

CaSe STuDy 4.3 Problems with John

John James has worked at one of the world’s largest aerospace firms for more than 15 years. He was hired into the division during the “Clinton years” when many people were being brought onto the payroll. John had not completed his engineering degree, so he was hired as a drafter. Most of the other people in his de- partment who were hired at the time had completed their degrees and therefore began careers as associate engineers. Over the years, John has progressed through the ranks to the classification of engineer. Many of the employees hired at the same time as John have ad- vanced more rapidly because the corporation recog- nized their engineering degrees as prerequisites for advancement. Years of service can be substituted, but a substantial number of years is required to offset the lack of a degree.

John began exhibiting signs of dissatisfaction with the corporation in general several years ago. He would openly vent his feelings against nearly everything the corporation was doing or trying to do. However, he did not complain about his specific situation. The complain- ing became progressively worse. John started to exhibit mood swings. He would be extremely productive at times (though still complaining) and then swing into periods of near zero productivity. During these times, John would openly surf the Internet for supplies for a new home repair project or for the most recent Dilbert comics. His fellow employees were hesitant to point out

to management when these episodes occurred. Most of the team members had been working together for the entire 15 years and had become close friends. This is why these nonproductive episodes of John’s were such a problem; no one on the team felt comfortable point- ing the problem out to higher management. As time progressed and John’s friends evolved into his manag- ers, while John remained at lower salary grades, John’s mood swings grew more dramatic and lasted longer.

During the most recent performance appraisal review process, John’s manager (a friend of his) included a paragraph concerning his “lack of concen- tration at times.” This was included because of numer- ous comments made by John’s peers. The issue could no longer be swept under the rug. John became irate at the review feedback and refused to acknowledge receipt of his performance appraisal. His attitude toward his teammates became extremely negative. He demanded to know who had spoken negatively about him, and his work output diminished to virtually nothing.

analysis of the Problem

Clearly John has not been happy. To understand why, the history of his employment at this company needs to be looked at in greater detail. The group of cowork- ers that started together 15 years earlier all had similar backgrounds and capabilities. A group of eight people

Case Study 4.3 139

were all about 22 years old and had just left college; John was the only exception to this pattern, as he still needed two years of schooling to finish his engineer- ing degree. All were single and making good money at their jobs. The difference in salary levels between an associate engineer and a draftsman was quite small. Figure 4.5 shows the salary grade classifications at this corporation.

This group played softball together every Wednesday, fished together on the weekends, and hunted elk for a week every winter. Lifelong bonds and friendships were formed. One by one, the group started to get married and begin families. They even took turns standing up for each other at the weddings. The wives and the children all became great friends, and the fish- ing trips were replaced with family backyard barbecues.

Meanwhile, things at work were going great. All of these friends and coworkers had very strong work ethics and above-average abilities. They all liked their work and did not mind working extra hours. This combination of effort and ability meant rewards and advancement for those involved. However, since John had not yet completed his degree as he had planned, his promotions were more difficult to achieve and did not occur as rapidly as those of his friends. The differ- ences in salary and responsibility started to expand at a rapid rate. John started to become less satisfied.

This large corporation was structured as a func- tional organization. All mechanical engineers reported to a functional department manager. This manager was aware of the situation and convinced John to go back for his degree during the evenings. Although John had good intentions, he never stayed with it long enough to complete his degree. As John’s friends advanced more quickly through the corporation, their cars and houses also became bigger and better. John’s wife pressured him to keep up with the others, and they also bought a bigger house. This move meant that John was living above his means and his financial security was threatened.

Until this point, John had justified in his mind that the corporation’s policies and his functional man- ager were the source of all of his problems. John would openly vent his anger about this manager. Then a dras- tic change took place in the corporation. The corpora- tion switched over to a project team environment and eliminated the functional management. This meant that John was now reporting directly to his friends.

Even though John now worked for his friends, company policy was still restrictive and the promotions did not come as fast as he hoped. The team leader gave John frequent cash spot awards and recognition in an attempt to motivate him. John’s ego would be soothed for a short time, but this did not address the real prob- lem. John wanted money, power, and respect, and he was not satisfied because those around him had more. Although he was good at what he did, he was not great at it. He did not appear to have the innate capability to develop into a leader through expert knowledge or per- sonality traits. Additionally, due to the lack of an engi- neering degree, he could not achieve power through time in grade. By now, John’s attitude had deteriorated to the point where it was disruptive to the team and something had to be done. The team leader had to help John, but he also had to look after the health of the team.

This detailed history is relevant because it helps to explain how John’s attitude slowly deteriorated over a period of time. At the start of his career, John was able to feel on a par with his peers. When every- one was young and basically equal, he knew that he had the respect of his friends and coworkers. This allowed John to enjoy a sense of self-esteem. As time passed and he gave up in his attempt at the college degree, he lost some of his self-esteem. As the gap grew between his friends’ positions in the company and his position in the company, he perceived that he lost the esteem of others. Finally, when he became overextended with the larger home, even his basic security was threatened. It is difficult to maintain a

Vice President


G 26 Engineering Manager

G 24 Senior Staff Engineer

G 22 Staff Engineer

G 20 Senior Engineer

G 18 Engineer

G 16 Associate Engineer

G 14 Senior Drafter

G 12 Drafter

G 10 Associate Drafter

Small Salary Gap

Large Salary Gap

Salaried Employees

Hourly Employees

Figure 4.5 Salary Grade classifications at this corporation


140 Chapter 4 • Leadership and the Project Manager

level of satisfaction in this situation. The problem was now distracting the team and starting to diminish their efforts and results. Because of the friendships, undue pressure was being placed on the team as they tried to protect John from the consequences of his actions.

The team leader had to try to resolve this prob- lem. The challenge was significant: The leader had to attempt to satisfy the individual’s needs, the group’s needs, and the task needs. When John’s individual needs could not be met, the group atmosphere and task completion suffered. It was time for the team leader to act decisively and approach upper management with a solution to the problem.

Possible Courses of action

The team leader put a lot of thought into his options. Because of the friendships and personal connections, he knew that he could not make this decision lightly. He decided to talk individually to the team members who were John’s close friends and then determine the best solution to present to upper management.

After talking with the team members, the team leader decided on the following list of potential options:

1. Do nothing. 2. Bypass company policy and promote John. 3. Talk John into going back to college. 4. Relocate John to a different project team. 5. Terminate John’s employment.

The option to do nothing would be the easiest way out for the team leader, but this would not solve any problems. This decision would be the equivalent of burying one’s head in the sand and hoping the prob- lem would go away by itself. Surprisingly, this was a common suggestion from the team members. There appeared to be a hope that the problem could be over- looked, as it had been in the past, and John would just accept the situation. With this option, the only person who would have to compromise was John.

The second option of bypassing company policy and promoting John to a higher level would be a very difficult sell to management. John was recently promoted to a salary grade 18 (his friends were now 24s and 26s). This promotion was achieved through the concerted efforts of his friends and the team leader. The chances of convincing management to approve another promo- tion so quickly were extremely low. Furthermore, if the team leader was successful at convincing management to promote John, what would the long-term benefits be? John would still not be at the same level as his friends and might not be satisfied for long. Chances were good that this would be only a temporary fix to the problem.

After the shine wore off the promotion, John would again believe that his efforts exceeded his rewards. It would be nice to believe that this solution would eliminate the problem, but history seemed to indicate otherwise.

The third option of trying to talk John into going back to college and finishing his engineering degree would be the best solution to the problem, but prob- ably the least likely to occur. If John could complete his degree, there would be no company policies that could obstruct his path. He would then be compet- ing on an even playing field. This would allow him to justifiably receive his advancement and recapture his self-esteem. If he did not receive the rewards that he felt he deserved, he would then have to look at his performance and improve on his weaknesses, not just fall back on the same old excuse. This solution would appear to put John back on the path to job satisfaction, but the problem with it was that it had been tried unsuc- cessfully several times before. Why would it be differ- ent this time? Should the corporation keep trying this approach knowing that failure would again lead to dis- satisfaction and produce a severe negative effect on the team? Although this third solution could produce the happy ending that everyone wants to see in a movie, it did not have a very high probability of success.

The fourth option of relocating John to a different team would be an attempt to break the ties of competi- tion that John felt with his friends and teammates. If this option were followed, John could start with a clean slate with a completely different team, and he would be allowed to save face with his friends. He could tell them of his many accomplishments and the great job that he is doing, while complaining that his “new” boss is holding him back. Although this could be considered “smoke and mirrors,” it might allow John the opportu- nity to look at himself in a new light. If he performed at his capabilities, he should be able to achieve the esteem of others and eventually his self-esteem. The team would consider this a victory because it would allow everyone to maintain the social relationship while washing their hands of the professional problems. This option offered the opportunity to make the situ- ation impersonal. It should be clear, however, that this solution would do nothing to resolve the true problem. Although it would allow John to focus his dissatisfac- tion on someone other than his friends and give him a fresh start to impress his new coworkers, who is to say that the problem would not simply resurface?

The fifth option, termination of employment, would be distasteful to all involved. Nothing to this point had indicated that John would deserve an action this severe. Also, since this option also would sever the social relationships for all involved and cause guilt for all of the remaining team members, resulting in team output deteriorating even further, it would be exercised

Internet Exercises 141

Internet exercises

only if other options failed and the situation deterio- rated to an unsafe condition for those involved.


1. As the team leader, you have weighed the pros and cons of the five options and prepared a pre- sentation to management on how to address this problem. What do you suggest?

2. Consider each of the options, and develop an argument to defend your position for each option.

3. What specific leadership behaviors mentioned in this chapter are most relevant to addressing and resolving the problems with John?

4.1 Identify an individual you would call a business leader. Search the Web for information on this individual. What pieces of information cause you to consider this individual a leader?

4.2 Go to the Web site and evaluate the role of the project leader in the Debian Project. What is it about the duties and background of the project leader that lets us view him as this project’s leader?

4.3 Knut Yrvin functions as the team leader for an initiative to replace proprietary operating systems with Linux-based technology in schools in Norway (the project is named “Skolelinux”). Read his interview at Articles/47510/. What clues do you find in this interview regarding his view of the job of project leader and how he leads projects?

4.4 Project champions can dramatically improve the chances of project success, but they can also have some negative ef- fects. For example, projects championed by a well-known organizational member are very difficult to kill, even when they are failing badly. Read the article on blind faith posted at taxonomyId=073. What does the article suggest are some of the pitfalls in excessive championing by highly placed members of an organization?

PMP certificAtion sAMPle QUestions

1. The project manager spends a great deal of her time communicating with project stakeholders. Which of the following represent an example of a stakeholder group for her project?

a. Top management b. Customers c. Project team members d. Functional group heads e. All are project stakeholders

2. Effective leadership involves all of the following, except: a. Managing oneself through personal time manage-

ment, stress management, and other activities b. Managing team members through motivation, del-

egation, supervision, and team building c. Maintaining tight control of all project resources

and providing information to team members only as needed

d. Employing and utilizing project champions where they can benefit the project

3. A project manager is meeting with his team for the first time and wants to create the right environment in which relationships develop positively. Which of the following guidelines should he consider employing to create an effective partnership with his team?

a. The right to say no b. Joint accountability c. Exchange of purpose d. Absolute honesty e. All are necessary to create a partnership

4. Joan is very motivated to create a positive project ex- perience for all her team members and is reflecting on some of the approaches she can take to employ lead- ership, as opposed to simply managing the process. Which of the following is an example of a leadership practice she can use?

a. Focus on plans and budgets b. Seek to maintain the status quo and promote order c. Energize people to overcome obstacles and show

personal initiative d. Maintain a short-term time frame and avoid un-

necessary risks

5. Frank has been learning about the effect of emotional intelligence on his ability to lead his project effectively. Which of the following is not an example of the kind of emotional intelligence that can help him perform better?

a. Self-awareness and self-regulation b. Motivation c. Social skills d. Results orientation (work to get the job done)

Answers: 1. e—Remember that stakeholders are defined as any group, either internal or external, that can affect the performance of the project; 2. c—Leadership requires allowing workers to have flexibility, providing them with all relevant information, and communicating project sta- tus and other pertinent information; 3. e—All of the above are necessary characteristics in promoting partnership be- tween the project manager and the team; 4. c—Energizing people to overcome obstacles is a critical component of leadership, as opposed to a philosophy of management; 5. d—Although a results orientation can be a useful ele- ment in a project leader’s skill set, it is not an example of emotional intelligence, which is often manifested through relationship building with others.

142 Chapter 4 • Leadership and the Project Manager


1. Hansford, M. (2014, February 18). “Daring to be dif- ferent: Sir John Armitt,” New Civil Engineer; Reina, P. (2013, January 28). “Sir John Armitt: Delivering the London Olympics Complex on Time, Under Budget, and Safely,” Engineering News-Record. http://enr.construc- delivered-on-time-under-budget-safely.asp; Osborne, A. (2013, September 5). “Take warring politicians out of infrastructure planning, says Olympics chief John Armitt,” The Telegraph. economics/10287504/Take-warring-politicians-out- of-infrastructure-planning-says-Olympics-chief-John- Armitt.html; Engineering and Physical Sciences Research Council. (2012, July 2). “EPSRC congratulates Sir John Armitt on inaugural major projects award.” www.epsrc. aspx; Bose, M. (2012, February 7). “ Sir John Armitt: We’ve made a magical place in London for the next 100 years.” made-a-magical-place-in-london-for-the-next-100-years/

2. Kim, W. C., and Mauborgne, R. A. (1992, July–August). “Parables of leadership,” Harvard Business Review, p. 123.

3. Posner, B. Z. (1987). “What it takes to be a good proj- ect manager,” Project Management Journal, 18(1): 51–54; Pinto, J. K., Thoms, P., Trailer, J., Palmer, T., and Govekar, M. (1998). Project Leadership: From Theory to Practice. Newtown Square, PA: Project Management Institute; Slevin, D. P., and Pinto, J. K. (1988). “Leadership, motiva- tion, and the project manager,” in Cleland, D. I., and King, W. R. (Eds.), Project Management Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp. 739–70; Geoghegan, L., and Dulewicz, V. (2008). “Do project managers’ compe- tencies contribute to project success?” Project Management Journal, 39(4): 58–67.

4. Pinto, J. K., and Kharbanda, O. P. (1997). Successful Project Managers. New York: Van Nostrand Reinhold.

5. Block, P. (1993). Stewardship: Choosing Service over Self- Interest. San Francisco, CA: Berrett-Koehler Publishers.

6. Verma, V. K. (1996). Human Resource Skills for the Project Manager. Newtown Square, PA: Project Management Institute.

7. Yukl, G. (2002). Leadership in Organizations, 5th ed. Upper Saddle River, NJ: Prentice Hall; Daft, R. L. (1999). Leadership Theory and Practice. Orlando, FL: Harcourt; Kouzes, J. M., and Posner, B. Z. (1995). The Leadership Challenge. San Francisco, CA: Jossey-Bass.

8. Yukl, G. (2002). Leadership in Organizations, 5th ed. Upper Saddle River, NJ: Prentice Hall.

9. Slevin, D. P. (1989). The Whole Manager. New York: AMACOM.

10. Zimmerer, T. W., and Yasin, M. M. (1998). “A leader- ship profile of American project managers,” Project Management Journal, 29(1): 31–38.

11. Goleman, D. (1998). “What makes a leader?” Harvard Business Review, 76(6): 92–102; Clarke, N. (2010). “Emotional intelligence and its relationship to transfor- mational leadership and key project manager compe- tences,” Project Management Journal, 41(2): 5–20.

12. Kouzes, J. M., and Posner, B. Z. (1995). The Leadership Challenge. San Francisco, CA: Jossey-Bass.

13. Pettersen, N. (1991). “What do we know about the effective project manager?” International Journal of Project Management, 9: 99–104. See also Javidan, M., and Dastmachian, A. (1993). “Assessing senior executives: The impact of context on their roles,” Journal of Applied Behavioral Science, 29, 328–42; DiMarco, N., Goodson, J. R., and Houser, H. F. (1989). “Situational leadership in the project/matrix environment,” Project Management Journal, 20(1): 11–18; Müller, R., and Turner, J. R. (2007). “Matching the project manager’s leadership style to proj- ect type,” International Journal of Project Management, 25: 21–32; Turner, J. R., and Müller, R. (2005). “The project manager’s leadership style as a success factor on projects: A literature review,” Project Management Journal, 36(2): 49–61.

14. Einsiedel, A. A. (1987). “Profile of effective project manag- ers,” Project Management Journal, 18(5): 51–56.

15. Medcof, J. W., Hauschildt, J., and Keim, G. (2000). “Realistic criteria for project manager selection and development,” Project Management Journal, 31(3): 23–32.

16. Hannon, E. (2010, September 27). “Problems fuel doubts about Commonwealth Games.” plates/story/story.php?storyId=13014949; Swanson, S. (2008). “Worldview: New Delhi,” PMNetwork, 22(12): 58–64; Lakshman, N. (2007, March 14). “The miracle-worker of the Delhi Metro.” money/2007/mar/14bspec.htm; www.muraleedharan. com/legends_sreedharan.html; Ramnath, N. S. (2012, June 2). “E Sreedharan: More than the metro man,” Forbes India. hip-award-2012/e-sreedharan-more-than-the-metro- man/33847/1

17. Schon, D. A. (1967). Technology and Change. New York: Delacorte; Maidique, M. A. (1980, Winter). “Entrepreneurs, champions, and technological innova- tion,” Sloan Management Review, 21: 59–76.

18. Peters, T. A. (1985, May 13). “A passion for excellence,” Fortune, pp. 47–50.

19. Meredith, J. A. (1986). “Strategic planning for factory auto- mation by the championing process,” IEEE Transactions on Engineering Management, EM-33(4): 229–32; Pinto, J. K., and Slevin, D. P. (1988). “The project champion: Key to implementation success,” Project Management Journal, 20(4): 15–20; Bryde, D. (2008). “Perceptions of the impact of project sponsorship practices on project success,” International Journal of Project Management, 26: 800–809; Wright, J. N. (1997). “Time and budget: The twin impera- tives of a project sponsor,” International Journal of Project Management, 15: 181–86.

20. Onsrud, H. J., and Pinto, J. K. (1993). “Evaluating cor- relates of GIS adoption success and the decision pro- cess of GIS acquisition,” Journal of the Urban and Regional Information Systems Association, 5: 18–39.

21. Chakrabarti, A. K. (1974). “The role of champion in prod- uct innovation,” California Management Review, XVII(2): 58–62.

Notes 143

22. Royer, I. (2003). “Why bad projects are so hard to kill,” Harvard Business Review, 81(2): 48–56; Pinto, J. K., and Slevin, D. P. (1988). “The project champion: Key to imple- mentation success,” Project Management Journal, 20(4): 15–20.

23. Thamhain, H. J. (1991). “Developing project management skills,” Project Management Journal, 22(3): 39–44; Pressman, R. (1998, January–February). “Fear of trying: The plight of rookie project managers,” IEEE Software, pp. 50–54.

24. Bennis, W. (2001). “The end of leadership: Exemplary lead- ership is impossible without full inclusion, initiatives, and cooperation of followers,” Organizational Dynamics, 28.

25. Kouzes, J. M., and Posner, B. Z. (1995). The Leadership Challenge. San Francisco, CA: Jossey-Bass.

26. Hartman, F. (2000). Don’t Park Your Brain Outside. Newtown Square, PA: Project Management Institute.

27. Silver, D. (2009). “Abroad spectrum,” PMNetwork, 23(1): 62–68.

28. Ayas, K. (1996). “Professional project management: A shift towards learning and a knowledge creating struc- ture,” International Journal of Project Management, 14: 131–36; Statement of Bruce Carnes, Chief Financial Officer, United States Department of Energy, Before the

Committee on Science—U.S. House of Representatives— on the FY 2003 Budget Request for the U.S. Department of Energy. (2002, February 13). See also openbook/0309089093/html/82-91.htm

29. Ayas, K. (1996), ibid. 30. Hoffman, E. J., Kinlaw, C. S., and Kinlaw, D. C. (2002).

“Developing superior project teams: A study of the char- acteristics of high performance in project teams,” in Slevin, D. P., Cleland, D. I., and Pinto, J. K. (Eds.), The Frontiers of Project Management Research. Newtown Square, PA: PMI, pp. 237–47; Kezbom, D. (1994). “Self-directed team and the changing role of the project manager.” Proceedings of the Internet 12th World Congress on Project Management, Oslo, pp. 589–93.

31. Wideman, R. M., and Shenhar, A. J. (2001). “Professional and personal development management: A practical approach to education and training,” in J. Knutson (Ed.), Project Management for Business Professionals: A Comprehensive Guide. New York: Wiley, pp. 353–83; Wideman, R. M. (1998). “Project teamwork, personality profiles and the population at large: Do we have enough of the right kind of people?” Presentation at the Project Management Institute’s Annual Seminar/Symposium, Long Beach, CA.


5 ■ ■ ■

Scope Management

Chapter Outline Project Profile

“We look like fools.”—Oregon’s Failed Rollout of Its Obamacare Web Site

introduction 5.1 concePtual develoPment

The Statement of Work Project Profile

Statements of Work: Then and Now The Project Charter

5.2 the ScoPe Statement The Work Breakdown Structure Purposes of the Work Breakdown Structure The Organization Breakdown Structure The Responsibility Assignment Matrix

5.3 Work authorization Project Profile

Defining a Project Work Package 5.4 ScoPe rePorting Project management reSearch in Brief

Information Technology (IT) Project “Death Marches”: What Is Happening Here?

5.5 control SyStemS Configuration Management

5.6 Project cloSeout Summary Key Terms Discussion Questions Problems Case Study 5.1 Boeing’s Virtual Fence Case Study 5.2 California’s High-Speed

Rail Project Case Study 5.3 Project Management

at Case Study 5.4 The Expeditionary Fighting Vehicle

Internet Exercises PMP Certification Sample Questions MS Project Exercises Appendix 5.1 Sample Project Charter Integrated Project—Developing the Work

Breakdown Structure Notes

Chapter Objectives After completing this chapter, you should be able to:

1. Understand the importance of scope management for project success. 2. Understand the significance of developing a scope statement. 3. Construct a Work Breakdown Structure for a project. 4. Develop a Responsibility Assignment Matrix for a project. 5. Describe the roles of changes and configuration management in assessing project scope.

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Develop Project Charter (PMBoK sec. 4.1) 2. Plan Scope Management (PMBoK sec. 5.1)

Project Profile 145

3. Collect Requirements (PMBoK sec. 5.2) 4. Define Scope (PMBoK sec. 5.3) 5. Create WBS (PMBoK sec. 5.4) 6. Validate Scope (PMBoK sec. 5.5) 7. Control Scope (PMBoK sec. 5.6)

Project Profile

case—“We look like fools.”—oregon’s failed rollout of its obamacare Web Site

Controversy has surrounded the Affordable Care Act (ACA), ever since it was proposed and passed through Congress without a single Republican vote. After two years of heated debate, the Act was signed into law by President Obama in 2010. Since then, the ACA, more commonly referred to as “Obamacare,” has been held up as a symbol of looming disaster and liberal overreach by its critics, while defenders argue that it represents a genuine effort to bring health care options to millions of Americans who could not afford coverage. Following its authorization and having survived numerous court challenges, parties on both sides of the debate waited for its effects to be felt as the federal and state health care exchanges came online, with a scheduled starting date of October 1, 2013. However, prior to the rollout, nu- merous warning signs were in evidence, from the late selection of prime contractors to develop the Web sites, to failed dress rehearsals, when the website crashed or could not be accessed. On October 1, the Obamacare exchanges and signup Web site ( failed spectacularly, with thousands of those attempting to sign up unable to access the system, frustratingly long waits to complete the registration, and innumerable crashes that required citizens to start the process over and over again. Records show that nationwide, only six people were able to register for health care coverage on day 1. So poorly did the system work in some states that, months after the rollout, a mere handful of people were able to sign up online. The government had to create phone-in centers as an alternative method for regis- tering for Obamacare. In fact, the initial history of Obamacare has given its critics plenty of ammunition with which to assail the administration and its dreadful management of the Obamacare exchange rollout.

Nowhere has this process been a more abject failure than in the state of Oregon. Oregon had attempted to de- velop its own Web site, Cover Oregon (as one of 14 states that opted to set up their own health care exchanges), since 2011. However, what started off as a popular and widely supported measure has turned into one of the worst examples of IT system implementation failure. Journalistic investigations have uncovered a series of missteps that included the per- fect storm of politics, poor planning, poor technological design, and contractors that were not up to the herculean task of setting up a health exchange. In the end, not one Oregonian was able to sign up through the exchange. Customers that ended up completing the task did so via paper enrollment. At the beginning of June 2014, Oregon announced that the 80,000 people who signed up for private insurance will have to reenroll in November via the federal exchange. The federal government will handle Oregon’s exchange as the state considers whether or not to overhaul its system, which it hopes would be ready in 2015. The state estimates that it lost over $250 million on its Cover Oregon Web site.

At the start of the project, Oregon selected Oracle as its primary contractor and hired the consulting firm Maximus to provide quality-control assessments. From its very first report, Maximus foretold nearly all of the major problems that would eventually doom Cover Oregon’s Web site to a catastrophic launch.

A Brief timeline of failure:

November 2011: With the clock ticking toward a launch deadline in two years, the project was already raising a number of red flags. Oracle had indicated its concern with the state’s decision to support an outdated software package and the project’s budget was looking questionable. On top of that, the consulting auditors termed the delivery date “function- ally impossible,” as it was established seemingly without any regard for technical estimates. At this point, the project was already $3 million over budget, the majority of the tasks were well behind schedule, and 75% of the project’s staff had not yet been hired. july 2012: By this point, over half the original budget has been spent (over $7 million) but the consultants label the Web site as technically poor. After several iterations of the software, the IT team has major concerns about the network’s security. Worse, the project managers for different teams have developed their own schedules and development roadmap, all without consulting each other or trying to integrate their efforts. The result is redun- dancies in performing some tasks and completely ignoring others. The consultants have begun to criticize the working relationships among the senior staff, warning that conflict and communication problems are only going to get worse. September 2012: With a little more than a year to the start-up, Cover Oregon is in trouble. The consultants offer a number of suggestions for getting the project back on track, including narrowing the scope, and begin developing contingency plans in case more problems emerge as the deadline nears. Because the project is not being tracked and controlled like a normal undertaking, it is difficult to identify the most pressing problems in order to devote more


146 Chapter 5 • Scope Management


The project scope is everything about a project—work content as well as expected outcomes. Project scope consists of naming all activities to be performed, the resources consumed, and the end products that result, including quality standards.2 Scope includes a project’s goals, constraints, and limitations. scope management is the function of controlling a project in terms of its goals and objectives through the processes of conceptual development, full definition, execution, and termination. It provides the foundation upon which all project work is based and is, therefore, the culmination of predevelopment planning. The process of scope manage- ment consists of several distinct activities, all based on creating a systematic set of plans for the upcoming project.

Emmitt Smith, former All-Pro running back for the Dallas Cowboys and member of the Pro Football Hall of Fame, attributes his remarkable success to his commitment to developing and working toward a series of personal goals. He likes to tell the story of his high school days and

resources and level of effort to fixing the serious gaps. Finally, the Web site is going through multiple changes, updates, and modifications and they are being signed off on without a formal review of the overall system. December 2012: Cover Oregon administrators brief a legislative oversight committee about their progress. So far, staff members have identified a total of 108 risks to the project. Meanwhile, the state’s contract with Oracle comes under review because the company is billing by the hour, rather than on the basis of completed work. Using this formulation, there is not much incentive for Oracle to finish the work quickly. May 2013: By this point, a critical milestone was to be met; that is, the handoff of the project Web site from the web developer organization to the insurance group, Cover Oregon. The two groups had been working simultaneously on parallel efforts for months now, so the handoff was expected to happen seamlessly. It didn’t; in fact, it was a disaster. The technical pieces of the Web site did not work and the site proved to be nearly impenetrable for users. This was the first clear evidence that the project was in serious problems from a technical perspective and coupled with ongoing cost and schedule overruns, highlighted the clear threat the project was facing. june 2013: June was supposed to be the point when systems testing showed that the project was fully operational. In fact, Cover Oregon personnel have finally come to the conclusion that not only will the site not be ready on time, but the only question left to answer is: just how bad will it be? More staff members are added to try and push as many fea- tures into the system as possible in time for the October 1 deadline. Meanwhile, Cover Oregon’s director, Rocky King, is already trying to protect his reputation by explaining the project’s problems in terms of its size and shortened timeframe to completion. September 2013: Seemingly out of nowhere, Rocky King delivered an upbeat project status presentation stating: “Bottom Line: We Are on Track to Launch.” In spite of the positive tone, no one associated with the project had any illusions about its real state. For example, Oracle’s efforts have been increasingly criticized to the point where Oregon was forced to hire a second consultant, Deloitte, to help with the site. Over the course of one week in September, 780 software tests were supposed to be run. In fact, they only managed to run 74 tests during this critical period leading up to the launch. Even worse, every single test failed. Even the relentlessly upbeat King recognizes the signs of imminent disaster. october 2013: The rollout has come and the site fails spectacularly. No one can access the system and in its inaugural version, Cover Oregon does not sign up a single resident. The finger pointing has begun and the state is threatening legal action against Oracle to recover some of its money. january 2014: Citing medical reasons, Rocky King resigns from his position as Director of Cover Oregon. He had been on medical leave since December and his resignation is the second for a high-profile individual associated with the project, following the earlier resignation of Carolyn Lawson, Chief Information Officer for the Oregon Health Authority.

After spending nearly a quarter of a billion dollars on its health care exchange site, Oregon was left with such a poorly developed and technically flawed exchange that it was forced to spend additional millions hiring temporary workers to sign up subscribers with a paper-based system. Left with the choice between hiring a new contractor and starting from scratch or opting for the federal Web site, Cover Oregon announced its intention of letting the federal govern- ment take over the system. This debacle is an example of poor project coordination and communication among key stakeholders, coupled with the risks of overpromising a new system, trying to coordinate massive systems to a fixed deadline, and failing to understand the complexities they were trying to address. While memory of specific elements of the Cover Oregon disaster may fade over time, its lessons deserve to be brought up every time a project of this sort is contemplated.1

Introduction 147

how they affected his future success. When Smith was a student at Escambia High in Pensacola, Florida, his football coach used to say, “It’s a dream until you write it down. Then it’s a goal.”

For successful projects, comprehensive planning can make all the difference. Until a detailed set of specifications is enumerated and recorded and a control plan is developed, a project is just a dream. In the most general sense, project planning seeks to define what needs to be done, by whom, and by what date, in order to fulfill assigned responsibility.3 Projects evolve onto an operational level, where they can begin to be developed, only after systematic planning—scope management—has occurred. The six main activities are (1) conceptual devel- opment, (2) the scope statement, (3) work authorization, (4) scope reporting, (5) control systems, and (6) project closeout.4 Each of these steps is key to comprehensive planning and project devel- opment (see Table 5.1).

This chapter will detail the key components of project scope management. The goal of scope management is maximum efficiency through the formation and execution of plans or systems that leave as little as possible to chance.

table 5.1 elements in Project Scope Management

1. conceptual Development

Problem statement Requirements gathering Information gathering Constraints Alternative analysis Project objectives Business case Statement of Work Project charter

2. Scope Statement Goal criteria Management plan Work Breakdown Structure Scope baseline Responsibility Assignment Matrix

3. Work Authorization Contractual requirements Valid consideration Contracted terms

4. Scope reporting Cost, schedule, technical performance status S curves Earned value Variance or exception reports

5. control Systems Configuration control Design control Trend monitoring Document control Acquisition control Specification control

6. Project closeout Historical records Postproject analysis

Financial closeout

148 Chapter 5 • Scope Management

5.1 conceptual development

conceptual development is the process that addresses project objectives by finding the best ways to meet them.5 To create an accurate sense of conceptual development for a project, the project management team must collect data and develop several pieces of information. Key steps in information development are:

• Problem or need statement: Scope management for a project begins with a statement of goals: why there is a need in search of a solution, what the underlying problem is, and what the project intends to do. For example, consider the following need statement from a fictitious county:

A 2014 report from the Maryland State Department of Health showed that the township of Freefield ranked among the worst in the state over a five-year average for infant mortality, low birth weight and premature births, late entry into prenatal care, unmarried parents, teen pregnancies, and poverty. A Clarion County health care focus group report identified patterns of poor communication between county families and doctors. There is a need for information gathering and dissemination on childbirth education opportunities, support service availability, preparation for new babies, and postpartum depression. The focus group indicated that the Freefield Public Library could be an important center for collecting this information and direct- ing new parents to resources and materials. To adequately meet this need, the library proposes a grant program to fund expanding their collections and programs in addition to linking the library with local primary care health providers and Freefield Memorial Hospital to serve expect- ant and postpartum mothers and their children.

• Requirements gathering: Requirements are the demands, needs, and specifications for a product (project outcome) as outlined by project stakeholders. It is the list of customer needs. Once a problem has been articulated (where we are now), the next step is to determine—in the words of the customer—where we wish to be. There can be many different types of requirements that an organization collects from a potential customer, including (1) product-related requirements—what features they desire the project to pos- sess, (2) quality requirements—the absolute minimum expectations for overall project quality, and (3) performance requirements—the expectations for how well the project performs or the standards it maintains. For example, in gathering requirements for a new automobile development project, Porsche might interview current and former owners of its high- performance cars to determine the expected levels of quality, price, and perfor- mance that customers expect. It is critical that during requirements gathering the project team does not overtly or unin- tentionally substitute their own interpretations for those of the customer. In other words, many project organizations, such as the IT industry, consider themselves the experts on what new software can do and the ways in which a customer would be expected to use it. In over- estimating their own role in requirements gathering, these organizations run the very real risk of creating systems that they imagine customers must have when, in reality, they are either not useful or are so overdesigned that customers only use them to the most limited degree. To guard against this situation, we discuss the critical nature of hearing the “voice of the customer” in requirements gathering in Chapter 11.

• Information gathering: Research to gather all relevant data for the project is the next step. A project can be effectively initiated only when the project manager has a clear understand- ing of the current state of affairs—specific target dates, alternative supplier options, degree of top management support for the project, and so forth. At any step along the way, project managers should take care that they have not limited their information search. Continuing the above example, suppose that as part of our information gathering, we identify five pro- spective funding sources in the Maryland Department of Health that would be good sources to access for grants. Further, our information search informs us that these grants are com- petitive and must be submitted by the end of the current calendar year, we can count on support from local political figures including our state representative and county commis- sioner, and so forth. All this information must be factored into the program proposal and used to shape it.

5.1 Conceptual Development 149

• Constraints: In light of the goal statement, project managers must understand any restric- tions that may affect project development. Time constraints, budget shrinkages, and client demands can all become serious constraints on project development. Referring back to the health grant example, some important constraints that could affect our ability to develop the grant application in time could be the need to find a medical professional to serve as the grant’s principal author, concern with statewide budgets and a withdrawal of support for community initiatives such as this one, and the need for a knowledgeable person within the library willing to serve as the primary collector of the prenatal and postnatal health care information.

• Alternative analysis: Problems usually offer alternative methods for solution. In project man- agement, alternative analysis consists of first clearly understanding the nature of the problem statement and then working to generate alternative solutions. This process serves two func- tions: It provides the team with a clearer understanding of the project’s characteristics, and it offers a choice of approaches for addressing how the project should be undertaken. It may be, as a result of alternative analysis, that an innovative or novel project development alterna- tive suggests itself. Alternative analysis prevents a firm from initiating a project without first conducting sufficient screening for more efficient or effective options.

• Project objectives: Conceptual development concludes with a clear statement of the final objectives for the project in terms of outputs, required resources, and timing. All steps in the conceptual development process work together as a system to ultimately affect the outcome. When each step is well done, the project objectives will logically follow from the analysis. In our health care example above, final objectives might include specific expectations, such as receiving a $100,000 grant to support collection services, printing costs, and holding informa- tion sessions and seminars with health care providers. These seminars would begin within a 90-day window from the administration of the grant. Library collections and subscriptions would be enhanced in this area by 25%. In this way, the problem or need statement is the catalyst that triggers a series of cascading steps from motive for the project through to its intended effects.

• Business case: The business case is the organization’s justification for committing to the proj- ect. Whenever a company intends to commit capital or its resources to a project, it should be clearly in support of a demonstrable business need. For example, it would make little sense for an IT organization like Google to develop a residential construction project unless a clear link could be made between the project and Google’s strategic goals and business activities. The project business case should (1) demonstrate the business need for a given project, (2) confirm the project is feasible before expending significant funding, (3) consider the strategic internal and external forces affecting the project (refer to the TOWS matrix discussion from Chapter 2), (4) assess and compare the costs (both monetary and nonmonetary) of choosing the project over other courses of action, and (5) provide time estimates for when we expect to be spending investment money on the project.

The business case is usually a carefully prepared document that highlights financial commitments, justification for undertaking the project, costs of doing the project, and more importantly, risks from not doing the project. For example, in the Maryland county example, we could build a business case that argued that because of the systemic problems with infant mortality in Fairfield Township, it is imperative not to delay action on this grant opportu- nity because failure to act will continue to result in higher levels of infant health problems in the county. A strong business case explores all feasible approaches to a given problem and enables business owners to select the option that best serves the organization. In short, the business case is the company’s (or project sponsor’s) best argument for undertaking a project.

Conceptual development begins with the process of reducing the project’s overall complexity to a more basic level. Project managers must set the stage for their projects as completely as possible by forming problem statements in which goals and objectives are clearly stated and easily understood by all team members.

Many projects that are initiated with less than a clear understanding of the problem the proj- ect seeks to address far exceed their initial budgets and schedules. At base level, this problem is due to the vague understanding among team members as to exactly what the project is attempt- ing to accomplish. For example, a recent information technology project was developed with the

150 Chapter 5 • Scope Management

vague goal of “improving billing and record-keeping operations” in a large insurance firm. The IT department interpreted that goal to develop a project that provided a complex solution requiring multiple interactive screens, costly user retraining, and the generation of voluminous reports. In fact, the organization simply wanted a streamlined link between the billing function and end- of-month reporting. Because the problem was articulated vaguely, the IT department created an expensive system that was unnecessarily complex. In reality, the optimal project solution begins with creating a reasonable and complete problem statement to establish the nature of the project, its purpose, and a set of concrete goals.

A complete understanding of the problem must be generated so that the projects themselves will be successful in serving the purpose for which they were created. A key part of the problem statement is the analysis of multiple alternatives. Locking in “one best” approach for solving a problem too early in a project can lead to failure downstream.

Also, to be effective, problem statements should be kept simple and based on clearly under- stood needs in search of solutions. For example, a clear project goal such as “improve the process- ing speed of the computer by 20%” is much better than a goal that charges a project team to “signif- icantly increase the performance of the computer.” A set of simple goals provides a reference point that the team can revisit when the inevitable problems occur over the course of project develop- ment. On the other hand, project goals that are vague or excessively optimistic—such as “improve corporate profitability while maintaining quality and efficiency of resources”—may sound good, but do not provide clear reference points for problem solving.

the Statement of Work

The impetus to begin a project is often the result of a statement of work. The statement of work (sow) is a detailed narrative description of the work required for a project.6 Useful SOWs contain information on the key objectives for the project, a brief and general description of the work to be performed, expected project outcomes, and any funding or schedule constraints. Typically, in the case of the latter, it is difficult to present schedule requirements past some “gross” level that may only include starting and ending dates, as well as any major milestones.

An SOW can be highly descriptive, as in the case of a U.S. Department of Defense Request for Proposal (RFP) for a new Army field communication device that is “no greater than 15 inches long by 15 inches wide by 9 inches deep, can weigh no more than 12 pounds, has a transmitting and receiv- ing range of 60 miles, must remain functional after being fully immersed in water for 30 minutes, and can sustain damage from being dropped at heights up to 25 feet.” On the other hand, an SOW can be relatively general, merely specifying final performance requirements without detailed specifics. The purpose of the SOW is to give the project organization and the project manager specific guidance on both work requirements as well as the types of end results sought once the project is completed.

A Statement of Work is an important component of conceptual development, as it identifies a need within the firm or an opportunity from an outside source, for example, the commercial mar- ket. Some elements in an effective SOW include:

1. Introduction and background—a brief history of the organization or introduction to the root needs that identified the need to initiate a project. Part of the introduction should be a prob- lem statement.

2. Technical description of the project—an analysis, in clear terms, of the envisioned technical capabilities of the project or technical challenges the project is intended to resolve.

3. Time line and milestones—a discussion of the anticipated time frame to completion and key project deliverables (outcomes).

A useful Statement of Work should clearly detail the expectations of the project client, the prob- lems the project is intended to correct or address, and the work required to complete the project.

For example, the U.S. Federal Geographic Data Committee recently developed an SOW for purchasing commercial services from government or private industry as an independent contractor. The Statement of Work contained the following components:

1. Background—describes the project in very general terms; discusses why the project is being pursued and how it relates to other projects. It includes, as necessary, a summary of statu- tory authority or applicable regulations and copies of background materials in addenda or references.

5.1 Conceptual Development 151

2. Objectives—provide a concise overview of the project and how the results or end products will be used.

3. Scope—covers the general scope of work the contractor will be performing. 4. Tasks or requirements—describe detailed work and management requirements, and also

spell out more precisely what is expected of the contractor in the performance of the work. 5. Selection criteria—identify objective standards of acceptable performance to be provided by

the contractor. 6. Deliverables or delivery schedule—describes what the contractor shall provide; identifies the

contractor’s responsibilities; and identifies any specialized expertise and services, training, and documentation that is needed. In addition, it clearly states the deliverables required, the schedule for delivery, the quantities, and to whom they should be delivered. Finally, it describes the delivery schedule in calendar days from the date of the award.

7. Security—states the appropriate security requirement, if necessary, for the work to be done. 8. Place of performance—specifies whether the work is to be performed at the government site

or the contractor’s site. 9. Period of performance—specifies the performance period for completion of the contracted


Notice how the Statement of Work moves from the general to the specific, first articulating the project’s background, including a brief history of the reasons the project is needed, and then iden- tifying the component tasks before moving to a more detailed discussion of each task objective and the approach necessary to accomplish it.7

A more detailed example of a generic statement of work is shown in Table 5.2. The SOW covers the critical elements in a project proposal, including description, deliverables, resource requirements, risks, expected outcomes, estimated time and cost constraints, and other pending issues. Table 5.2 can serve as a standard template for the construction of a reasonably detailed SOW for most projects.

The Statement of Work is important because it typically serves as the summary of the concep- tual development phase of the project plan. Once armed with the SOW, the project manager can begin moving from the general to the more specific, identifying the steps necessary to adequately respond to the detailed SOW.

the project charter

After a comprehensive SOW has been developed, many organizations establish a project charter. The project charter is defined as a document issued by the project initiator or sponsor that formally sanctions the existence of the project and authorizes the project manager to begin applying orga- nizational resources to project activities.8 In effect, a charter is created once the project supporters have done the needed “homework” to verify that there is a business case for the project, that they fully understand the elements of the project (as demonstrated through the SOW), and have applied more company-specific information for the project as it begins. The project charter demonstrates formal company approval of the project and that can only occur when all necessary information during conceptual development has been satisfied. For some organizations, the formal signoff of the SOW constitutes the project charter, while other organizations require that a separate document be created. An example of a project charter is shown in Appendix 5.1 at the end of the chapter.

Project Profile

Statements of Work: then and Now

Modern weapon systems have traditionally contained many more specifications and greater detailed SOWs than those of the past. Contrast the Army Signal Corps’ SOW for the Wright Brothers’ heavier-than-air flying machine in 1908 to the Air Force’s SOW for the Joint Strike Fighter, originally approved in 2001. The requirements in the 1908 SOW—for example, that the plane be easily taken apart for transport in Army wagons and be capable of being reassembled in an hour—and other contract conditions were specified on one page. The requirements section in the 2001 SOW for the Air Force Joint Strike Fighter is nearly 100 pages long with more than 300 paragraphs of requirements. Today’s SOWs are much more complex and require greater attention to detail, perhaps because the products are so much more complex, the equipment and materials are technically challenging, and legal requirements need much greater specification.9

152 Chapter 5 • Scope Management

table 5.2 elements in a comprehensive Statement of Work

Date Submitted

Revision Number

Project Name

Project Identification Number

SOW Prepared by:

1. Description and Scope a. Summary of work requested b. Background c. Description of major elements (deliverables) of the completed project d. Expected benefits e. Items not covered in scope f. Priorities assigned to each element in the project

2. Approach a. Major milestones/key events anticipated

Date Milestone/Event

b. Special standards or methodologies to be observed c. Impact on existing systems or projects d. Assumptions critical to the project e. Plans for status report updates f. Procedures for changes of scope or work effort

3. resource requirements a. Detailed plan/rationale for resource needs and assignments

Person Role and Rationale

b. Other material resource needs (hardware, software, materials, money, etc.) c. Expected commitments from other departments in support d. Concerns or alternatives related to staffing plan

4. risks and concerns a. Environmental risks b. Client expectation risks c. Competitive risks d. Risks in project development (technical) e. Project constraints f. Overall risk assessment g. Risk mitigation or abatement strategies

5.2 The Scope Statement 153

5.2 the Scope Statement

The scope statement, the heart of scope management, reflects a project team’s best efforts at creat- ing the documentation and approval of all important project parameters prior to proceeding to the development phase.10 Key steps in the scope statement process include:

• Establishing the project goal criteria. Goal criteria include cost, schedule, performance and deliverables, and key review and approval “gates” with important project stakeholders (par- ticularly the clients). deliverables are formally defined as “any measurable, tangible, verifi- able outcome, result, or item that must be produced to complete a project or part of a project.” The goal criteria serve as the key project constraints and targets around which the project team must labor.

• Developing the management plan for the project. The management plan consists of the orga- nizational structure for the project team, the policies and procedures under which team mem- bers will be expected to operate, their appropriate job descriptions, and a well-understood reporting structure for each member of the team. The management plan is essentially the project’s bureaucratic step that creates control systems to ensure that all team members know their roles, their responsibilities, and professional relationships.

• Establishing a Work Breakdown Structure. One of the most vital planning mechanisms, the work Breakdown structure (wBs), divides the project into its component substeps in order to begin establishing critical interrelationships among activities. Until a project has gone through WBS, it is impossible to determine the relationships among the various activities (which steps must precede others, which steps are independent of previous tasks, and so on). As we will see, accurate scheduling can begin only with an accurate and meaningful Work Breakdown Structure.

• Creating a scope baseline. The scope baseline is a document that provides a summary description of each component of the project’s goal, including basic budget and schedule information for each activity. Creation of the scope baseline is the final step in the process of systematically laying out all pre-work information, in which each subroutine of the project has been identified and given its control parameters of cost and schedule.

the Work breakdown Structure

When we are first given a project to complete, the task can seem very intimidating. How do we start? Where should we first direct our efforts? One of the best ways to begin is to recognize that any proj- ect is just a collection of a number of discrete steps, or activities, that together add up to the overall deliverable. There is no magic formula; projects get completed one step at a time, activity by activity.

According to the Project Management Body of Knowledge (PMBoK), a Work Breakdown Structure (WBS) is “a deliverable-oriented grouping of project elements which organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of a project component. Project components may be products or services.” To rephrase this PMBoK definition, the Work Breakdown Structure is a process that sets a project’s scope by breaking down its overall mission into a cohesive set of synchronous, increasingly specific tasks.11 The result is a comprehensive document reflecting this careful work.

5. Acceptance criteria a. Detailed acceptance process and criteria b. Testing/qualification approach c. Termination of project

6. estimated time and costs a. Estimated time to complete project work b. Estimated costs to complete project work c. Anticipated ongoing costs

7. outstanding issues

table 5.2 continued

154 Chapter 5 • Scope Management

The WBS delineates the individual building blocks that will construct the project. Visualize the WBS by imagining it as a method for breaking a project up into “bite-sized” pieces, each repre- senting a step necessary to complete the overall project plan. It can be challenging at the project’s start to envision all the elements or component tasks needed to realize the project’s success, but the effort to “drill down” into the various activities at the task level actually can reinforce the overall picture of the project.

Consider the simple case of a student team working together on a term paper and final presentation for a college seminar. One of the first steps in the process of completing the assign- ment consists of breaking the project down into a series of tasks, each of which can be allocated to a member or members of the student team. The overall project consisting of specific products— a final paper and presentation—becomes easier to manage by reducing it to a series of simpler levels, such as:

Task One: Refine topic Task Two: Assign library research responsibilities Task Three: Develop preliminary outline for paper and presentation Task Four: Assign team member to begin putting presentation together Task Five: Begin producing drafts of paper Task Six: Proofread and correct drafts Task Seven: Refine class presentation Task Eight: Turn in paper and make classroom presentation

A WBS could go much further in defining a project’s steps; this example is intended only to give you a sense of the logic employed to reduce an overall project to a series of meaningful action steps. You will see, in subsequent chapters, that those same action steps are later evaluated in order to estimate the amount of time necessary to complete them.

The logic of WBS is shown visually in Figure 5.1. Rather than giving a starting date and an end goal, the diagram provides a string of checkpoints along the way. These checkpoints address the specific steps in the project that naturally lead from the start to the logical conclusion. The WBS allows you to see both the trees and the forest, so you can recognize on many levels what it will take to create the completed project.

purposes of the Work breakdown Structure

The WBS serves six main purposes:12

1. It echoes project objectives. Given the mission of the project, a WBS identifies the main work activities that will be necessary to accomplish this goal or set of goals. What gets men- tioned in the WBS is what gets done on the project.

A. Goal Setting Using WBS

Project Start

Goal 1 Goal 2 Goal 3 Goal 4

Project CompletionCBA D

B. Goal Setting Without WBS

Project Start

Project Completion


FIgure 5.1 Goal Setting With and Without Work Breakdown Structures (WBS)

5.2 The Scope Statement 155

2. It is the organization chart for the project. Organization charts typically provide a way to understand the structure of the firm (who reports to whom, how communication flows evolve, who has responsibility for which department, and so forth). A WBS offers a similar logical structure for a project, identifying the key elements (tasks) that need attention, the various subtasks, and the logical flow from activity to activity.

3. It creates the logic for tracking costs, schedule, and performance specifications for each ele- ment in the project. All project activities identified in the WBS can be assigned their own budgets and performance expectations. This is the first step in establishing a comprehensive method for project control.

4. It may be used to communicate project status. Once tasks have been identified and respon- sibilities for achieving the task goals are set, you can determine which tasks are on track, which are critical and pending, and who is responsible for their status.

5. It may be used to improve overall project communication. The WBS not only dictates how to break the project into identifiable pieces, but it also shows how those pieces fit together in the overall scheme of development. As a result, team members become aware of how their component fits into the project, who is responsible for providing upstream work to them, and how their activities will affect later work. This structure improves motivation for com- munication within the project team, as members wish to make activity transitions as smooth as possible.

6. It demonstrates how the project will be controlled. The general structure of the project demonstrates the key focus that project control will take on. For example, is the project based on creating a deliverable (new product) or improving a process or service (functional effi- ciency) within the firm? Either way, the WBS gives logic to the control approach and the most appropriate control methods.

Let’s illustrate the WBS with a simplified example. Consider the case of a large, urban hospital that has made the decision to introduce an organizationwide information technology (IT) system for billing, accounts receivable, patient record keeping, personnel supervision, and the medical process control. The first step in launching this large installation project is to identify the important elements in introducing the technology. Here is a basic approach to identifying the deliverables in a project to install a new information system for an organization (see Figure 5.2).

Formal proposal

Identify IT location

Seek staff support

Identify user needs

Match IT to problems

Seek and hire consultant

Prepare proposal

Solicit RFPs from vendors

Pilot project

Contract for purchase

Adopt and use IT

FIgure 5.2 it installation flowchart

156 Chapter 5 • Scope Management

1. Match IT to organizational tasks and problems. 2. Identify IT user needs. 3. Prepare an informal proposal to top management (or other decision makers) for IT acquisition. 4. Seek and hire an IT consultant. 5. Seek staff and departmental support for the IT. 6. Identify the most appropriate location within the organization for the IT hardware to be

located. 7. Prepare a formal proposal for IT introduction. 8. Undertake a request for proposals (RFPs) from IT vendors. 9. Conduct a pilot project (or series of pilot projects using different IT options).

10. Enter a contract for purchase. 11. Adopt and use IT technology.

For simplicity’s sake, Figure 5.2 identifies only the first-level tasks involved in completing this project. Clearly, each of the 11 steps in the flowchart in Figure 5.2 has various supporting subtasks associated with it. For example, step 2, identifying IT user needs, might have three subtasks:

1. Interview potential users. 2. Develop presentation of IT benefits. 3. Gain user “buy-in” to the proposed system.

Figure 5.3 illustrates a partial WBS, showing a few of the tasks and subtasks. The logic across all identified tasks that need to be accomplished for the project is similar.

We do not stop here but continue to flesh out the WBS with additional information. Figure  5.4 depicts a more complete WBS to demonstrate the logic of breaking the project up into its compo- nent pieces. The 1.0 level shown in Figure 5.4 identifies the overall project. Underneath this level are the major deliverables (e.g., 1.2, 1.3, etc.) that support the completion of the project. Underneath these deliverables are the various “work packages” that must be completed to conclude the project deliverables.

work packages are defined as WBS elements of the project that are isolated for assignment to “work centers” for accomplishment.13 Just as atoms are the smallest, indivisible unit of matter in phys- ics, work packages are the smallest, indivisible components of a WBS. That is, work packages are the lowest level in the WBS, composed of short-duration tasks that have a defined beginning and end, are assigned costs, and consume some resources. For example, in the 1.2 level of identifying IT user needs (a deliverable), we need to perform three supporting activities: (1) interviewing potential users, (2) developing a presentation of IT benefits, and (3) gaining user “buy-in” to the system. This next level down (1.2.1, 1.2.2, etc.) represents the work packages that are necessary to complete the deliverable.

Sometimes confusion arises as to the distinction made between “work package” and “task,” as they relate to projects and the development of the WBS. In truth, for many organizations, the


1.2 1.3 1.4 1.5









FIgure 5.3 Partial Work Breakdown Structure

5.2 The Scope Statement 157

difference between the terms and their meanings is actually quite small; often they are used inter- changeably by the project management organization. The key is to be consistent in applying the terminology, so that it means the same thing within different parts of the organization, in regard to both technical and managerial resources.

Overall, for a generic project, the logic of hierarchy for WBS follows this form:

level WBS term Description

Level 1 (Highest) Project The overall project under development

Level 2 Deliverable The major project components

Level 3 Subdeliverable Supporting deliverables

Level 4 (Lowest) Work package Individual project activities

Breakdown Description WBS Code

IT Installation Project 1.0

Deliverable 1 Match IT to organizational tasks and problems 1.1

WP 1 Conduct problem analysis 1.1.1

WP 2 Develop information on IT technology 1.1.2

Deliverable 2 Identify IT user needs 1.2

WP 1 Interview potential users 1.2.1

WP 2 Develop presentation of IT benefits 1.2.2

WP 3 Gain user “buy-in” to system 1.2.3

Deliverable 3 Prepare informal proposal 1.3

WP 1 Develop cost/benefit information 1.3.1

WP 2 Gain top management support 1.3.2

Deliverable 4 Seek and hire IT consultant 1.4

WP 1 Delegate members as search committee 1.4.1

WP 2 Develop selection criteria 1.4.2

WP 3 Interview and select consultant 1.4.3

Deliverable 5 Seek staff and departmental support for IT 1.5

Deliverable 6 Identify the appropriate location for IT 1.6

WP 1 Consult with physical plant engineers 1.6.1

WP 2 Identify possible alternative sites 1.6.2

WP 3 Secure site approval 1.6.3

Deliverable 7 Prepare a formal proposal for IT introduction 1.7

Deliverable 8 Solicit RFPs from vendors 1.8 WP 1 Develop criteria for decision 1.8.1

WP 2 Contact appropriate vendors 1.8.2

WP 3 Select winner(s) and inform losers 1.8.3

Deliverable 9 Conduct a pilot project (or series of projects) 1.9

Deliverable 10 Enter a contract for purchase 1.10

Deliverable 11 Adopt and use IT technology 1.11

WP 1 Initiate employee training sessions 1.11.1

WP 2 Develop monitoring system for technical problems 1.11.2

FIgure 5.4 example of a Project WBS

158 Chapter 5 • Scope Management

Figure 5.4 provides an example of how project activities are broken down and identified at both the deliverable and the work package levels, as well as a brief description of each of these activities. The WBS in that figure also shows a numeric code assigned to each activity. A com- pany’s accounting function assigns wBs codes to each activity to allocate costs more precisely, to track the activities that are over or under budget, and to maintain financial control of the development process.

Sometimes it is necessary to differentiate between a subdeliverable, as identified in the hierarchical breakdown above, and work packages that are used to support and complete the subdeliverables. Typically, we think of subdeliverables as “rolled-up” summaries of the out- comes of two or more work packages. Unlike work packages, subdeliverables do not have a duration of their own, do not consume resources, and do not have direct assignable costs. Any resources or costs attached to a subdeliverable are simply the summary of all the work packages that support it.

Most organizations require that each deliverable (and usually each of the tasks or work packages contained within) come with descriptive documentation that supports the goals of the  project and can be examined as a basis for allowing approval and scheduling resource com- mitments. Figure 5.5 is a sample page from a task description document, intended to support

Project Task Description Form

Task Identification

Project Name: IT Installation Project Code: IS02 Project Manager: Williams

WP Name: Delegate members as search committee WP Code: 1.4.1 WP Owner: Susan Wilson

Deliverables: Assignment of personnel to IT vendor search committee Revision no.: 3 Date: 10/22/12 Previous revision: 2 (on file)

Resources Required

Labor Other Resources

Type Labor Days Type Quantity Cost

Systems manager 5 Software A 1 $15,000 Senior programmer 3 Facility N/A

Hardware technician 2 Equipment 1 $500 Procurement manager 3 Other N/A

Systems engineer 5

Required prerequisites: Deliverables 1.1, 1.2, and 1.3 (on file) Acceptance tests: None required Number of working days required to complete task: 5 Possible risk events, which may impair the successful completion of the task: __________________

TO BE COMPLETED AFTER SCHEDULING THE PROJECT: Earliest start on the task: 1/15/13 Earliest finish on the task: 2/15/13

Review meeting according to milestones: Name of milestone Deliverables Meeting date Participants

Identify IT user needs IT work requirements 8/31/12 Wilson, Boyd, Shaw

Design approval of the task: Task Owner: Sue Wilson Signature: _________________________ Date: _______ Customer contact: Stu Barnes Signature: _________________________ Date: _______ Project Manager: Bob Williams Signature: _________________________ Date: _______

FIgure 5.5 Project task Description

5.2 The Scope Statement 159

the project WBS outlined in Figure 5.4. Using work package 1.4.1, “Delegate members as search  committee,” a comprehensive control document can be prepared. When a supporting document functions as a project control device throughout the project’s development, it is not prepared in advance and is no longer used once that project step has been completed; in other words, it is a dynamic document. This document also specifies project review meetings for the particular work package as the project moves forward; the task description document must be completed, filed, and revisited as often as necessary to ensure that all relevant information is available.

MS Project allows us to create a WBS for a project. As we input each project task, we can assign a WBS code to it by using the WBS option under the Project heading. Figure 5.6 gives a sample screen shot of some of the activities identified in the hospital IT project example. Note that we have created a partial WBS for the IT project by using the MS Project WBS option, which also allows us to distinguish between “Project Level” headings, “Deliverable” headings, and “Work Package” headings.

the organization breakdown Structure

An additional benefit of creating a comprehensive WBS for a project is the ability to organize the work needed to be performed into cost control accounts that are assignable to various units engaged in performing project activities within the company. The outcome of organizing this material is the organization Breakdown structure (oBs). In short, the OBS allows companies to define the work to be accomplished and assign it to the owners of the work packages.14 The budgets for these activities are then directly assigned to the departmental accounts responsible for the project work.

Suppose, for example, that our IT project example required the committed resources of three departments—information technology, procurement, and human resources. We want to make certain that the various work packages and their costs are correctly assigned to the per- son and department responsible for their completion in order to ensure that our cost control for the project can remain accurate and up-to-date. Figure 5.7 shows a visual example of the intersection of our partial WBS with an OBS for our IT installation project. The three depart- ments within the organization are shown horizontally and the work packages underneath one of the deliverables are shown vertically. Notice that only some of the boxes used to illustrate the intersection are affected, suggesting that for some work packages multiple departments may be involved, each with its own cost accounts, while for other work packages there may be only one direct owner.

FIgure 5.6 Sample WBS Development Using MS Project 2013

Source: MS Project 2013 by Microsoft Corporation.

160 Chapter 5 • Scope Management

The benefit of using an OBS is that it allows for better initial linking of project activities and their budgets, either at a departmental level or, even more directly, on an individual-by-individual basis, as shown in Figure 5.8. In this case, the direct cost for each work package is assigned to a specific individual responsible for its completion. Figure 5.9 reconfigures the OBS to show the cost account rollups that can be done for each department responsible for a specific work package or project deliverable.

In managing projects, the main point to keep in mind about the scope statement is the need to spend adequate up-front time preparing schedules and budgets based on accurate and reasonable estimation. This estimation can be adequately performed only if project managers have worked through the WBS and project goals statements thoroughly. There are fewer surefire ways to create an atmosphere for project failure than to do a cursory and incomplete WBS. When steps are left out, ignored, or underestimated during the WBS phase, they are then underbudgeted or under- estimated in scheduling. The result is a project that will almost certainly have sliding schedules, rapidly inflating budgets, and confusion during the development phase. Much of this chaos can be avoided if the project manager spends enough time with her scope statement to ensure that there are no missing elements.

the responsibility assignment matrix

To identify team personnel who will be directly responsible for each task in the project’s devel- opment, a responsibility Assignment Matrix (rAM) is developed. (The RAM is sometimes referred to as a linear responsibility chart.) Although it is considered a separate document, the RAM is often developed in conjunction with the WBS for a project. Figure 5.10 illustrates a Responsibility Assignment Matrix for this chapter’s example project. Note that the matrix lists

IT Installation Project


1.3 1.4 1.5


1.4.1 1.4.2 1.4.3

Work Packages

Prepare proposal

Search committee

Develop criteria

Select consultant

Seek and hire IT consultant

Seek support for IT

Human Resources


Information Systems


Cost Account

Cost Account

Cost Account

Cost Account

Cost Account

Cost Account

FIgure 5.7 the intersection of the WBS and oBS

5.3 Work Authorization 161

WBS code Budget responsibility

1.0 $700,000 Bob Williams, IT Manager 1.1 5,000 Sharon Thomas

1.1.1 2,500 Sharon Thomas 1.1.2 2,500 Dave Barr

1.2 2,750 David LaCouture

1.2.1 1,000 David LaCouture 1.2.2 1,000 Kent Salfi 1.2.3 750 Ken Garrett

1.3 2,000 James Montgomery

1.3.1 2,000 James Montgomery 1.3.2 -0- Bob Williams

1.4 2,500 Susan Wilson

1.4.1 -0- Susan Wilson 1.4.2 1,500 Susan Wilson 1.4.3 1,000 Cynthia Thibodeau

1.5 -0- Ralph Spence

1.6 1,500 Terry Kaplan

1.6.1 -0- Kandra Ayotte 1.6.2 750 Terry Kaplan 1.6.3 750 Kandra Ayotte

1.7 2,000 Bob Williams

1.8 250 Beth Deppe

1.8.1 -0- Kent Salfi 1.8.2 250 James Montgomery 1.8.3 -0- Bob Williams

1.9 30,000 Debbie Morford

1.10 600,000 Bob Williams

1.11 54,000 David LaCouture

1.11.1 30,000 David LaCouture 1.11.2 24,000 Kandra Ayotte

FIgure 5.8 cost and Personnel Assignments

not only the member of the project team responsible for each activity, but also the other signifi- cant members of the team at each stage, organized according to how that activity requires their support. The RAM identifies where each person can go for task support, who should be notified of the task completion status at each stage, and any sign-off requirements. This tool provides a clear linkage among all project team members and combats the danger of a potential communi- cation vacuum in which project team members perform their own tasks without updating others on the project team.

5.3 Work authorIzatIon

This stage in scope management naturally follows the two previous steps. Once the scope definition, planning documents, management plans, and other contractual documents have been prepared and approved, the work authorization step gives the formal “go ahead” to commence with the project. Many times work authorization consists of the formal sign-off on all project

162 Chapter 5 • Scope Management

Lead Project Personnel

Bob IT

David IT

Susan HR

Beth Procurement

Terry LegalTask

& Code Deliverable

Match IT to Org. Tasks— 1.1

Problem Analysis –1.1.1

Develop info on IT technology –1.1.2

Identify IT user needs— 1.2

Interview potential users –1.2.1

Develop presentation –1.2.2

Gain user “buy-in” –1.2.3

Prepare proposal— 1.3

Develop cost/ benefit info –1.3.1


Responsible Support


James Engineering

FIgure 5.10 responsibility Assignment Matrix

IT Installation Project


1.3 1.4 1.5


1.4.1 1.4.2 1.4.3

Work Packages

Prepare proposal

Search committee

Develop criteria

Select consultant

Seek and hire IT consultant

Seek support for IT

Human Resources


Information Systems











FIgure 5.9 cost Account rollup Using oBS

5.3 Work Authorization 163

plans, including detailed specifications for project delivery. In cases of projects developed for external clients, work authorization typically addresses contractual obligations; for internal cli- ents, it means establishing an audit trail by linking all budget and resource requirements to the formal cost accounting system of the organization. Numerous components of contractual obliga- tions between project organizations and clients can exist, but most contractual documentation possesses some key identifiable features:16

• Contractual requirements. All projects are promised in terms of the specific functionality, or performance criteria, they will meet. This raises the questions: What is the definition accepted by both parties of “specific performance”? Are the terms of performance clearly understood and identified by both parties?

• Valid consideration. What items are voluntarily promised in exchange for a reciprocal com- mitment by another party? Does the work authorization contract make clear the commit- ments agreed to by both parties?

Project Profile

Defining a Project Work Package

Remember these seven important points about defining a project work package:15

1. The work package typically forms the lowest level in the WBS. Although some projects may employ the term subtask, the majority leave work package–level activities as the most basic WBS step.

2. A work package has a deliverable result. Each work package should have its own outcome. One work package does not summarize or modify another. Together, work packages identify all the work that must be contributed to complete the project.

3. A work package has one owner assigned—a project team member who will be most responsible for that package’s completion. Although other team members can provide support as needed, only one person should be directly answerable for the work package.

4. A work package may be considered by its owner as a project in itself. If we adopt the notion that all work packages, because they are of finite length and budget and have a specific deliverable, can be considered miniature projects, each package owner can view his activities as a microproject.

5. A work package may include several milestones. A milestone is defined as a significant event in the project. Depending on the size and complexity of a project work package, it may contain a number of significant checkpoints or milestones that determine its progress toward completion.

6. A work package should fit organizational procedures and culture. Tasks undertaken to support project outcomes should be in accord with the overall cultural norms of the project organization. Performing a work package should never lead a team member to violate company policy (either codified or implicit); that is, assigned activities must pass both relevant legal standards for ethical behavior and also adhere to the accepted behaviors and procedures of the organization.

7. The optimal size of a work package may be expressed in terms of labor hours, calendar time, cost, report period, and risks. All work packages should be capable of being tracked, meaning that they must be structured to allow the project manager to monitor their progress. Progress is usually a measurable concept, delineated by metrics such as time and cost.

In developing a project’s RAM, managers must consider the relationships between the project team and the rest of the organization as well as those within the project team. Within an organization and without it, actions of department heads and external functional managers can affect how members of a project team perform their jobs. Thus, a detailed RAM can help project managers negotiate with functional managers for resources, particularly through detailing the necessity of including various team members on the project.

Working through a RAM allows the project manager to determine how best to team people for maximum efficiency. In developing the document, a project manager has a natural opportunity to assess team members’ strengths, weaknesses, work commitments, and availability. Many firms spend a significant amount of money developing and using software to accurately track project activities, but not nearly as many devote time to tracking the ongoing inter- action among project team members. A RAM allows project managers to establish a method for coordinating the work activities of team members, realizing the efficiencies that take place as all team members provide support, notification, and approval for each other’s project responsibilities.

164 Chapter 5 • Scope Management

• Contracted terms. What are excusable delays, allowable costs, and statements of liqui- dated damages in the case of nonperformance? What are the criteria for inspection? Who has responsibility for correction of defects? What steps are necessary to resolve disputes? Contracted terms typically have clear legal meanings that encourage both parties to com- municate efficiently.

A number of contractual arrangements can serve to codify the relationship between a project organization and a customer. It is beyond the purview of this chapter to explore the various forms of contracts and legal recourse in great detail, but some standard contractual arrangements should be considered when managing the project scope. From the perspective of the project organization, the most common contracts range from lump-sum or turnkey con- tracts, in which the project organization assumes all responsibility for successful performance, to cost-plus contracts, which fix the company’s profit for a project in advance. We will discuss the latter first.

Sometimes it is nearly impossible to determine the likely cost for a project in advance. For example, the sheer technical challenges involved in putting a man on the moon, drilling a tunnel under the English Channel, or developing the Strategic Defense Initiative make the process of estimating project costs extremely difficult. In these cases, it is common for project companies to enter into a cost-plus contract that guarantees them a certain profit, regardless of the cost overruns that may occur during the project development. Cost-plus contracts can be abused; in fact, there have been notorious examples of huge overruns in governmental con- tracts because the lack of oversight resulted in systematic abuses. However, cost-plus contracts can minimize the risk that a company would incur if it were to undertake a highly technical project with the potential for uncertain outcomes, provided that both parties understand the terms of the agreement, the project organization acts with due diligence, and there is a final audit of the project books.

At the opposite extreme are lump-sum (sometimes referred to as turnkey) contracts in which the contractor is required to perform all work at an initially negotiated price. Lump-sum contracting works best when the parameters of the project are clearly understood by both sides (e.g., a residential construction project) and the attendant costs of the project can be estimated with some level of sophistication. In lump-sum contracts, initial cost estimation is critical; if the original estimate is too low and the contractor encounters unforeseen problems, the project’s profit may be reduced or even disappear. The advantage of the lump-sum contract to the cus- tomer is that the selected project contractor has accepted the majority of the risk in the project. On the other hand, because cost estimation is so crucial, it is common for initial estimates in lump-sum contracts to be quite high, requiring negotiation and rebidding between the contrac- tors and the customer.

The key point about work authorization is grounded in the nature of stated terms for proj- ect development. The manager must draw up contracts that clearly stipulate the work agreed to, the nature of the project development process, steps to resolve disputes, and clearly identi- fied criteria for successfully completing the project. This specificity can be especially important when dealing with external stakeholders, including suppliers and clients. Precisely worded work authorization terminology can provide important assistance for project development downstream. On the other hand, ambiguously stated terms or incorrectly placed milestones may actually provoke the opposite results: disagreements, negotiations, and potentially legal action—all guaranteed to slow project development down to a crawl and add tremendous costs to the back end of “completed” projects.

5.4 Scope reportIng

At the project’s kickoff, the project team and key clients should make decisions about the need for project updates: How many will be required, and how frequently? scope reporting fulfills this function by determining the types of information that will be regularly reported, who will  receive  copies of this information, and how this information will be acquired and disseminated.

What types of information are available and what may be appropriately reported? Clearly, a wide variety of forms of project reports can be tracked and itemized. Although the concepts will be

5.4 Scope Reporting 165

developed in more detail in subsequent chapters, among the types of project parameter informa- tion that are most commonly included in these reports are:17

• Cost status: updates on budget performance - S curves: graphical displays of costs (including labor hours and other costs) against project

schedule - Earned value: reporting project status in terms of both cost and time (the budgeted value

of work performed regardless of actual costs incurred) - Variance or exception reports: documenting any slippages in time, performance, or cost

against planned measures • Schedule status: updates on schedule adherence • Technical performance status: updates on technical challenges and solutions

Solid communication between all concerned parties on a project is one of the most impor- tant aspects of effective scope reporting. It is necessary to avoid the temptation to limit project status information to only a handful of individuals. Often using the excuse of “need to know,” many project teams keep the status of their project secretive, even past the point when it has run into serious trouble (see “Project Management Research in Brief” box). Project manag- ers should consider who would benefit from receiving regular project updates and plan their reporting structure appropriately. Some stakeholders who could be included in regular project status reporting are:

• Members of the project team • Project clients • Top management • Other groups within the organization affected by the project • Any external stakeholders who have an interest in project development,

such as suppliers and contractors

All of these groups have a stake in the development of the project or will be affected by the imple- mentation process. Limiting information may seem to be efficient or save time in the short run, but it can fuel possible misunderstandings, rumors, and organizational resistance to the project in the long run.

Box 5.1

Project Management research in Brief

Information Technology (IT) Project “Death Marches”: What Is Happening Here?

Every year, billions of dollars are spent on thousands of information technology (IT) projects worldwide. With the huge emphasis on IT products and advances in software and hardware systems, it is no surprise that inter- est in this field is exploding. Under the circumstances, we would naturally expect that, given the importance of IT projects in both our corporate and everyday lives, we are doing a reasonably good job of implementing these critical projects, right? Unfortunately, the answer is a clear “no.” In fact, IT projects have a terrible track record for delivery, as numerous studies show. How bad? The average IT project is likely to be 6 to 12 months behind schedule and 50% to 100% over budget. Of course, the numbers vary with the size of the project, but the results still suggest that companies should expect their IT projects to lead to wasted effort, enormous delays, burnout, and many lost weekends while laboring for success with the cards stacked the other way.

What we are referring to here are “death march” projects. The death march project is typically one in which the project is set up for failure through the demands or expectations that the company places on it, leaving the expectation that project team will pull off a miracle. The term death march invokes images of team members wearily trudging along mile after mile, with no end or possibility of successful conclusion in sight. Death march projects are defined as projects “whose parameters exceed the norm by at least 50%.” In practical terms, that can mean:

• The schedule has been compressed to less than half the amount estimated by a rational estimating process (e.g., the schedule suggests it should take one year to complete the project, but top manage- ment shrinks the schedule to six months).

(continued )

166 Chapter 5 • Scope Management

• The project team staffing has been reduced to half the number that normally would be assigned to a project of this size and scope (e.g., a project manager needing 10 resources assigned is instead given only 5).

• The budget and other necessary resources are cut in half (e.g., as a result of downsizing and other cost-cutting exercises in the company, everyone is expected to “do more with less”; or competitive bidding to win the contract was so intense that when the smoke cleared, the company that won the project did so at such a cut-rate price it cannot possibly hire enough people to make it work).

The result of any or all of these starting conditions is a virtual guarantee that the project will fail. The preva- lence of death march projects begs the question: Why are death march projects so common and why do they continue to occur? According to the research, there are a number of reasons:

1. Politics—the project may be the result of a power struggle between two ambitious senior executives, or it may have been set up to fail as a form of revenge upon some manager. In these cases, the project manager just gets caught in the blast zone.

2. Naïve promises made by marketing executives or inexperienced project managers—inexperience can result in all sorts of promises made, including those that are impossible to fulfill. In order to impress the boss, a new project manager may promise more than he can deliver. Marketing managers who are concerned with sales and how to improve them may think, “what’s a little exaggerated promise if it closes the deal?”

3. Naïve optimism of youth—a technical hotshot who is ambitious and feeling particularly cocky one day may make exaggerated promises that quickly result in the project team getting in over its head. Optimism is no substitute for careful planning.

4. The “start-up” mentality of fledgling entrepreneurial companies—start-up firms come loaded with energy, enthusiasm, and an aggressive, get-it-going attitude. When that mentality translates into projects, however, problems can occur. Entrepreneurial approaches to managing projects may ignore critical planning and detailed advance preparation that no experienced project manager would sacrifice.

5. The “Marine Corps” mentality: Real programmers don’t need sleep—this attitude emphasizes bravado as a substitute for evaluation. The hyperoptimistic schedule or budget is not an accident; it is a deliberate manifestation of this aggressive attitude: If you can’t handle it, you don’t belong here.

6. Intense competition caused by globalization—the appearance of new, international competitors often comes as a rude awakening when it is first experienced. Many firms respond with radical moves that push for rapid technical advances or “catching up” behaviors, resulting in numerous new death march projects.

7. Intense competition caused by the appearance of new technologies—as new opportunities emerge through new technologies, some firms jump into them eagerly, without first understanding their capacities, scalability for larger projects, and limitations. The result is an endless game of exploiting “opportunities” without fully comprehending them or the learning curve for using new technologies.

8. Intense pressure caused by unexpected government regulations—government-mandated death march projects occur through a failure of top management to anticipate new regulations or man- dates or, worse, to recognize that they are coming but put off any efforts to comply with them until deadlines have already been set. New pollution or carbon-energy controls laws, for example, may lead to huge projects with looming deadlines because the company put off until the last minute any efforts to self-regulate.

9. Unexpected and/or unplanned crises—any number of crises can be anticipated with sufficient advance planning. Examples of crises that can severely affect project delivery are the loss of key project team personnel midway through the project’s development or the bankruptcy of a key supplier. Some crises, of course, are unpredictable by definition, but all too often the crisis that destroys all of the work to date on a project is one that could have been anticipated with a little foresight. The long road back from these disasters will lead to many death marches.

Death march projects are not limited to the IT industry. Indeed, as we consider the list of reasons why death marches occur, we can see similar effects in numerous projects across different industries. The end result is typically the same: massively wasted efforts spent on projects that have been set up to fail by the very conditions under which they are expected to operate. The implications are clear: To avoid setting the stage for future death march projects, we need to start with the end in mind and ask, are the goals and conditions (budget, personnel assigned, and schedule) conducive to project success, or are we just sowing the seeds of inevitable disaster?18

5.5 Control Systems 167

5.5 control SyStemS

A question we might ask is: “How does a project become one year late?” The answer is: “One day at a time.” When we are not paying close attention to a project’s development, anything can (and usually does) happen. Project control is a key element in scope management. control systems are vital to ensure that any changes to the project baseline are conducted in a systematic and thorough manner. Project managers can use a number of project control systems to track the status of their projects, including:19

• Configuration control includes procedures that monitor emerging project scope against the original baseline scope. Is the project following its initial goals, or are they being allowed to drift as status changes or new circumstances alter the original project intent?

• Design control relates to systems for monitoring the project’s scope, schedule, and costs during the design stage. Chrysler developed Platform Design Teams (PDTs), composed of members from functional departments, to ensure that new automobile designs could be immediately evaluated by experts in engineering, production, and marketing. It found that this instanta- neous feedback eliminated the time that had been lost when designs were deemed unwork- able by the engineering organization at some later point in the car’s development.

• Trend monitoring is the process of tracking the estimated costs, schedules, and resources needed against those planned. Trend monitoring shows significant deviations from norms for any of these important project metrics.

• Document control ensures that important documentation is compiled and disseminated in an orderly and timely fashion. Document control is a way of making sure that anything contrac- tual or legal is documented and distributed. For example, document control would ensure that the minutes of a building committee’s deliberations concerning a new construction proj- ect are reproduced and forwarded to appropriate oversight groups.

• Acquisition control monitors systems used to acquire necessary project equipment, materi- als, or services needed for project development and implementation.

• Specification control ensures that project specifications are prepared clearly, communicated to all concerned parties, and changed only with proper authorization.

One of the most important pieces of advice for project managers and teams is to establish and maintain a reasonable level of control (including clear lines of authority) at the start of a project. Perhaps surprisingly, reasonable here means avoiding the urge to overdevelop and overcontrol proj- ects. Project managers’ ability to manage day-to-day activities can be hindered by having to handle excessive control system reports—there can simply be too much paperwork. On the other hand, it is equally important not to devalue control systems as taking up too much time. Knowing the right project control systems to use and how often to employ them can eliminate much of the guesswork when dealing with project delays or cost overruns. For example, a recent large office building proj- ect brought together a project team composed of groups and contractors relating to the architectural design; the heating, ventilation, and air conditioning (HVAC); the electrical and plumbing work; concrete and steel construction; and facilities management. During meetings early in the project, the combined construction project team agreed to a clear scope for the project and a streamlined control and reporting process that had trend monitoring, configuration, and specification control as the key elements in the project review cycle. Because several of the independent contractors had a long history of working together and had built a level of mutual trust, they reasoned that the bar- est minimum control processes would be preferable. In this example, the team sought a balance in project control processes between the twin errors of excessive and nonexistent control.

configuration management

The Project Management Body of Knowledge (PMBoK) defines configuration management as “a sys- tem of procedures that monitors emerging project scope against the scope baseline. It requires documentation and management approval on any change to the baseline.” A baseline is defined as the project’s scope fixed at a specific point in time—for example, the project’s scheduled start date. The baseline, therefore, is viewed as the project’s configuration. Remember that the scope baseline is simply a summary description of the project’s original content and end product, including budget and time constraint data. As a result, in simple terms, configuration management relates to the fact that projects usually consist of component parts, all contributing to the project’s functionality.

168 Chapter 5 • Scope Management

These parts must be individually developed and ultimately assembled, or configured, to produce the final product or service. The role of designing, making, and assembling these components belongs to configuration management. However, because this process often requires several iterations, adjustments, and corrections to get the project right, in practical terms, configuration management is the systematic management and control of project change.20

The management of project changes is most effectively accomplished at the beginning of the project when plans and project scope are first articulated. Why would you want to begin managing change at the point where you are carefully defining a project? The answer is that the need to make significant project changes is usually an acknowledged part of the planning process. Some changes are made as the result of carefully acknowledged need; others emerge almost by accident during the project’s development. For example, we may discover at some point during the project’s execu- tion that certain technical specifications we designed into the original prototype may not work under specific conditions (e.g., high altitudes, humid conditions), requiring us to make midcourse alterations to the project’s required functionality.

Configuration management works toward formalizing the change process as much as pos- sible as early in the project’s life as possible, rather than leaving needed downstream changes to be made in an uncoordinated manner. The need to make project changes or specification adjustments, it has been suggested, comes about for one of several reasons:21

• Initial planning errors, either technological or human. Many projects involve technological risks. It is often impossible to accurately account for all potential problems or technological roadblocks. For example, the U.S. Navy and Marine Corps’ drive to create a vertical takeoff, propeller-driven aircraft, the Osprey, resulted in a series of unexpected technical problems, including some tragic accidents during prototype testing. Initial engineering did not pre- dict (and perhaps could not have predicted) the problems that would emerge with this new technology. Hence, many projects require midcourse changes to technical specifications as they encounter problems that are not solvable with existing resources or other unexpected difficulties. Planning errors also may be due to human mistake or lack of full knowledge of the development process. In the case of nontechnical causes for change, reconfiguration may be a simple adjustment to the original plans to accommodate new project realities.

• Additional knowledge of project or environmental conditions. The project team or a key stakeholder, such as the client, may enter into a project only to discover that specific features of the project or the business, economic, or natural environment require midcourse changes to the scope. For example, the technical design of a deep-water oil-drilling rig may have to be significantly modified upon discovery of the nature of water currents or storm characteris- tics, underwater terrain formations, or other unanticipated environmental features.

• Uncontrollable mandates. In some circumstances, events occur outside the control of the project team and must be factored into the project as it moves forward. For example, a governmental mandate for passenger safety established by the European Union in 2001 forced Boeing Corporation to redesign exit features on its new 777 aircraft, temporarily delaying the project’s introduction and sale to foreign airlines.

• Client requests. The situation in which a project’s clients, as the project evolves, attempt to address new needs with significant alterations is a very common phenomenon. In software development, for example, a client taking the role of potential user might list several com- plaints, requests, new features, reworked features, and so on when first exposed to a planned software upgrade. Often IT projects run excessively behind schedule as users continue to bring forward lists of new requirements or change requests.

Configuration management can probably be traced to the change control techniques initiated by the U.S. defense community in the 1950s. Defense contractors routinely changed the configu- ration of various weapon systems at the request of governmental groups, especially the armed forces. In making these changes, however, little of the process would be documented or traceable; hence, when new weapon systems were introduced, the armed forces found them hard to service and maintain. Poor record keeping led to poor channels of communication to relevant contrac- tors when problems or modification requests arose. As a result, the Defense Department routinely found it necessary to reissue general change request orders that delayed its ability to gain timely performance corrections. In the middle of the decade after much frustration (and expense), the

5.6 Project Closeout 169

Step Action

1. Configuration identification 1. Develop a breakdown of the project to the necessary level of definition.

2. Identify the specifications of the components of the breakdown and of the total project.

2. Configuration reviews Meet with all the project stakeholders to agree to the current project definition.

3. Configuration control 1. If agreement is achieved, repeat the first three steps, developing the breakdown and specification further, until the project is defined.

2. If agreement is not reached, either:

• Cycle back to the configuration as agreed at a previous review and repeat steps 1, 2, and 3 until agreement is achieved; or

• Change the specification last obtained by a process change control to match what people think it should be.

4. Status accounting Memory of the current configurations, and all previous ones, must be maintained so that if agreement is not reached at some point, the team can cycle back to a previous configuration and restart from there. Also, memory of the configuration of all prototypes must be maintained.

FIgure 5.11 four Stages of configuration Management

Source: © Turner, R. (2000), “Managing scope-configuration and work methods,” in Turner, R. (Ed.), Gower Handbook of Project Management, 3rd ed. Aldershot, UK: Gower.

Defense Department finally issued an order mandating that all organizations supplying systems to the government demonstrate a comprehensive change control and documentation process.22

Figure 5.11 presents the four stages in configuration management, including the tasks to be performed at each of the configuration management steps.23

5.6 project cloSeout

Effective scope management also includes appropriate planning for a project’s termination. Although the process of effective project termination will be covered in great detail in Chapter 14, it is useful to reflect on the fact that even when planning for a project, we should be planning for the project’s conclusion. The project closeout step requires project managers to consider the types of records and reports they and their clients will require at the completion of the project.24 The earlier in the scope development process that these decisions are made, the more useful the infor- mation collected over the project’s development can be. Closeout information can be important (1) in the case of contractual disputes after the project has been completed, since the more thorough the project records, the less likely it is that the organization will be held liable for alleged violations; (2) as a useful training tool for postproject analysis of either successes or failures; and (3) to facilitate project auditing tasks by showing the flow of expenses in and out of various project accounts.

Closeout documentation a project leader may decide to track includes the following:

• Historical records, or project documentation that can be used to predict trends, analyze feasi- bility, and highlight problem areas for similar future projects

• Postproject analysis, which follows a formal reporting structure, including analysis and doc- umentation of the project’s performance in terms of cost, schedule adherence, and technical specification performance

• Financial closeout, or the accounting analysis of how funds were dispersed on the project

One of the most important lessons for successful project managers is to “start with the end in mind.” Clear goals at the beginning of a project make clear what the project’s completion will require. Project closeout requires managers to consider a priori the types and amounts of informa- tion to continually collect during project development, relying on a sound project tracking and

170 Chapter 5 • Scope Management

filing system. That way, when the project is in its closeout, time is not wasted scrambling for old project records and other information that is needed but missing.

A project’s goals are just a dream until they are written down. Until the project’s plans are laid out, its purposes specified, its constraints considered, and its results anticipated, a project is nothing more than an organization’s hope for success. Scope management is the systematic process of turning these dreams into reality by formally developing project goals. Like a lighthouse, a thor- ough scope document illuminates the way toward project completion even while the team may be tossed on the waves of numerous crises and concerns. As long as the light continues to shine, as long as the project manager works to develop and maintain the various elements of project scope, the likelihood of passage to successful project completion is strong.


1. Understand the importance of scope management for project success. This chapter examined the role of project scope management as an important plan- ning technique. Project scope management is the detailed development of the project plan to specify the work content and outcomes of the project, the activities that must be performed, the resources consumed, and the quality standards to be main- tained. The six steps in creating a project scope management procedure are conceptual develop- ment, the scope statement, work authorization, scope reporting, control systems, and project closeout.

Conceptual development is the process of choos- ing the best method for achieving the project’s goals. The project’s conceptual development allows the project manager to begin the process of transitioning from the project as a dream to the project as a specific goal or set of objectives. Problem statements, infor- mation gathering, identified constraints, alternatives analyses, and final project objectives are all created during the conceptual development.

The scope statement is a comprehensive defini- tion of all parameters necessary for the project to succeed. A number of elements factor into effective scope statement development, but perhaps most key is the Work Breakdown Structure (WBS). The work breakdown process gives the project team the ability to create a hierarchy of activities-based pri- orities, creating work packages, tasks, and subtasks as building blocks for completing the overall proj- ect. When this is coupled with a clear Responsibility Assignment Matrix (RAM), the project manager and team are able to begin moving beyond the project as a concept and tackle the project as a set of identi- fied activities, with responsible personnel assigned to them.

Work authorization, the third element in project scope management, refers to the process of sanc- tioning all project work. This step may involve formulating contractual obligations with vendors, suppliers, and clients.

Project scope reporting refers to any control systems and documentation that will be used to

assess the project’s overall status. Examples of scope reporting include the creation of control documents and budget and schedule tracking.

Control systems, including configuration man- agement, refer to the processes put in place to track the ongoing status of the project, compare actual with baseline projections, and offer corrective measures for bringing the project back on track.

Finally, the project closeout phase represents the project team’s best determination as to the information and transition materials necessary to ensure a smooth transfer of the project to its intended clients.

2. Understand the significance of developing a scope statement. The project scope statement reflects the project team’s best efforts to create the documentation and approval for all important project para meters prior to beginning the devel- opment phase. This statement is an opportunity to clearly “nail down” the elements of the project and what it is intended to accomplish, as well as to identify the project’s critical features. The ele- ments in the scope statement include (1) establish- ing the goal criteria—defining what will demon- strate project success and what the decision gates are for evaluating deliverables; (2) developing the management plan for the project— determining the structure for the project team, key rules and pro- cedures that will be maintained, and the control systems to monitor effort; (3) establishing the Work Breakdown Structure (WBS)—dividing the proj- ect into component substeps in order to establish the critical interrelationships among project activi- ties; and (4)  creating a scope baseline—provid- ing a summary description of each component of the project’s goal, including budget and schedule information for each activity.

3. construct a work Breakdown structure for a project. The Work Breakdown Structure (WBS) is a process that sets a project’s scope by break- ing down its overall mission into a cohesive set of  synchronous, increasingly specific tasks. Defined as a “deliverable-oriented grouping of

Discussion Questions 171

project elements which organizes and defines the total scope of the project,” the WBS is the most important organizing tool project teams have in preparing their tasks.

The WBS serves six main purposes: (1) it echoes project objectives; (2) it is the organization chart for the project; (3) it creates the logic for tracking costs, schedule, and performance specifications for each element in the project; (4) it may be used to commu- nicate project status; (5) it may be used to improve overall project communication; and (6) it demon- strates how the project will be controlled. The logic of the WBS is to subdivide project deliverables into increasingly more specific sublevels to identify all significant activities. The common terminology is to first identify the overall project, then the major deliverables for that project, and finally the work packages that must be accomplished to complete each deliverable.

Closely related to the WBS is the Organization Breakdown Structure (OBS), which allows com- panies to define the work to be accomplished and assign it to the owners of the work packages. The budgets for these activities are then directly as- signed to the departmental accounts responsible for the project work.

4. develop a responsibility Assignment Matrix for a project. The Responsibility Assignment Matrix (RAM), sometimes referred to as a linear responsi- bility chart, identifies project team personnel who

are directly responsible for each task in the project’s development. The RAM identifies where respon- sible team members can go for task support, who should next be notified of the task completion sta- tus, and any sign-off requirements. The goal of the RAM is to facilitate communication between proj- ect team personnel to minimize transition disrup- tions as the project moves toward completion. An additional benefit of the RAM is to make the coor- dination between project managers and functional department heads easier as they work to make best use of personnel who may be assigned to the project for only temporary periods.

5. describe the roles of changes and configuration management in assessing project scope. Significant project changes occur for a number of reasons, includ- ing (1) initial planning errors, either technological or human; (2) additional knowledge of project or envi- ronmental conditions; (3) uncontrollable mandates; and (4) client requests.

The four stages of configuration management are (1) configuration identification—breaking down the project and identifying the specifications of its components; (2) configuration reviews—meeting with stakeholders to agree to project definition; (3)  configuration control—following agreement with stakeholders, developing the breakdown and specifications further; and (4) status accounting— maintaining memory of all current and previous configurations for reference.

Key Terms

Baseline (p. 167) Business case (p. 149) Conceptual development

(p. 148) Configuration management

(p. 167) Control systems (p. 167) Cost control accounts (p. 159)

Cost-plus contracts (p. 164) Deliverables (p. 153) Milestone (p. 163) Organization Breakdown

Structure (OBS) (p. 159) Project charter (p. 151) Project closeout (p. 169) Project scope (p. 146)

Requirements gathering (p. 148)

Responsibility Assignment Matrix (RAM) (p. 160)

Scope baseline (p. 153) Scope management (p. 146) Scope reporting (p. 164) Scope statement (p. 153)

Statement of Work (SOW) (p. 150)

Turnkey contracts (p. 164) WBS codes (p. 158) Work authorization (p. 161) Work Breakdown Structure

(WBS) (p. 153) Work packages (p. 156)

Discussion Questions

5.1 What are the principal benefits of developing a compre- hensive project scope analysis?

5.2 What are the key characteristics of a work package? 5.3 Create a Work Breakdown Structure for a term paper

project or another school-related project you are working on. What are the steps in the WBS? Can you identify any substeps for each step?

5.4 What are the benefits of developing a Responsibility Assignment Matrix (RAM) for a project?

5.5 Develop an argument for scope reporting mechanisms. At  a minimum, what types of reports do you consider necessary for document control of a project? Why?

5.6 What is the chief purpose of configuration management? In your opinion, why has it become increasingly popu- lar in recent years as a part of the project management process?

5.7 What is the logic behind developing a plan for project closeout prior to even beginning the project?

172 Chapter 5 • Scope Management

Problems 5.1 Prepare a group project for the classroom. Use as your

model one of the following: a. Construction project b. Software development project c. Events management project (e.g., an awards

banquet) d. New product development project

Develop a Statement of Work (SOW) for the project, using the format of (1) background, (2) task, (3) objec- tives, (4) approach, and (5) input source. Next, create a

Work Breakdown Structure (WBS) for the project. What are the key steps, including work packages, tasks, and any related subtasks for the project?

5.2 Using the project you identified in Problem 1, create a Responsibility Assignment Matrix (RAM) for it, identi- fying at least six fictitious project team members.

5.3 Research a real project through library resources or the Internet and develop a brief scope statement for the project, a general WBS, and any other information per- taining to the scope management for that project.

CaSe STuDy 5.1 Boeing’s Virtual Fence

On January 14, 2011, Secretary of Homeland Security Janet Napolitano made it official: The Virtual Fence Project was to be officially canceled. In her statement explaining the decision, Napolitano cited the diffi- culty in creating a unified, fully integrated security system and promised to “pursue a new path forward.” What was left  unsaid were the reasons that led to the  final decision—principally, struggling with a too- complicated technical system that did not work but was leading to ballooning costs.

Illegal crossing into the United States along the Mexican border has reached epidemic proportions in recent years. Fear of drug smuggling, illegal aliens, and possible terrorist incursions have made the issue of homeland security one of the major “hot buttons” in the political arena, both in Washington, DC, and within states located along the southern border as well as those in proximity to Canada. The problem is compounded by the sheer sizes of the borders involved. The Mexican/ U.S. border runs for nearly 2,000 miles, much of it across desert wastelands and inhospitable and remote areas. Establishing any sort of border security, in the wake of the 9/11 attacks, is a national necessity but a daunting and difficult task.

The Department of Homeland Security (DHS), organized following the attacks on the World Trade Center towers, is charged with the responsibility of securing all borders and points of illegal entry into the United States, in cooperation with Customs and Border Protection. As part of its mandate, it has devel- oped plans for creating a more secure and stable border with Mexico to prevent the continuous flow of undocu- mented immigrants, drugs, and potential terrorists. For the first stage in this process, DHS proposed a project to physically and electronically seal the stretch of the desert between the United States and Mexico under a multibillion-dollar contract named the Secure Border

Initiative Net (SBInet). President Bush in May 2006 called SBInet “the most technologically advanced bor- der security initiative in American history.” A 28-mile stretch of desert, centered on Nogales, Texas, was to be the pilot stage in a project that eventually would be used to monitor and control some 6,000 miles of border with both Mexico and Canada.

In late 2006, Boeing was selected as the major con- tractor for the SBInet project. Although better known for their military weapon systems, Boeing’s Integrated Defense Systems Unit was made responsible for overall coordination of a massive system of towers as well as listening devices, motion sensors, cameras, and radar to be used to detect and help apprehend illegals crossing the border. In fact, the U.S. government chose to out- source the entire project to private firms; that is, they expected that contractors would design the program’s elements, build them, and then handle full oversight of their own work.

In a nutshell, the system used a chain of 100-foot- tall towers that each scanned a 360-degree radius for a distance of 10 miles. Ground radar sensors also attempted to detect footsteps, bicycles, and vehicles. The first $20 million pilot phase, named Project 28 after the length of the part of the desert that it was supposed to cover, was to be completed by mid-June 2007. Boeing selected more than 100 subcontractors to build various components of the system, with its project managers maintaining overall control of the development process. Unfortunately, their structure was unwieldy, and the project was further compromised by the sheer number of distinct elements and technical systems Boeing was attempting to integrate. The technical challenge of inte- grating systems including watch towers, sensors, radar, and specialized cameras was beyond anything Boeing had attempted before. The problem was particularly noteworthy when we consider that integration, in many

Case Study 5.2 173

CaSe STuDy 5.2 California’s High-Speed Rail Project

With the announcement that California would be com- mitting $4.3 billion to the construction of a 29-mile rail link between the towns of Fresno and Madera in the state’s Central Valley, California’s 20-year-old quest for a high-speed rail line was finally coming true. The

California High-Speed Rail Authority (CHSRA), first es- tablished in the mid-1990s, had long pursued the goal of linking the San Francisco Bay metropolitan area in the north to the cities of Los Angeles and San Diego in the south. Under the administration of President Obama,

ways, was the project. The various technical elements were difficult but attainable. The challenge for SBInet lay in the ability of Boeing to find a means to bring all these new and unproven technologies together under one umbrella. So complicated was the challenge, in fact, that the virtual fence failed a series of initial tests, sig- nificantly delaying the full deployment of Project 28.

Unfortunately, these technical and coordination problems were never resolved. In the nearly three years after original testing was done on one section of the fence, SBInet had cost the government $672 million dol- lars, with the end nowhere in sight. Although the total project cost was anticipated at $1.1 billion, congressio- nal watchdog groups argued that the final cost of the project could soar to over $30 billion. Costs, in fact, were a sore point with the project from the time it was bid. Originally promising to complete SBInet for $1.1 billion, Boeing’s revised estimates went to $2.5 billion and then,  just a few months later, to $8 billion. This rapid escalation of projected costs finally prompted a congres- sional oversight committee hearing, in which Boeing endured withering criticism from Representatives who questioned their motives in asking for more money and time to complete the project. In the meantime, beset by continuing problems, Boeing had also revised its esti- mates for the completion date to 2016, more than seven years after the date in the original plan.

A major concern was Boeing’s pyramid-like management structure that critics said caused confu- sion and a lack of clear responsibility. Worse, it made it easier for hidden costs to be charged to the project. Because Boeing embedded multiple subcontracting layers in the Virtual Fence development, they were able to add charges at each level. The larger prob- lem was the clear conflict of interest that emerged by placing Boeing in charge of project oversight, while allowing them to manage sub-contractors, and moni- tor the progress of the project. Not surprisingly, with this configuration, little information came to light about cost overruns or schedule slippages until qual- ity and overrun problems were simply too large to

ignore . . . or hide. Critics compared this attitude of easy oversight and loose control to the huge problems that had plagued Boston’s “Big Dig” construction project (see Case Study 8.2 in text).

Admittedly, the problems that sank the SBInet project were complicated and came from multiple sources. Besides the technical challenges of manag- ing 100 subcontractors, all required to provide criti- cal components that Boeing would integrate, the project had effectively shut out most federal agencies and oversight groups. It was difficult to get accurate project status information given the government’s decision to “farm out” border security to private contractors. As a result, congressional investigators found that Homeland Security officials were simply standing by while Boeing provided information that was “replete with unexplained anomalies, thus ren- dering the data unfit for effective contractor man- agement and oversight.” Furthermore, many critics questioned the feasibility of the original intent of the project itself, wondering about the likelihood of ever effectively sealing a border that runs through some of the most inhospitable terrain in North America. Whether through a combination of poor oversight, over- optimistic scope expectations, or simple inabil- ity to make this cutting-edge technology work, SBInet remains an example of a significant program failure at the taxpayer’s expense.25


1. What problems do you see emerging from a project such as SBInet where the government allows the contractor to determine scope, man- age all contractor relations, and decide how to share project status information with oversight bodies?

2. Consider the following two arguments: “The fail- ure of SBInet was due to poor scope management” versus “SBInet failed because of poor oversight and project controls.” Take one side or the other in this argument, and justify your response.


174 Chapter 5 • Scope Management

the federal government set aside money from a stimu- lus package to fund high-speed rail initiatives in sev- eral states, including Wisconsin, Florida, Ohio, Illinois, and California. The election of Republican governors in Ohio and Wisconsin led to a rethinking of the projects in those states, which ultimately refused the seed money grants from Washington, suspicious that the rail proj- ects were both unnecessary and likely to be subject to huge cost overruns, for which state taxpayers eventually would be held responsible. As a result, Transportation Secretary Ray LaHood reclaimed $1.2 billion from those states to be presented to 13 other states.

One of the states that stood to benefit most from this redistribution of federal money was California, with its ambitious, and many argue, ultimately fool- hardy decision to support a massive transportation project to link its cities with high-speed rail. The history of CHSRA’s drive to create high-speed rail is a fascinat- ing one, with supporters and critics in equal measure. As part of its initial pitch for the project, CHSRA argued that the system would lead to multiple benefits. For a one-way $55 ticket, passengers in Los Angeles would be able to travel to the Bay Area in less than 3 hours or reach San Diego in 80 minutes. Estimating that 94 million pas- sengers would use the rail system each year and that its development would generate hundreds of thousands of permanent jobs, CHSRA used these projections to help convince state voters to approve a nearly $10 billion bond issue and support the project in a 2008 referendum. Other advantages the organization cited included the reduction of pollution and fossil-fuel use by diverting millions of people to the rail line who otherwise would use automobile or air travel between cities.

With revised estimated cost of at least $69 billion, the overall project would first operate trains up to 220 mph along a 520-mile route between Anaheim and San Francisco. Extensions to San Diego and Sacramento would be built later. A total of $3.18 billion in federal funding has been approved for the state’s bullet train proposal so far, the largest amount for any pending rail project in the nation. With matching state funds, the amount available for construction is about $5.5 billion, according to CHSRA.

Since its approval, a number of events have led insiders to reconsider the wisdom of pursuing the rail project. First, based on other high-speed rail projects, CHSRA has revised its projections for ridership down- ward, suggesting that the project will serve 39 mil- lion passengers by its tenth year of operation, which is about 40% of its original estimate prior to getting funding approval. Second, another change in the origi- nal business model is that projected ticket prices have been raised to $105 for a one-way trip, although critics suggest that actual prices, based on comparable cost- per-mile data from Europe and Japan, are likely to be

closer to $190. A third concern relates to the decision to start the project with a 65-mile link between two small Central Valley communities; that is, though the high-speed rail project is specifically designed to join major metropolitan areas, the first pilot stage is to be constructed along the route that is the least populated segment of the line. This decision sits poorly not only with rail critics, but also with rail supporters, who rec- ognize the need to make a more significant statement in order to answer other objections of critics. “It defies logic and common sense to have the train start and stop in remote areas that have no hope of attaining the rid- ership needed to justify the cost of the project,” U.S. Representative Dennis Cardoza (D., Calif.) wrote in a letter to Transportation Secretary Ray LaHood.

A fourth closely questioned element in the project is the projected final price. Though CHSRA and state officials hold to the latest $69 billion price tag (a figure that has doubled since the original $33 billion estimate approved by voters in 2008), others, including the trans- portation consultants at Infrastructure Management Group, have suggested that this figure, based on his- torical data, grossly underestimates the final cost, while inflating the likely number of passengers. Economists suggest that a more likely range for the final cost of the project would be anywhere from $100 to $250 billion, and a more reasonable estimate of annual passenger traffic is in the range of 5 million. If these numbers are close to accurate (and they are disputed by CHSRA), they point to a project that cannot ever hope to pay for itself, will require long-term annual subsidies, and will place the already cash-strapped state even deeper into a financial hole. The state, which recently averted a budget crisis when it agreed to cut $15 billion in public spending, says it will match federal spending dollar for dollar and also hopes to secure private-sector invest- ment. However, with unemployment in California remaining steady at nearly 8%, these claims are being called into question.

A recent study by three economists found the CHSRA business model to be deeply flawed, con- cluding that it relies too heavily on federal grants and does not adequately address risks posed by fluctuat- ing ticket prices. “When an investor looks at an asser- tion by the CHSRA that says you’re going to earn an operating surplus of $370 million in the first year of operations and $1.5 billion profit by the third year, they shake their heads and smile,” said William Grindley, former World Bank analyst. “It doesn’t pass the smell test.” This new study calls CHSRA’s revenue esti- mates “unreasonably optimistic” and is confirmed by a 2013 study by the Reason Foundation suggesting that CHSRA could require over $350 million in annual sub- sidies to stay in business. One key linchpin to attaining sustainability, for example, is CHRSA’s ability to secure

Case Study 5.3 175

billions of dollars in additional funding from the fed- eral government. For its part, CHSRA acknowledges that the project hinges on additional funding coming from the federal government but believes that making a good faith effort to produce a workable rail network is critical for securing additional money.

Recent court decisions have put the brakes on the project as well. The California 3rd District Court ruled that the state could not continue to sell bonds support- ing the project as the CHSRA had failed to comply with its own guidelines regarding funding. Voters were originally told that state financial exposure would be l imited and that the federal government and private investors would put up most of the money— promises that so far have failed to materialize. However, Washington has committed only a few billion dollars and there is absolutely nothing else the state can expect from the federal government to support the project. The court ruled that the state’s attempt to sell $6.8 billion in bonds to fund the project violated the original provi- sions of the 2008 referendum. Jerry Brown, California’s governor, has vowed to continue the court battle as long as it takes to get the bonds approved. However, in the meantime, the project is stalled for lack of funding

to continue building the phase one, 29-mile stretch of track. The project also faces a ticking clock: If the fed- eral grant money is not used by a specific date, it will be reclaimed by Washington.

As of now, one could argue that the project’s future is simply a debate between “dueling econo- mists”; however, there is no question that the future of California’s high-speed rail is uncertain. Will the out- come be a case of the best intentions meeting economic realities? Only time will tell.26


1. Assess the benefits and drawbacks of the high- speed rail project. In your opinion, do benefits outweigh drawbacks, or vice versa? Why? Justify your answer.

2. What are the implications of starting a project based on tenuous projections that may or may not come true 10 years from now?

3. Could you justify the California high-speed rail project from the perspective of a massive public works initiative? In other words, what other fac- tors enter into the decision of whether to pursue a high-speed rail project? Why are they important?

CaSe STuDy 5.3 Project Management at, a software engineering and systems de- velopment consulting firm, sells a wide assortment of Internet and computer-based solutions for resource planning, administrative, and accounting networks to organizations in health care delivery, financial services, and hotel management. Typically, a service provider approaches with a list of prob- lems it has and some targets for organizational im- provement. Because most of Dotcom’s clients are not themselves computer savvy, they tend to rely heavily on Dotcom to correctly diagnose their difficulties, pro- pose solutions to correct these problems, and imple- ment the new technologies. The industry in which Dotcom operates is extremely competitive, forcing successful organizations to make low bids to win con- sulting contracts. In this environment, project man- agement is vital for Dotcom’s success because poorly managed projects quickly “eat up” the profit margin for any job.

Unfortunately, Dotcom’s senior management team has noticed a recent upsurge in project operating

costs and a related drop-off in profitability. In par- ticular, Dotcom’s executives are concerned because the last seven consulting contracts have resulted in almost no profit margin because the software systems were delivered late and required several rounds of rework to fix bugs or correct significant shortcomings in the software. The firm decided to hold a weekend off-site retreat with the project managers responsible for these most recently completed projects in order to learn why project management was being done so poorly.

To a person, the project managers fixed the blame for their problems on the clients. A typical response was made by Susan Kiley, a project manager with more than five years’ experience, who stated, “We are put in a very tough position here. Most of the custom- ers don’t know what they really want so we have to spend hours working with them to get a reasonable Statement of Work that we can develop the project scope around. This takes time. In fact, the more time I spend with the customer up front, the less I have to


176 Chapter 5 • Scope Management

get my team to actually develop the system for them. It’s a Catch-22—If I want to get things right, I have to pry information out of them. The better I do getting a sense of their problems, the less time I have to develop and run the project!”

Jim Crenshaw, another project manager, spoke up. “It doesn’t stop there, unfortunately. My biggest problems are always on the back end of the project. We work like dogs to get a system up that corresponds to the client’s demands, only to have them look it over, push a few buttons, and start telling us that this was not anything like what they had in mind! How am I supposed to develop a system to solve their problems when they don’t know what their problems are? Better yet, what do we do when they ‘think’ they know what they want and then when we create it, they turn around and reject our solutions out of hand?”

After two hours of hearing similar messages from the other project managers, it became clear to the senior management team that the project management prob- lems were not isolated but were becoming embedded

in the firm’s operations. Clearly, something had to be done about their processes.

Questions 1. How would you begin redesigning Dotcom.

com’s project management processes to minimize the problems it is experiencing with poor scope management?

2. How do the company’s consulting clients contrib- ute to the problems with expanding or changing scope? If you were to hold a meeting with a po- tential customer, what message would you want the customer to clearly understand?

3. How do you balance the need to involve clients with the equally important need to freeze project scope in order to complete the project in a timely fashion?

4. Why are configuration management and project change control so difficult to perform in the midst of a complex software development project such as those undertaken by

CaSe STuDy 5.4 The Expeditionary Fighting Vehicle

One of the most complex and difficult congressional budget decisions in years finally came due: the deter- mination of the fate of the Marine Corps’ Expeditionary Fighting Vehicle (EFV). Given the numerous delays, tests, conditional approvals, and retests, the EFV had been no stranger to controversy. Although the EFV was loudly defended by senior officers in the Pentagon, a growing army of critics cited the vehicle’s poor test performance, and costs continued to balloon. As one reporter noted, “After 10 years and $1.7 billion, this is what the Marine Corps got for its investment in a new amphibious vehicle: A craft that breaks down about an average of once every 4½ hours, leaks, and some- times veers off course.” The biggest question is: How did things get to that point with what was viewed, for many years, as one of the Marine’s highest priority ac- quisition programs?

The EFV program began more than 20 years ago when this armored amphibious vehicle was designed to replace the 1970s-era Amphibious Assault Vehicle. The purpose of vehicles such as the EFV is to provide armored support for the early stages of amphibious assault onto enemy shores. The EFV was designed to roll off a Navy assault ship, move under its own power at 20 mph on the water’s surface for distances up to 25

miles while transporting a Marine rifle squad (up to 17 Marines), cross hostile beaches, and operate on shore. The EVF was moderately armored and carried a 30-mm cannon in a turret for offensive firepower. The EVF often was described as a Marine Corps variant of the Bradley Fighting Vehicle.

The EFV began as a state-of-the-art acquisi- tion program for the Department of Defense (DoD). Following a concept exploration phase to determine the viability of the project that began in 1988, the project entered a program definition and risk reduc- tion phase during which it was considered “a model defense acquisition program,” winning two DoD awards for successful cost and technology manage- ment. The original contract was awarded to General Dynamics Corporation in June 1996 for full engi- neering and design work, and that corporation was awarded a subsequent contract for the system devel- opment and demonstration (SDD) phase of the pro- gram in July 2001. It is during this critical stage that all the complex engineering, systems development, and functionality of the program must be successfully demonstrated. Perhaps unwisely, General Dynamics budgeted only 27 months for total testing and system verification.

Case Study 5.4 177

This far-too-ambitious schedule soon became a problem for General Dynamics and the EFV as a series of technical problems began to surface. Two addi- tional years were added to the SDD phase as it became apparent that the EFV concept was beset with numer- ous unforeseen problems. In December 2004, tests of EFV prototypes demonstrated further problems. The tests showed severe failure in the vehicle’s main com- puter system, causing the vehicle’s steering to freeze. The hydraulic systems powering the vehicle’s bow- flap, installed to make the EFV more seaworthy, began leaking and failing. The EFV was originally intended to operate for an average of 70 hours between mission fail- ure breakdowns, but because of the numerous reliability problems, the Marines reduced this figure to 43.5 hours. Following these prototype tests, an additional two years were added to the program development schedule.

The year 2006 was not a good one for the Expeditionary Fighting Vehicle. The EFV was put through a critical operational assessment, which is a  series of tests to demonstrate that it could meet performance requirements and was ready for produc- tion. The EFV performed abysmally, experiencing numerous system failures, breakdowns, and failure in its reliability assessment. During the tests, the vehicles were able to operate on average for only 4.5 hours between breakdowns, and it took nearly 3.5 hours of corrective maintenance for every hour of operation. Poor reliability resulted in 117 mission failures and 645 acts of unscheduled maintenance during the tests. The EFV’s reliability was so poor that it successfully com- pleted only 2 of 11 attempted amphibious tests, 1 of 10 gunnery tests, and none of the 3 land mobility tests. Other problems included the fact that the prototypes were nearly one ton overweight, suffered from limited visibility, and were so noisy that the driver was advised to wear ear plugs while in the driver’s chair, despite the fact that doing so would make it nearly impossible to communicate with the EFV’s commander. In fact, so poorly did the EFV fare during the operational assess- ment that the Marines announced they were going back  to the drawing board with the design, aiming to complete a new SDD phase by 2011, eight years behind the original schedule.

Meanwhile, the program’s costs just kept rising. When the EFV was first conceived, the Marines planned to purchase 1,025 of them at a total cost of $8.5 billion. Subsequently, a DoD estimate put the program’s cost at upwards of $14 billion dollars, while the Marines had trimmed their order to 573 vehicles. In effect, even assuming those final figures were to hold, the cost of the EFV had risen from $8.3 million per vehicle to slightly more than $23 million. Overall, the Pentagon estimated it had spent $2.9 billion on the program in R&D and testing costs before buying a single vehicle.

wrong weapon for the wrong war?

The ongoing litany of failures associated with the EFV’s development gave rise to some more fundamental ques- tions about the purpose behind developing the vehicle. Critics argued that the EFV simply did not serve a meaningful role in the modern Marine Corps’ mission. Among their concerns were the following points:

• Modern warfare does not offer options for “storm- ing the beaches,” as the old Marine Corps model envisions. Low-level, regional, or urban conflicts make the need for amphibious assault an anach- ronism in the modern day. As Laura Peterson, a defense analyst with Taxpayers for Common Sense, suggested, “This thing isn’t just fighting the last war, it’s fighting last century’s wars.”

• The advance in cruise missile technology makes the “25 mile offshore” model obsolete. When the EFV was envisioned, it was believed that the Navy could protect its ships by remaining just over the horizon, disembarking EFVs from that distance to assault enemy shores. Critics con- tended that new cruise missiles have a range of over 100 miles, making the EFVs or the Navy’s ships vulnerable to attack if they were to follow the original model.

• The flat bottom of the EFV, necessary for ship-to- shore transportation, makes them extremely vul- nerable to the shaped charges from improvised explosive devices (IEDs), used so effectively in Iraq and Afghanistan. General Dynamics argued that redesigning the bottom of the vehicle would alter its amphibious characteristics.

A number of senior Pentagon officials, including the Commandant of the Marine Corps, stood by the EFV, arguing that the Marine’s “expeditionary” mis- sion will remain alive and in effect into the foreseeable future. The EFV, they believed, was a critical element in the deployment and striking capability of the Marines. However, other high-ranking government officials, including the Secretary of Defense, gave only tepid and qualified support for the continued development and deployment of the EFV.

Final rounds of funding began to limit additional money for the EFV and to tie continued support to the ability of General Dynamics and the Marines to demonstrate much improved reliability and overall system effectiveness. For example, in 2010 the Senate Appropriations Committee authorized $38 million for one more round of tests and set aside $184 million to shut the program down in the event the vehicle failed the tests again. The axe finally fell at the start of 2011, when Secretary Gates sent his preliminary budget to Congress. Among the casualties of the cost-cutting knife was the EFV program. The program had long

178 Chapter 5 • Scope Management

been teetering on the brink, so in a world of smaller Pentagon budgets and more aggressive program over- sight, perhaps it was inevitable that the EFV would finally slip over the edge.27


1. What does the story of the EFV suggest about the importance of considering what a project’s key mission is supposed to be prior to authorizing it?

2. The EFV has been labeled, “The wrong weapon for the wrong war at the wrong time.” Do you agree or disagree with this characterization? Why?

3. Why does the EFV failure illustrate the dangers of long lead-times for weapon systems? In other words, when a project’s development cycle takes 20 years from start to finish, what dangers do the project developers face when the project is finally operational?

Internet exercises

5.1 Go to‐plan/wbs/ and view a short tutorial on developing an effective Work Breakdown Structure. Why does this site specifically warn against creating a laundry list of project activities? What are some of the dangers in creating poor work breakdown structures and the advantages of doing them effectively?

5.2 Go to for-Professional-Services-or-Sow to see a process for describ- ing and creating a Statement of Work for the Minnesota Job Bank Upgrade project. In your opinion, what are some of the critical elements in this Statement of Work? Why? The site also contains an “IT Professional Services Master Contract Work Order.” Why is this work order so detailed?

5.3 Access datawarehouse/docs/dwprojectprocessanddocumentation .pdf. Analyzing the comprehensive Scope Statement for the data warehousing project, what problem is this project seeking to address? What is the proposed solution?

PMP certificAtion sAMPle QUestions

1. What is the lowest level of decomposition in the Work Breakdown Structure called?

a. Work package b. Deliverable c. Subdeliverable d. Project

2. All of the following define a work package EXCEPT: a. A work package has a deliverable result b. It may be considered by its owner as a project in

itself c. A work package may include several milestones d. A work package can be created and addressed re-

gardless of other organizational procedures of cul- tural considerations

3. George has been assigned to be the new project man- ager for our project. He is eager to get off to a good start and wants to identify what activities he should first engage in. How would you advise him to start?

a. Begin with the Work Breakdown Structure (WBS) b. Begin with a clear scope statement

c. Begin with a problem statement and Statement of Work (SOW)

d. Begin with clear work authorization

4. The project manager wants to make sure that he is proceeding in the right order as he moves to develop a clear scope for his project. During scope definition, what should he be doing?

a. Involving stakeholders and verifying that they have all provided their input to the process

b. Developing his WBS and OBS c. Moving as quickly as possible to the determination

of scope reporting methods d. Identifying all necessary vendors for any outsourc-

ing that must be done

5. A hospital expansion is being planned for a com- munity. As part of the scope of this project, it will be necessary to close down the access routes into the emergency room for major remodeling; however, be- cause this is the only hospital for trauma cases within 50 miles, it is not possible to completely shut down the emergency room. The project team will have to find a means to remodel the emergency room while allowing for continuous operations of the unit. This is an example of what?

a. Negotiation points with the owner b. Constraints c. Initial assumptions d. Milestone development

Answers: 1. a—The work package is the lowest level in the Work Breakdown Structure (WBS); 2. d—A work package should fit organizational procedures and culture; 3. c—The project should initiate with a clear problem state- ment and understood SOW supporting it; 4. a—It is criti- cal that all stakeholders have the opportunity to contribute their input to the project during the scope definition phase; 5. b—The need to keep the emergency room open during the remodeling is an example of working around existing project constraints.

MS Project Exercises 179

MS Project exercises

Using the information provided below, construct a simple WBS table for the project example.

Project Outline—Remodeling an Appliance

i. Research Phase A. Prepare product development proposal

1. Conduct competitive analysis 2. Review field sales reports 3. Conduct technological capabilities assessment

B. Develop focus group data c. Conduct telephone surveys d. Identify relevant specification improvements

ii. Design and Engineering Phase A. Interface with marketing staff B. and so on

iii. Testing Phase iv. Manufacturing Phase v. Sales Phase

180 Chapter 5 • Scope Management

appendIx 5.1

Sample Project charter

Project chArter

version history

Version # implemented By revision Date Approved By Approval Date reason

0.1 Sarah Hughes 9/1/15 Initial charter draft

0.2 Sarah Hughes 10/1/15 George Blankenship

10/4/15 Updates per sponsor

0.3 Sarah Hughes 10/15/15 Updates per executive committee

Project title: Project Management Resource Training and Deployment

scope and objectives: The XYZ Corporation has determined that they are understaffed in relation to fully-trained and appropriately deployed project managers. There is an urgent need to identify potential candidates internally and create training programs to develop their project management skills. Further, project managers within the corporation must perceive a career path through the project management function as a means to promotion to higher corporate levels.

overview: Since 2010, business-related commercial projects have increased 55%, resulting in average resource commitment of 31 hours per week on project-related activities. Average project performance since 2010 has been significantly degraded: average cost overrun = 28%, average schedule overrun = 34%, quality failure mitigation costs have increased 24%. Project manager resources have decreased in real numbers from 112 in 2010 to 87 in 2015 (a loss of 22%). Human Resource projections expect that we will see an additional 41 project managers retire within the next three years. XYZ Corporation cannot continue to sustain the losses from project ventures, coupled with the loss of senior project personnel. This project was initiated to begin identifying and training a replacement cohort of project managers.

general objectives:

1. Identify potential project managers from within Engineering, Commercial, and Supply Chain functions.

2. Determine the critical skill set that successful project managers need at XYZ. 3. Develop training programs to promote the critical project management skill set.

specific objectives:

1. Identify potential project managers. a. Determine strong candidates through mentoring and past experience on projects. b. Enlist their willingness to commit to project management as a career path. c. Develop “candidate ready” list and “potential future candidate” list.

2. Determine critical project management skills. a. Survey leaders and team members of past successful projects. b. Work with local university faculty to create database of critical skills.

3. Initiate project manager training program. a. Secure top management support and funding. b. Identify appropriate HR staff and university faculty for training.

defining conditions and constraints: Project management resource training and deployment program must be operational within six months of approval. The program will occur in three phas- es: (1) project management skill survey, (2) candidate identification, and (3) program development. All elements of the survey and candidate identification must be completed before formal approval of the training initiatives. Final phase will be collaboration with industry experts and university faculty on formal training.

Appendix 5.1 Sample Project Charter 181

Project organization: Key members of the project team are:

1. Sponsor: George Blankenship, VP of Human Resources 2. Project Manager: Sarah Hughes, Senior Engineer 3. Disciplinary Representatives: Teresa Connelly, Supply Chain

a. Teresa Connelly, Supply Chain and Procurement b. Vince Walters, Commercial c. Evan Telemann, Engineering

4. Team members: No more than two additional team members from the disciplinary functions will be appointed, based on recommendations from the disciplinary representatives. All team members will be 100% dedicated to the project for a period of not less than 90 business days.

Project Manager responsibilities:

1. Staffing – The project manager is ultimately responsible for the performance of all members of the team and will be granted authority, in collaboration with each person’s current disci- plinary manager, to complete a performance appraisal for the calendar year. The project man- ager is authorized to use one member of the clerical staff on a half-time (20 hours) basis per week for the duration of the project. Additional staff support may be available upon request.

2. Budget – The estimated budget for this project, including fully loaded personnel charges, is $240,000, to be charged against the Human Resources budget in three equal monthly install- ments. Additional budget money may be available upon formal request submitted jointly by the project manager and sponsor to the executive committee.

3. Status Updates – All communications on project status must be made to the chief executive officer. Additionally, monthly updates on the project status will be made at executive com- mittee meetings.

4. Planning/Tracking – The project will use standard corporate tracking software (MS Project) and will report on schedule, exception reports, slippages, and cost performance. Additionally, earned value metrics (SPI and CPI) will be employed throughout the project duration.

5. Change Control and Configuration – The project manager will have authority to make changes to the project provided they do not exceed $2,500 and have no negative impact on the project schedule. Otherwise, changes to the project scope or development must receive sponsor approval.

6. Project Plan – A formal project plan, including statement of work (SOW), risk assessment and mitigation, work breakdown structure (WBS), schedule, and budget must be submitted to the sponsor not later than June 15.

Authority: The project manager will have full authority to identify necessary tasks and resources needed to help complete these assignments. Where resource conflicts occur, the sponsor and other disciplinary VPs will resolve them.


Vice President Engineering ________________________________________

Vice President Supply Chain and Procurement ________________________________________

Vice President Commercial ________________________________________

Vice President Human Resources ________________________________________

President and CEO ________________________________________

182 Chapter 5 • Scope Management

iNteGrAteD Project

Developing the Work Breakdown Structure Develop a Work Breakdown Structure for your project based on the identified goals from the first assign- ment. Provide a detailed assessment of the various components of the project, going down through the work package stage to tasks and subtasks (if appropriate). Next, assess the personnel needs for the project. How many core team members will be necessary to achieve the project’s goals? What are their positions within the organization? Remember to use the project scope as the basis for determining all the elements of the project, the personnel responsible for each component, and the associated budget for each task.

In addition to identifying the tasks and key personnel requirements for the project, construct a Respon- sibility Assignment Matrix (RAM) that demonstrates the interrelationship among project team members.

SAMPle Work BreAkDoWN StrUctUre—ABcUPS, iNc.

Personnel table

Name Department title

Carol Johnson Safety Safety Engineer

Bob Hoskins Engineering Industrial Engineer Sheila Thomas Management Project Manager Randy Egan Management Plant Manager Stu Hall Industrial Maintenance Supervisor Susan Berg Accounting Cost Accountant Marty Green Industrial Shop Supervisor John Pittman Quality Quality Engineer Sally Reid Quality Jr. Quality Engineer Lanny Adams Sales Marketing Manager Kristin Abele Purchasing Purchasing Agent

Work BreAkDoWN StrUctUre—ABcUPS’ ProceSS MoDificAtioN

Process Modification Project 1000

Deliverable 1 feasibility Study 1010

Work Package 1 Conduct feasibility study 1011

Work Package 2 Receive technical approval 1012

Work Package 3 Get administrative sign-off 1013

Deliverable 2 Vendor Selection 1020

Work Package 1 Research equipment 1021

Work Package 2 Qualify suppliers 1022

Work Package 3 Solicit quotes from suppliers 1023

Work Package 4 Negotiate price and terms 1024

Work Package 5 Approval and contracts 1025

Deliverable 3 Design 1030

Work Package 1 Factory floor redesign 1031

Work Package 2 Drawings 1032

Work Package 3 Process redesign approval 1033

Deliverable 4 engineering 1040

Work Package 1 Conduct process flow evaluation 1041

Work Package 2 Determine site for equipment 1042

Responsibility Assignment Matrix

Sheila Susan Bob Lanny

Del 1010

Del 1020

Del 1030

Del 1040

Del 1050

Del 1060

Del 1070

Del 1080





Work Package 3 Retooling 1043

Work Package 4 Final layout approval 1044

Deliverable 5 Prototype testing 1050

Work Package 1 Build inventory bank 1051

Work Package 2 Set up trial run 1052

Work Package 3 Trial run 1053

Work Package 4 Quality assessment 1054

Work Package 5 Process documentation 1055

Deliverable 6 Packaging 1060

Work Package 1 Design new packaging 1061

Work Package 2 Coordinate with marketing 1062

Work Package 3 Part assembly 1063

Work Package 4 Packaging approval 1064

Deliverable 7 Sales and Service 1070

Work Package 1 Beta-test products 1071

Work Package 2 Sales approval 1072

Work Package 3 Customer approval 1073

Deliverable 8 initiate changeover 1080

Work Package 1 Assemble inventory 1081

Work Package 2 Cancel vendor contracts 1082

Work Package 3 Close out project 1083

Work Package 4 Develop lessons learned 1084

Integrated Project 183

184 Chapter 5 • Scope Management

1. Thorp, F. (2013, October 31). “Only 6 able to sign up on’s first day, documents show,” NBC News. healthcare-govs-first-day-documents-show-f8C11509571; Reinen, J. (2013, September 9). “Obamacare is the worst new-product rollout in memory,” Minnpost. www. new-product-rollout-memory; Jones, W. (2013, October 7). “Obamacare exchange sign-ups hobbled by IT sys- tems not ready for prime time,” IEEE Spectrum. http:// exchange-signups-not-so-much; Lane, D. (2014, January 15). “Cover Oregon head:  State might scrap all or part of failing website,” investigators/Cover-Oregon-head-State-might-scrap-all- or-part-of-failed-website-240348071.html; Lane, D. (2014, January 30). “‘We look like fools:’ A history of Cover Oregon’s failure,”; investigators/We-look-like-fools-A-history-of-Cover- Oregons-failure-239699521.html; Shepheard, C. (2014, June 4). “Oregon’s health exchange failed so terribly, there’s now a federal investigation,” Care2. www.care2. com/causes/oregons-health-exchange-failed-so-terribly- theres-now-a-federal-investigation.html

2. Project Management Institute. (2013). “Scope Management,” Project Management Body of Knowledge (PMBoK). Upper Darby, PA: Project Management Institute; Westney, R. E. (1993). “Paradigms for planning productive projects,” in Dinsmore, P. C. (Ed.), The AMA Handbook of Project Management. New York: AMACOM.

3. Kerzner, H. (2001). Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 7th ed. New York: Wiley; Mepyans-Robinson, R. (2010). “Project scope management in practice,” in Dinsmore, P. C., and Cabanis-Brewin, J. (Eds.), The AMA Handbook of Project Management, 3rd ed. New York: AMACOM, pp. 79–87; Cleland, D. I., and Kimball, R. K. (1987). “The strategic context of projects,” Project Management Journal, 18(3): 11–30.

4. Project Management Institute (2000), as cited in note 2. 5. Stuckenbruck, L. C. (1981). The Implementation of Project

Management: The Professional’s Handbook. Boston, MA: Addison-Wesley; Laufer, A. (1991). “Project planning: Timing issues and path of progress,” Project Management Journal, 22(2): 39–45.

6. Martin, M. G. (1998). “Statement of work: The foundation for delivering successful service projects,” PMNetwork, 12(10): 54–57.

7. statement-of-work.pdf/

8. Project Management Institute (2013), as cited in note 2. 9. Department of Defence, Handbook For Preparation of

Statement of Work, USA. MILHDBK-245D. (1996, April 3) Superseding MIL-HDBK-245C (1991, Sep 10). https:// DODhandbook.pdf

10. Duncan, W. R. (1994). “Scoping out a scope statement,” PMNetwork, 8(12): 24–27; Wideman, R. M. (1983). “Scope management,” Project Management Quarterly, 14: 31–32;

Pinto, J. K. (1999). “Project scope management,” in Pinto, J. K. (Ed.), The Project Management Institute’s Project Management Handbook. San Francisco, CA: Jossey-Bass, pp. 109–18.

11. Lavold, G. D. (1988). “Developing and using the work breakdown structure,” in Cleland, D. I., and King, W. R. (Eds.), Project Management Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp. 302–23.

12. Obradovitch, M. M., and Stephanou, S. E. (1990). Project Management: Risks & Productivity. Bend, OR: Daniel Spencer.

13. Project Management Body of Knowledge. (2008). Project Management Institute: Newton Square, PA.

14. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Management, 5th ed. New York: Wiley.

15. Globerson, S. (2001). “Scope management: Do all that you need and just what you need,” in Knutson, J. (Ed.), Project Management for Business Professionals. New York: Wiley, pp. 49–62.

16. Obradovitch, M. M., and Stephanou, S. E. (1990). Project Management: Risks & Productivity. Bend, OR: Daniel Spencer.

17. Project Management Institute (2010), as cited in note 2. 18. Yourdon, E. (2004). Death March, 2nd ed. Upper Saddle

River, NJ: Prentice-Hall. 19. Kidd, C., and Burgess, T. F. (2004). “Managing configu-

rations and data for effective project management,” in Morris, P. W. G., and Pinto, J. K. (Eds.), The Wiley Guide to Managing Projects. New York: Wiley, pp. 498–513.

20. Meredith, J. R., and Mantel, Jr., S. J. (2003), as cited in note 14.

21. Frame, J. D. (2001). “Requirements management: Addressing customer needs and avoiding scope creep,” in Knutson, J. (Ed.), Project Management for Business Professionals. New York: Wiley, pp. 63–80.

22. Kidd, C., and Burgess, T. F. (2004), as cited in note 19. 23. Turner, R. (2000). “Managing scope—Configuration and

work methods,” in Turner, R. (Ed.), Gower Handbook of Project Management, 3rd ed. Aldershot, UK: Gower.

24. Antonioni, D. (1997). “Post-project review prevents poor project performance,” PMNetwork, 11(10).

25. Kouri, J. (2010, November 11). “Border ‘virtual fence’ project a costly failure.” border-% E2%80%9Cvirtual-fence%E2%80%9D-project-a- costly-failure/; Krigsman, M. (2007, August 23). “Boeing virtual fence: $30 billion failure.” blog/project failures/boeing-virtual-fence-30-billion- failure/36; Krigsman, M. (2007, September 24). “Update: Boeing’s virtual fence ‘unusable.’” blog/projectfailures/update-boeing-virtual-fence-unus- able/403; Lipowicz, A. (2010, April 21). “Senate committee chairman suggests killing Boeing’s virtual fence.” http:// articles/2010/04/21/lieber- man-calls-sbinet-virtual-fence-a-failure.aspx; Richey, J. (2007, July 7). “Fencing the border: Boeing’s high-tech plan falters.” immigrationandlabor/1243/fencing_the_ border%3A _boeing%27s_high-tech_plan_falters

26. California High-Speed Rail Authority Web site, www.; Castaneda, V., and


Notes 185

Severston, A. (2010, October 11). “Economists say high- speed rail system won’t make money.” http://menlopark. sys- tem-will-never-achieve-positive-cash-flow; Enthoven, A., Grindley, W., and Warren, W. (2010). “The financial risks of California’s proposed high-speed rail.” org/assets/pdf/CHSR-Financial_Risks-101210-D.pdf; Garrahan, M. (2009, October 6). “California keen to set the pace.” Financial Times, b28a-11de-b7d2-00144feab49a.html#axzz18CGc6USH; Mitchell, J. (2010, December 13). “At start of rail project, a tussle over where to begin.” Wall Street Journal, http:// 11871825514428.html; “Subsidy trains to nowhere.” (2010, December 11–12). Wall Street Journal, p. A14; Weikel, D. (2010, December 10). “U.S. shifts $624 million to California bullet train.” Los Angeles Times, dec/10/local/la-me-high-speed-money-20101210; Rosenberg, M. (2013, April 3). “California high-speed rail costs soar again—this time just for planning.” San Jose Mercury News.

california-high-speed-rail-costs-soar-again-this; Reason Foundation (2013, April 11). “Study: California high-speed rail system would lost $124 to 373 million a year.” http://

27. Feickert, A. (2008). “The Marines’ Expeditionary Fighting Vehicle (EFV): Background and issues for Congress.” Congressional Research Service, Library of Congress. www. Doc.pdf&AD=ADA486513; Hodge, N. (2010, August 27). “Marines question craft needed to hit the beach,” Wall Street Journal, p. B8; marines-swimmin/; Merle, R. (2007). “Problems stall Pentagon’s new fighting vehicle.” www.washing- AR2007020601997.html; Ackerman, S. (2010). “Senate may finally sink Marines’ swimming tank.” dangerroom/ 2010/09/senate-may-finally-sink-marines- swimming- tank/; cludes/articlePrint. jsp?storyID=news/asd/2010/11/08/01. xml&headLine=null; story.jsp?id=news/asd/2010/10/12/08.xml&channel=misc.


6 ■ ■ ■

Project Team Building, Conflict, and Negotiation

Chapter Outline Project Profile

Engineers Without Borders: Project Teams Impacting Lives

introduction 6.1 Building the Project team

Identify Necessary Skill Sets Identify People Who Match the Skills Talk to Potential Team Members and Negotiate

with Functional Heads Build in Fallback Positions Assemble the Team

6.2 characteristics of effective Project teams A Clear Sense of Mission A Productive Interdependency Cohesiveness Trust Enthusiasm Results Orientation

6.3 reasons Why teams fail Poorly Developed or Unclear Goals Poorly Defined Project Team Roles and

Interdependencies Lack of Project Team Motivation Poor Communication Poor Leadership Turnover Among Project Team Members Dysfunctional Behavior

6.4 stages in grouP develoPment Stage One: Forming Stage Two: Storming Stage Three: Norming Stage Four: Performing

Stage Five: Adjourning Punctuated Equilibrium

6.5 achieving cross-functional cooPeration Superordinate Goals Rules and Procedures Physical Proximity Accessibility Outcomes of Cooperation: Task and

Psychosocial Results 6.6 virtual Project teams Project Profile

Tele-Immersion Technology Eases the Use of Virtual Teams

6.7 conflict management What Is Conflict? Sources of Conflict Methods for Resolving Conflict

6.8 negotiation Questions to Ask Prior to the Negotiation Principled Negotiation Invent Options for Mutual Gain Insist on Using Objective Criteria

Summary Key Terms Discussion Questions Case Study 6.1 Columbus Instruments Case Study 6.2 The Bean Counter and the Cowboy Case Study 6.3 Johnson & Rogers Software

Engineering, Inc. Exercise in Negotiation Internet Exercises PMP Certification Sample Questions Notes

Chapter Objectives After completing this chapter, you should be able to:

1. Understand the steps involved in project team building. 2. Know the characteristics of effective project teams and why teams fail. 3. Know the stages in the development of groups. 4. Describe how to achieve cross-functional cooperation in teams. 5. See the advantages and challenges of virtual project teams. 6. Understand the nature of conflict and evaluate response methods. 7. Understand the importance of negotiation skills in project management.

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Plan Human Resource Management (PMBoK sec. 9.1) 2. Acquire Project Team (PMBoK sec. 9.2) 3. Develop Project Team (PMBoK sec. 9.3) 4. Manage Project Team (PMBoK sec. 9.4)

Project Profile

engineers Without Borders: Project teams impacting lives

In 2000, Bernard Amadei, a civil engineering professor at the University of Colorado at Boulder, visited San Pablo, Belize, where the sight of little girls hauling water instead of attending school broke his heart. Upon his return to Boulder, he recruited eight civil and environmental engineering students to design and install a clean water system powered by a local waterfall. The total cost, including airfare for him and his students, came to US$14,000.

It was just the beginning for Amadei, who went on to found Engineers Without Borders–USA in 2002. The orga- nization now inspires nearly 14,000 members in over 250 chapters around the country. The more than 350 programs currently underway lean heavily toward civil engineering—a farm irrigation system in Bolivia, a geothermal heating system for a Native American tribe in South Dakota—but some, such as small hydroelectric systems and rooftop solar panel installations, require the skills of electrical engineers. By the latest reckoning, EWB-USA has impacted for the bet- ter the lives of over 2.5 million people worldwide.

The U.S. organization follows in the footsteps of a movement that began in France in the 1980s and then spread to Spain, Italy, Canada, and many other countries. The organizations were quite independent, though, sharing only a name and a mission, so in 2004 Amadei created an informal network, EWB-International. Today it has 45 member groups, including ones in Kosovo, Rwanda, and Iran.

“Amadei tapped into a previously unexploited humanitarian passion within the U.S. engineering community,” says Peter Coats, a civil engineer and cofounder of EWB-USA’s San Francisco chapter, the first to consist of profession- als instead of students. That higher purpose is particularly attractive to women, who make up more than 40 percent of student volunteers, twice the proportion of female engineering graduates. “They identify more with people and humanity,” says Cathy Leslie, a civil engineer who serves as the executive director of EWB-USA. “Women don’t thrive on creating technology for technology’s sake.”

Communities or local non-government organizations (NGOs) provide EWB-USA with a wish list of needs, and the organization plays matchmaker, helping pair chapters with specific projects. Clean water tops the list—establishing sewage systems, sanitation systems for collecting and disposing of waste, and irrigation canals. Cheap, renewable sources of electricity are also a common need.

These projects can’t be built in a day, and like almost all engineering work, they need to be maintained and upgraded, so there is an emphasis on imparting knowledge to local community members and NGOs. For this, project teams include trainers and business folks in addition to engineers. “You establish a sort of trust, which is really power- ful,” says Eyleen Chou, the president of the University of Wisconsin–Madison’s student chapter. “There’s no reason why you shouldn’t stay 10 years or longer.”

Leslie says that successful chapters such as Chou’s can build and maintain many projects despite a constant rota- tion of entering freshmen and departing seniors. They establish training programs and mentorships, devise ways for


Project Profile 187

188 Chapter 6 • Project Team Building, Conflict, and Negotiation


The difficulties involved in building and coordinating an effective team can be daunting and highly complex. Becoming technically proficient at scheduling, budgeting, and project evaluation is essential in developing the necessary project management skills; however, it is equally impor- tant to develop an appreciation for and willingness to undertake the human challenges of the job. team building and conflict management are two of the most important people skills that project managers can cultivate, but they are also two of the most difficult undertakings. We must use our leadership skills to negotiate with department managers for access to skilled personnel for team staffing; we must recognize that no project team comes “fully assembled” and ready to go. Simply grouping a collection of diverse individuals together is not the same thing as building a team.

This chapter offers an overview of some of the key behavioral tasks facing project managers: staffing a project team, building a sense of common purpose and shared commitment, encouraging cross-functional cooperation among team members, and recognizing the causes of and resolving conflicts among all project stakeholders. The bad news is that this is not an easy process; it does not involve formulas or calculations in the same way that task duration estimation does. The “rules” of

FIgure 6.1 eWB Project team laying Water Pipes with local Workers

Source: Dieter Heinemann/Westend61/Corbis

new students to contribute, and find sustainable funding. Chapters are expected to raise the majority of project money themselves, but they work under basic guidelines. At a project’s onset, they consult with an EWB-USA technical advisory committee to tweak and finalize plans. Teams must commit five years to a project.

In addition to the student chapters at universities, EWB-USA maintains a number of professional chapters around the country. However, maintaining effective, temporary teams is a challenge; especially for a volunteer organization. Professional chapters have problems of bringing new volunteers up to speed while experienced ones drop out—and their members face the additional challenge of juggling their project work with full-time jobs. For example, the San Francisco chapter’s members typically spend at least five hours per week, but this can spike during special events or an actual field visit. Members have on occasion spent over 30 hours a week on EWB activities in addition to working their regular jobs.

In the process of improving others’ lives, EWB is also creating a better brand of engineer, says Leslie. “The work we do has educational value for the student,” she says, and taking a professional out of the office “makes for a more well-rounded engineer.”1

6.1 Building the Project Team 189

human behavior often consist of broad generalizations, at best, which should be used only to sug- gest appropriate managerial actions. The good news is that when carefully evaluated and applied, managing the people side of project management can be just as effective, rewarding, and important for project success as any of the technical duties.

Project staffing, team building, cross-functional cooperation, and conflict management are not supplementary topics in project management; the study of these skills is central to our ability to become proficient in a highly complex and challenging profession. This chapter will not only analyze the team building and conflict processes, but it will also offer some prescriptive advice to readers on how to improve these processes and skills in managing human behavior. One point is clear: If we undertake projects with a project team as our principal resource for getting work done and the project completed, it is vital that we learn everything possible about how to mold people into a high-performing team and how to control the inevitable conflicts that are likely to emerge along the way.

6.1 BuIldIng the Project team

Effective project teams do not happen by accident. A great deal of careful work and preparation goes into the steps necessary to first staff and then develop project team members to the point where they begin to function jointly and the project reaps positive dividends from their collec- tive performance. The best-case scenario for project managers is to take over a project with a uni- fied team composed of individuals who lobbied for and were awarded with membership on the team. Unfortunately, in many organizations, project teams are put together based on other criteria, most notably whoever is available. Regardless of the circumstances, the project manager is faced with the challenge of creating from a set of diverse individuals a high-performing, cohesive proj- ect team. The preferred process, however, should be as structured as possible; staffing is ideally aligned with the project manager’s judgment of what is best for the project.

Figure 6.2 illustrates how project team personnel may be assigned. Within many organiza- tions, this process emerges as the result of protracted negotiations with functional or departmental supervisors, as we discussed in Chapter 2. The flowchart in Figure 6.2 illustrates several key deci- sion points or critical interfaces in developing a project team.2

Identify necessary Skill Sets

The first stage in project team development is to conduct a realistic assessment of the types of skills the team members will need in order to complement each other and perform their project duties as effectively as possible. For example, in projects with a high technical complexity, it is imperative to ascertain the availability of skilled human resources and their capability of adding value to the project development. No one would seriously embark on a software development project without first ensuring that the technical steps in the project are clearly understood.

Identify People Who match the Skills

Once a reasonable assessment of the required project skills has been completed, a complemen- tary assessment of the availability of personnel with the requisite skills is necessary. We have two options: (1) hire new personnel for the project (e.g., in many cases, companies will hire con- tractors on a fixed-term basis for the life of a project), or (2) train current personnel to become proficient in the skills they will need to perform the tasks. The final decision often comes down to a cost/benefit assessment: Who can do the work? Is the cost of hiring or training the person to do the job prohibitively expensive? Once the person has been trained/hired, will these skills be of continuing benefit to the company?

talk to Potential team members and negotiate with Functional heads

The third step in the process of building the project team involves opening communication with likely candidates for the team and assessing their level of interest in joining the project. In some cases, personnel have a great deal of authority in assigning their own time to projects. However, in most cases (particularly within functional organizations), all functional specialists are under the authority of departmental heads. Consequently, at some point the project manager must begin

190 Chapter 6 • Project Team Building, Conflict, and Negotiation

to enter into negotiations with these functional heads for the services of prospective project team members. These negotiations can be complex and lengthy.

Departmental managers generally are not opposed to the use of their personnel on proj- ects. They are, however, primarily concerned with the smooth operations of their organizations. Depriving a functional manager of key personnel to serve on a project team can be seen as threat- ening a smoothly operating department. Hence, negotiations are required. Among the issues to be decided are:

1. How long are the team members services required? Project team members can be assigned on a full-time basis (40 hours per week) or a part-time basis (less than 40 hours per week). Further, the team member may be assigned for a fixed period (e.g., six months) or for the duration of the project.

Identify skills required (from WBS)

Identify personnel to match the skills

Talk to potential team members

Negotiate with the functional supervisor

Renegotiate with top management

Notify top management of consequences

Try to get partial assistance

Adjust project schedule, budget, and/or priorities



Assemble the team

• Develop skills inventory matrix • Develop responsibility matrix • Clarify roles • Clarify methods and procedures





• From permanently assigned staff or functional groups

• Explain nature of project and gauge their interest

FIgure 6.2 Basic Steps in Assembling a Project team

Source: V. K. Verma. (1997). Managing the Project Team, p. 127. Upper Darby, PA: Project Management Institute. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

6.1 Building the Project Team 191

2. Who should choose the person to be assigned to the project? Another point of negotiation is the question of who should select the individual to serve on the project team. The func- tional manager may have her own ideas as to the best choice, while the project manager may employ different criteria and come up with other possible candidates.

3. What happens when special circumstances arise? In the event of some emergency or spe- cial circumstance, the functional department head may wish to retain control of the team member or have the option of suddenly recalling that individual back to work on departmen- tal activities. How will “emergencies” be defined? If the team member is recalled, how will the department provide a replacement? What is the maximum amount of time a team mem- ber can be removed from his project duties? All these questions are important and should be resolved prior to the appointment of project team members.

Most project resources are negotiated with department managers. This point is critical: For the majority of project managers, their outright control over project team members may be limited, particularly early in the process when project team assignments are being made. The best strategy a project manager can engage in at this point is to have thought carefully about the types of exper- tise and skills that will be required for successful completion of the project and begin bargaining with these clear goals in mind. Treat functional managers as allies, not opponents. The organiza- tion supports the project; functional departments will support it as well, but their level of support must be carefully planned in advance.

Build in Fallback Positions

What are your options as the project manager when resources are not available? Suppose, for example, that you need three highly trained design engineers for the project and the head of engi- neering is unwilling to part with them or negotiate a compromise. As Figure 6.2 demonstrates, in the event that negotiations with functional managers and top managers are not fruitful, the project manager is faced with three basic alternatives.

try to negotIate For PartIal aSSIStance The best alternative to an outright refusal is to seek some limited assistance. One reason for this approach is that it gets your foot in the door. Once the personnel are assigned to the project, even on limited terms, it forms the basis for your returning to the department head at a later point to ask for them again, while only slowing down the project marginally. This principle argues, in effect, that it is better to have half a loaf than none.

adjuSt Project ScheduleS and PrIorItIeS accordIngly When critical resources are not available, the project schedule must be adjusted to reflect this fact. As we will note in Chapter 12, “Resource Management,” there is no point in developing a sophisticated project schedule if it is not supported by resources. Or, to put it another way, until we can match people to project tasks, we cannot make progress. With a failure to convince functional managers that their resources are needed to support the project, serious and honest adjustments must be made to all project plans, including scope documents, schedules, risk assessment, and so forth.

notIFy toP management oF the conSequenceS Failing to gain necessary resources must be reported to top management, the ultimate sponsors of the project. They may, in the end, become the final arbiters of the resource and staffing question. In the face of persistent resistance from a functional manager, the only recourse may be to present to top management, as candidly as possible, the implications for project success without sufficient support. The final decision then comes down to top management: They will either support the project and require that staffing be completed as requested, suggest a compromise, or support the functional manager. In the first two cases, the project will proceed; in the third, top management is effectively ending the project before it has begun.

assemble the team

When the project has been staffed and approved, the final step is assembling the project team. This involves developing a skills inventory matrix that identifies the skills needed for the project against the skills we have acquired and a responsibility matrix using the Responsibility Activity

192 Chapter 6 • Project Team Building, Conflict, and Negotiation

Matrix (RAM) methodology (discussed in Chapter 5). Also, all project team roles and responsibili- ties must be clarified, along with all project team methods, expectations, and standard operating procedures. Where any of these do not exist, it will be necessary to begin establishing them.

6.2 characterIStIcS oF eFFectIve Project teamS

A great deal of research has investigated the qualities that effective teams possess and how those same qualities are missing from less effective groups. Successful teams share common underlying features, including a clear sense of mission, an understanding of team interdependencies, cohe- siveness, a high level of trust, a shared sense of enthusiasm, and a results orientation.

a clear Sense of mission

A key determinant of project success is a clear project mission.3 Further, that sense of mission must be mutually understood and accepted by all team members. Research has demonstrated that a clearly understood project mission is the number one predictor of success as the project is being developed.4 Two important issues are clear: First, project teams perform well when there is a clear sense of purpose or objectives for their project; and second, the more widely shared and under- stood those goals, the better the project performance. The alternative is to allow the project man- ager to function as the hub of a wheel, with each team member as a separate spoke, interacting only through the project manager. This arrangement is not nearly as useful or successful as one in which all project team members understand the overall project objectives and how their perfor- mance contributes to achieving those objectives.

A mistake sometimes made by project managers is to segment the team in terms of their duties, giving each member a small, well-specified task but no sense of how that activity contrib- utes to the overall project development effort. This approach is a serious mistake for several impor- tant reasons. First, the project team is the manager’s best source for troubleshooting problems, both potential and actual. If the team is kept in the dark, members who could potentially help with the smooth development of the project through participating in other aspects of the installa- tion are not able to contribute in helpful ways. Second, team members know and resent it when they are being kept in the dark about various features of the project on which they are working. Consciously or not, when project managers keep their team isolated and involved in fragmented tasks, they are sending out the signal that they either do not trust their team or do not feel that their team has the competence to address issues related to the overall implementation effort. Finally, from a “firefighting” perspective, it simply makes good sense for team leaders to keep their people abreast of the status of the project. The more time spent defining goals and clarifying roles in the initial stages of the team’s development, the less time will be needed to resolve problems and adju- dicate disputes down the road.

a Productive Interdependency

Interdependency refers to the degree of joint activity among team members that is required in order to complete a project. If, for example, a project could be completed through the work of a small number of people or one department in an organization, the interdependence needed would be considered low. In most situations, however, a project manager must form a team out of members from various functional areas within the organization. For example, an IT project introduction at a large corporation could conceivably require the input or efforts of a team that included members from the Information Systems department, engineering, accounting, marketing, and administra- tion. As the concept of differentiation suggests, these individuals each bring to the team their pre- conceived notions of the roles that they should play, the importance of their various contributions, and other parochial attitudes.

interdependencies refer to the degree of knowledge that team members have and the impor- tance they attach to the interrelatedness of their efforts. Developing an understanding of mutual interdependencies implies developing a mutual level of appreciation for the strengths and contri- butions that each team member brings to the table and is a precondition for team success. Team members must become aware not only of their own contributions but also of how their work fits into the overall scheme of the project and, further, of how it relates to the work of team members from other departments.

6.2 Characteristics of Effective Project Teams 193


cohesiveness, at its most basic level, simply refers to the degree of mutual attraction that team members hold for one another and their task. It is the strength of desire all members have to remain a team. It is safe to assume that most members of the project team need a reason or reasons to contribute their skills and time to the successful completion of a project. Although they have been assigned to the project, for many individuals, this project may compete with other duties or responsibilities pulling them in other directions. Project managers work to build a team that is cohesive as a starting point for performing their tasks. Since cohesiveness is predicated on the attraction that the group holds for each individual member, managers need to make use of all resources at their disposal, including reward systems, recognition, performance appraisals, and any other sources of organizational reward, to induce team members to devote time and energy in furthering the team’s goals.


Trust means different things to different people.5 For a project team, trust can best be understood as the team’s comfort level with each individual member. Given that comfort level, trust is mani- fested in the team’s ability and willingness to squarely address differences of opinion, values, and attitudes and deal with them accordingly. Trust is the common denominator without which ideas of group cohesion and appreciation become moot. The interesting point about trust is that it can actu- ally encourage disagreement and conflict among team members. When members of a project team have developed a comfort level where they are willing to trust the opinions of others, no matter how much those opinions diverge from their own, it is possible to air opposing views, to discuss issues, and even to argue. Because we trust one another, the disagreements are never treated as personal attacks; we recognize that views different from our own are valuable and can contribute to the proj- ect. Of course, before positive results can come from disagreement, we have to develop trust.

There are a number of ways in which project team members begin to trust one another. First, it is important for the project manager to create a “What happens here, stays here” mentality in which team members are not worried that their views will be divulged or confidences betrayed. Trust must first be demonstrated by the professionalism of the project manager and the manner in which she treats all team members. Second, trust develops over time. There is no way to jump- start trust among people. We are tested continuously to ensure that we are trustworthy. Third, trust is an “all-or-nothing” issue. Either we are trustworthy or we are not. There is no such thing as being slightly trustworthy. Finally, trust occurs on several levels:6 (1) trust as it relates to profes- sional interaction and the expectation of another person’s competence (“I trust you to be able to accomplish the task”), (2) trust that occurs on an integrity level (“I trust you to honor your commit- ments”), and (3) trust that exists on an emotional level based on intuition (“It feels right to allow you to make this decision”). Hence, it is important to recognize that trust among team members is complex, takes time to develop, is dependent on past history, and can occur on several levels, each of which is important to developing a high-performing team.


Enthusiasm is the key to creating the energy and spirit that drive effective project efforts. One method for generating team enthusiasm is to promote the idea of efficacy, the belief that if we work toward certain goals, they are attainable. Enthusiasm is the catalyst for directing positive, high energy toward the project while committing to its goals. Project managers, therefore, are best able to promote a sense of enthusiasm within the project team when they create an environment that is:

• Challenging—Each member of the project perceives his role to offer the opportunity for professional or personal growth, new learning, and the ability to stretch professionally.

• Supportive—Project team members gain a sense of team spirit and group identity that creates the feeling of uniqueness with regard to the project. All team members work collaboratively, communicate often, and treat difficulties as opportunities for sharing and joint problem solving.

• Personally rewarding—Project team members become more enthusiastic as they perceive personal benefits arising from successful completion of the project. Linking the opportunity for personal advancement to project team performance gives all team members a sense of ownership of the project and a vested interest in its successful completion.

194 Chapter 6 • Project Team Building, Conflict, and Negotiation

The importance of enthusiasm among project team members is best illustrated by a recently witnessed example. A team leader had been charged with reengineering a manufacturing process at a large production plant in New England. Despite his initial enthusiasm and energy, he was getting increasingly frustrated with his project team, most of them having been assigned to him without any of his input on the assignments. His chief concern became how to deal with the constant litany of “We can’t do that here” that he heard every time he offered a suggestion for changing a procedure or trying anything new. One Monday morning, his team members walked into the office to the vision of the words “YES WE CAN!” painted in letters three feet high across one wall of the office. (Over the weekend, the project manager had come in and done a little redecorating.) From that point on, the motto YES WE CAN! became the theme of the team and had a powerful impact on project success.

results orientation

Results orientation suggests that each member of the project team is committed to achieving the project’s goals. The project manager can influence team performance in many ways, but it is through constantly emphasizing the importance of task performance and project outcomes that all team members are united toward the same orientation. Some have referred to this phenomenon as the “eyes on the prize” attitude, a commonly held characteristic among successful project teams. The benefit of a results orientation is that it serves to continually rally team members toward the important or significant issues, allowing them to avoid squandering time and resources on prob- lems that may be only peripheral to the major project goals.

6.3 reaSonS Why teamS FaIl

Because the challenges involved in creating high-performing project teams are so profound, it is not surprising that project teams fail to perform to their potential in many circumstances. Teams operate at less than optimum performance for a number of reasons, including poorly developed or unclear goals, poorly defined project team roles and interdependencies, lack of project team motivation, poor communication or leadership, turnover among team members, and dysfunctional behavior.7

Poorly developed or unclear goals

One of the most common causes of project team failure is the absence of clear and commonly understood project goals. When the project goals are fragmented, constantly changing, or poorly communicated, the result is a high degree of ambiguity. This ambiguity is highly frustrating for project team members for a number of reasons.

unclear goalS PermIt multIPle InterPretatIonS The most common problem with poorly developed goals is that they allow each team member to make separate and often differing inter- pretations of project objectives. As a result, rather than helping the team to focus on the project at hand, these goals actually serve to increase disagreements as each team member interprets the project’s goals in different ways.

unclear goalS ImPede the WIllIngneSS oF team memBerS to Work together When team members are faced with ambiguous goals, it is common for each person to interpret the goals in the most advantageous way. When goals are used to support individuals rather than team objectives, it often leads to situations in which one person’s desire to satisfy the project goals as he interprets them actually conflicts with another team member’s desire to satisfy her goals.

unclear goalS IncreaSe conFlIct Project team conflict is heightened by vague goals that allow for multiple, self-centered interpretations. Rather than working on completing the project, team members expend energy and time in conflict with one another sifting through project objectives.

Poorly defined Project team roles and Interdependencies

Team interdependencies is a state where team members’ activities coordinate with and comple- ment other team members’ work. To some degree, all team members depend on each other and must work in collaboration in order to accomplish project goals. High-performing teams are well

6.3 Reasons Why Teams Fail 195

structured in ways that leave little ambiguity about individual roles and responsibilities. When team member assignments or responsibilities are not made clear, it is natural for disagreements to occur or for time to be wasted in clarifying assignments. Another serious problem with poorly defined roles is that it allows for significant time to be lost between project activities. When team members are unaware of their roles and interdependencies in relation to other team members, it is common to lose time on the project through poor transitions, as tasks are completed and succes- sors are expected to begin.

lack of Project team motivation

A common problem with poorly performing project teams is a lack of motivation among team members. Motivation is typically a highly individualistic phenomenon, suggesting that the factors that motivate one member of the project (e.g., technical challenge, opportunities for advancement) may not be motivating for another member. When overall project team motiva- tion is low, however, the project’s performance will naturally suffer as team members work at below-optimal performance. Some of the reasons why project team motivation may be low include the following.

the Project IS PerceIved aS unneceSSary When projects are viewed by team members as less than critical, their motivation to perform well will naturally be affected. Whether the project team members’ perception of a project as “unnecessary” is correct or not, if the organization and the project manager allow this interpretation to become fixed, it is extremely difficult to achieve high motivation from the team. Consequently, project managers need to communicate to the project team, as honestly as possible, the benefits of the project, its goals, and why they are important for the organization.

the Project may have loW PrIorIty Team members within organizations are often aware of which project initiatives are considered high priority and which are not. Internal company com- munications, including newsletters, e-mails, and other methods for highlighting activities, clearly identify the projects that top management views as critical. When project team members perceive that they are working on a project of low priority, they adopt a low level of commitment to the project and have low motivation to perform well.

Poor communication

Poor communication comes about for a variety of reasons. For example, project team members may be uncertain about the structure of the project and the interdependencies among team members so they do not know with whom they are expected to share information. Another reason communi- cation within the project team can break down is that some team members are unwilling to share information, viewing it as a source of power over other members of the team. Communication also may be impeded within the project team due to the different functional or professional orientations of project team members. Technical personnel, such as engineers, are comfortable employing scientific or technical jargon that is hard for nontechnical personnel to understand. Likewise, professionals with financial backgrounds may use business-related terminology that is not clear to technical team members.

The key to resolving many communication problems lies in the project manager’s willing- ness to establish and enforce standards for information sharing among team members, creating an atmosphere within the project team that encourages frank and open exchanges. Other mecha- nisms for encouraging cross-functional cooperation are examined in greater detail later in this chapter.

Poor leadership

Chapter 4 discussed the importance of the project manager’s approach to leadership in great detail. Because this individual is often the linchpin holding the team together, the leadership style chosen by the project manager is a key promoter or inhibitor of project team effectiveness. Project managers who adopt a “one-style-fits-all” approach to leadership fail to recognize that different leadership styles are required in order to get the best performance out of each team

196 Chapter 6 • Project Team Building, Conflict, and Negotiation

member. Further, some project managers adopt a leadership approach that may be completely antithetical to the project team, browbeating, bullying, or threatening team members in the belief that the key to high project team performance is to create an atmosphere of fear and anxiety. Successful project leaders understand that leadership styles depend upon a number of relevant criteria within the project team—including makeup of the team, motivation levels, and experience and skill levels of team members—and modify their leadership style accordingly.

turnover among Project team members

A common problem in many organizations is that team members are assigned to a project and then unexpectedly pulled off the project for reassignment. The higher the turnover among proj- ect team members, the more it disrupts the project manager’s ability to create project team cohesion. Further, the act of continually adding to and removing personnel from project teams causes problems with team learning and functioning. Research has found that because of learn- ing curve effects, the act of adding team members to an ongoing project often has the effect of delaying the project. New team members need time to get caught up with the project, they are not clear on structure or team interrelationships, and they do not understand internal team dynamics.

Although the best-case scenario for project managers is to run projects in which team mem- bers do not turn over, the practical reality is that we must anticipate the potential for turnover and consider strategies that allow for minimal disruption to the project schedule when turnover does occur. One method of minimizing disruption is for the project manager to require that everyone on the team understands, as clearly as possible, not only her own role but also the roles of other team members to allow the members to support activities that could be delayed due to staff “pullaways.” Another option is for the project manager to work closely with functional department heads in order to anticipate the possibility of project team members leaving the team prematurely and to begin prepping possible replacements.

dysfunctional Behavior

Dysfunctional behavior refers to the disruptive acts of some project team members due to per- sonality issues, hidden agendas, or interpersonal problems. Sometimes the solution simply calls for recognizing which members are engaging in these behaviors and taking steps to correct the problem. Other times, serious cases of dysfunctional behavior may require that a team member be removed from the project team.

6.4 StageS In grouP develoPment

The process of group development is a dynamic one.8 Groups go through several maturation stages that are often readily identifiable, are generally found across a variety of organizations, and involve groups formed for a variety of different purposes. These stages are illustrated in Table 6.1 and Figure 6.3.9

taBle 6.1 Stages of Group Development

Stage Defining characteristics

Forming Members get to know one another and lay the basis for project and team ground rules.

Storming Conflict begins as team members begin to resist authority and demonstrate hidden agendas and prejudices.

Norming Members agree on operating procedures and seek to work together, develop closer relationships, and commit to the project development process.

Performing Group members work together to accomplish their tasks.

Adjourning Groups may disband either following the completion of the project or through significant reassignment of team personnel.

6.4 Stages in Group Development 197

Stage one: Forming

forming consists of the process or approaches used to mold a collection of individuals into a coherent project team. This stage has sometimes been referred to as the “floundering” stage, because team members are unsure about the project’s goals, may not know other team mem- bers, and are confused about their own assignments.10 Team members begin to get acquainted with one another and talk about the purposes of the project, how they perceive their roles, what types of communication patterns will be used, and what will be acceptable behaviors within the group. During the forming stage, some preliminary standards of behavior are established, including rules for interaction (who is really in charge and how members are expected to inter- act) and activity (how productive members are expected to be). The earlier this stage is com- pleted, the better, so that ambiguities further along are avoided. In these early meetings, the role of the team leader is to create structure and set the tone for future cooperation and positive member attitudes.

Stage two: Storming

storming refers to the natural reactions members have to the initial ground rules. Members begin to test the limits and constraints placed on their behavior. Storming is a conflict-laden stage in which the preliminary leadership patterns, reporting relationships, and norms of work and interpersonal behavior are challenged and, perhaps, reestablished. During this stage, it is likely that the team leader will begin to see a number of the group members demonstrating per- sonal agendas, attempting to defy or rewrite team rules, and exhibiting prejudices toward team- mates from other functional backgrounds. For example, a team member may unilaterally decide that it is not necessary for her to attend all team meetings, proposing instead to get involved later in the project when she is “really needed.” Other behaviors may involve not-so-subtle digs at members from other departments (“Gee, what are you marketing people doing here on a tech- nical project?”) or old animosities between individuals that resurface. Storming is a very natural phase through which all groups go. The second half of this chapter addresses ways to handle all types of conflict.

1. Forming

2. Storming3. Norming

4. Performing






Co nt

ro l

C ooperation

Pr od

uc tiv


• Quiet • Polite • Guarded • Impersonal • Businesslike • High morale

• Conflict over control • Confrontational • Alienation • Personal agendas • Low morale

• Establish procedures • Develop team skills • Confront issues • Rebuild morale

• Trust • Flexible • Supportive • Confident • Efficient • High morale

FIgure 6.3 Stages of team Development

Source: V. K. Verma. (1997). Managing the Project Team, p. 71. Upper Darby, PA: Project Management Institute. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

198 Chapter 6 • Project Team Building, Conflict, and Negotiation

Stage three: norming

A norm is an unwritten rule of behavior. norming behavior in a group implies that the team members are establishing mutually agreed-upon practices and attitudes. Norms help the team determine how it should make decisions, how often it should meet, what level of openness and trust members will have, and how conflicts will be resolved. Research has shown that it is during the norming stage that the cohesiveness of the group grows to its highest level. Close relationships develop, a sense of mutual concern and appreciation emerges, and feelings of camaraderie and shared responsibility become evident. The norming stage establishes the healthy basis upon which the actual work of the team will commence.

Stage Four: Performing

The actual work of the project team is done during the performing stage. It is only when the first three phases have been properly dealt with that the team will have reached the level of maturity and confidence needed to effectively perform their duties. During the performing stage, team rela- tionships are characterized by high levels of trust, a mutual appreciation for one another’s perfor- mance and contributions, and a willingness to actively seek to collaborate. Morale has continued to improve over the project team’s development cycle to this point, at which all team members are working confidently and efficiently. As long as strong task-oriented group norms were estab- lished early in the team development and conflict was resolved, the performing stage is one of high morale and strong performance.

Stage Five: adjourning

Adjourning recognizes the fact that projects and their teams do not last forever. At some point, the project has been completed and the team is disbanded to return to their other functional duties within the organization. In some cases, the group may downsize slowly and deliberately. For example, in the case of developing a systems engineering project, as various components of the system come online, the services of the team’s design engineer may no longer be needed and he will be reassigned. In other circumstances, the team will complete its tasks and be disbanded all at once. In either case, it is important to remember that during the final stages of the implementation process, group members are likely to exhibit some concern about their future assignments and/or new duties. Project managers need to be sensitive to the real concerns felt by these team members and, where possible, help smooth the transition from the old team to the new assignments.

Punctuated equilibrium

In the late 1980s, UCLA researcher Connie Gersick challenged the validity of the standard model of project team development.11 Through a series of studies, she observed a dramatically different process by which project teams evolve. She referred to her model as punctuated equilibrium, based on a similar scientific model proposed by Stephen J. Gould to explain macroevolutionary change in the natural world. Punctuated equilibrium proposes that rather than evolution occurring as a steady state of gradual change, real natural change comes about through long periods of stasis, interrupted by some cataclysmic event that propels upward, evolutionary adjustment.

This phenomenon of punctuated equilibrium frequently occurs in the field of group dynamics. Gersick’s work suggests that the timing of group process changes is quite consistent across teams and situations. Most teams, she discovered, develop a set of operating norms very quickly, at the time of the first team meeting and on the basis of limited interaction and knowledge of one another or the project mission. These norms, which are often less than optimal, tend to guide group behavior and performance for a substantial period of the project’s life. The group will continue to operate as a result of these norms until some trigger event occurs, almost precisely at the halfway point between the initial meeting and the project deadline (see Figure 6.4). The trigger event may be general dissatisfaction with the project’s progress to date, a boiling over of interpersonal antag- onisms, or some other external force. Nevertheless, once this eruption has occurred, it serves as the motivation to revise group norms, develop better intragroup procedures, and promote better task performance. It is typically during this second phase of the group’s life that the majority of effective work gets done and the group begins to function more as a team and less as a collection of individuals.

6.5 Achieving Cross-Functional Cooperation 199

Punctuated equilibrium has some very important implications for project team leaders. First, it suggests that initial impressions are often lasting, as early behaviors and norms quickly solidify and become the controlling force behind the team’s behavior. Project team leaders, therefore, need to take a hard look at how they run kickoff meetings and the messages they send (intentional or otherwise) regarding appropriate task and interpersonal behavior. Second, the model suggests that groups collectively experience a form of “midlife crisis” in running their project, because a lack of concrete results, coupled with escalating interpersonal tensions, tends to build to a state of dissatisfaction that finally overflows midway through the development process. Leaders need to plan for these behaviors, recognize the warning signs of their approach, and proactively chart the steps needed for more positive outcomes from the transition. Finally, Gersick’s research found that group members tended to feel increased frustration because they lacked a real sense of where the project stood at any point in time. Hence, project managers who wish to avoid the more damaging effects of midlife project transitions need to recognize that the more they plan for interim mile- stones and other indications of progress, the more they can mitigate the adverse effects of project team blowups.

6.5 achIevIng croSS-FunctIonal cooPeratIon

What are some tactics that managers can use for effective team development? One research project on project teams uncovered a set of critical factors that contribute to cross-functional cooperation.12 Figure 6.5 shows a two-stage model: The first set of factors influences cooperation, and the second set influences outcomes. Critical factors that influence cooperation and behavior are superordinate goals, rules and procedures, physical proximity, and accessibility. Through cross-functional coopera- tion, these influence both high task outcomes (making sure the project is done right) and psycho- social outcomes (the emotional and psychological effects that strong performance will have on the project team).

Superordinate goals

A superordinate goal refers to an overall goal or purpose that is important to all functional groups involved, but whose attainment requires the resources and efforts of more than one group.13 When Apple developed its iPad tablet, that venture included a number of subprojects, including the creation of a user-friendly operating system, graphical-user interface, a number of unique fea- tures and applications for running multiple programs, 4G and wireless capabilities, and so forth.

Project Time Line

Start Midpoint Deadline

Team Performance




First Meeting


FIgure 6.4 Model of Punctuated equilibrium

200 Chapter 6 • Project Team Building, Conflict, and Negotiation

Each of these subprojects was supported by dozens of electronics engineers, IT professionals, pro- grammers and coding specialists, graphics designers, marketing research personnel, and opera- tions specialists, all working together collaboratively. The iPad could not have been successful if only some of the projects succeeded—they all had to be successful, requiring that their developers maintain strong, collaborative working relationships with one another.

The superordinate goal is an addition to, not a replacement for, other goals the functional groups may have set. The premise is that when project team members from different functional areas share an overall goal or common purpose, they tend to cooperate toward this end. To illus- trate, let us consider an example of creating a new software project for the commercial marketplace. A superordinate goal for this project team may be “to develop a high-quality, user-friendly, and generally useful system that will enhance the operations of various departments and functions.” This overall goal attempts to enhance or pull together some of the diverse function-specific goals for cost-effectiveness, schedule adherence, quality, and innovation. It provides a central objective or an overriding goal toward which the entire project team can strive.

rules and Procedures

Rules and procedures are central to any discussion of cross-functional cooperation because they offer a means for coordinating or integrating activities that involve several functional units.14 Organizational rules and procedures are defined as formalized processes established by the orga- nization that mandate or control the activities of the project team in terms of team membership, task assignment, and performance evaluation. For years, organizations have relied on rules and procedures to link together the activities of organizational members. Rules and procedures have been used to assign duties, evaluate performance, solve conflicts, and so on. Rules and procedures can be used to address formalized rules and procedures established by the organization for the performance of the implementation process, as well as project-specific rules and procedures devel- oped by the project team to facilitate its operations.

The value of rules and procedures suggests that in the absence of cooperation among team members, the company can simply mandate that it occur. In cases where project teams cannot rely on established, organizationwide rules and procedures to assist members with their tasks, they often must create their own rules and procedures to facilitate the progress of the project. For example, one such rule could be that all project team members will make themselves available to one another regarding project business.

Cross–Functional Cooperation

Superordinate Goals

Rules and Procedures

Physical Proximity


Feedback Loop

Task Outcomes

Psychosocial Outcomes

FIgure 6.5 Project team cross-functional cooperation

Source: M. B. Pinto, J. K. Pinto, and J. E. Prescott. (1993). “Antecedents and consequences of project team cross-functional cooperation.” Management Science, 39: 1281–97, p. 1283. Copyright 1993, the Institute for Operations Research and the Management Sciences, 7240 Parkway Drive, Suite 300, Hanover, MD 21076 USA. Reprinted by permission, Project Team Cross-Functional Cooperation.

6.5 Achieving Cross-Functional Cooperation 201

Physical Proximity

Physical proximity refers to project team members’ perceptions that they are located within physi- cal or spatial distances that make it convenient for them to interact. Individuals are more likely to interact and communicate with others when the physical characteristics of buildings or set- tings encourage them to do so.15 For example, the sheer size and spatial layout of a building can affect working relationships. In a small building or when a work group is clustered on the same floor, relationships tend to be more intimate, since people are in close physical proximity to one another. As people spread out along corridors or in different buildings, interactions may become less frequent and/or less spontaneous. In these situations, it is harder for employees to interact with members of either their own department or other departments.

Many companies seriously consider the potential effects of physical proximity on project team cooperation. In fact, some project organizations relocate personnel who are working together on a project to the same office or floor. The term “war room” is sometimes used to illustrate this deliberate regrouping of project team members into a central location. When project team mem- bers work near one another, they are more likely to communicate and, ultimately, cooperate.


While physical proximity is important for encouraging cross-functional cooperation, another factor, accessibility, appears to be an equally important predictor of the phenomenon. Accessibility is the perception by others that a person is approachable for communicating and interacting with on problems or concerns related to the success of a project. Separate from the issue of physical proximity, accessibility refers to additional factors that can inhibit the amount of interaction that occurs between organizational members (e.g., an individual’s schedule, position in an organization, or out-of-office commitments). These factors often affect the acces- sibility among organizational members. For example, consider a public-sector organization in which a member of the engineering department is physically located near a member of the city census department. Although these individuals are in proximity to each other, they may rarely interact because of different work schedules, varied duties and priorities, and commit- ment to their own agendas. Such factors often create a perception of inaccessibility among the individuals involved.

outcomes of cooperation: task and Psychosocial results

As Figure 6.5 suggests, the goal of promoting cross-functional cooperation among members of a project team is not an end unto itself; it reflects a means toward better project team performance and ultimately better project outcomes. Two types of project outcomes are important to consider: task outcomes and psychosocial outcomes. task outcomes refer to the factors involved in the actual implementation of the project (time, schedule, and project functionality). Psychosocial outcomes, on the other hand, represent the team member’s assessment that the project experience was worth- while, satisfying, and productive. It is possible, for example, to have a project “succeed” in terms of completing its task outcomes while all team members are so disheartened due to conflict and bad experiences that they have nothing but bad memories of the project. Psychosocial outcomes are important because they represent the attitudes that project team members will carry with them to subsequent projects (as shown in the feedback loop in Figure 6.5). Was the project experience satisfying and rewarding? If so, we are much more likely to start new projects with a positive atti- tude than in circumstances where we had bad experiences on previous projects. Regardless of how carefully we plan and execute our project team selection and development process, our efforts may take time to bear fruit.

Finally, what are some general conclusions we can draw about methods for building high- performing teams? Based on research, project managers can take three practical steps to set the stage for teamwork to emerge:16

1. Make the project team as tangible as possible. Effective teams routinely develop their own unique identity. Through publicity, promoting interaction, encouraging unique terminology and language, and emphasizing the importance of project outcomes, project managers can create a tangible sense of team identity.

202 Chapter 6 • Project Team Building, Conflict, and Negotiation

2. Reward good behavior. There are many nonmonetary methods for rewarding good per- formance. The keys are (1) flexibility—recognizing that everyone views rewards differently, (2) creativity—providing alternative means to get the message across, and (3) pragmatism— recognizing what can be rewarded and being authentic with the team about how superior performance will be recognized.

3. Develop a personal touch. Project managers need to build one-on-one relationships with project team members. If they lead by example, provide positive feedback to team members, publicly acknowledge good performance, show interest in the team’s work, and are acces- sible and consistent in applying work rules, project team members will come to value both the manager’s efforts and his work on the project.

These suggestions are a good starting point for applying the concept of team building in the difficult setting of project management. Given the temporary nature of projects, the dynamic move- ment of team members on and off the team, and the fact that in many organizations team members are working on several projects simultaneously, building a cohesive project team that can work in harmony and effectively to achieve project goals is extremely valuable.17 Using these guidelines for team building should allow project managers to more rapidly achieve a high-performing team.

6.6 vIrtual Project teamS

The globalization of business has had some important effects on how projects are being run today. Imagine a multimillion-dollar project to design, construct, and install an oil-drilling platform in the North Atlantic. The project calls on the expertise of partner organizations from Russia, Finland, the United States, France, Norway, and Great Britain. Each of the partners must be fully represented on the project team, all decisions should be as consensual as possible, and the project’s success will require continuous, ongoing communication between all members of the project team. Does this sound difficult? In fact, such projects are undertaken frequently. Until recently, the biggest chal- lenge was finding a way for managers to meet and stay in close contact. Constant travel was the only option. However, now more organizations are forming virtual project teams.

virtual teams, sometimes referred to as geographically dispersed teams, involve the use of elec- tronic media, including e-mail, the Internet, and teleconferencing, to link together members of a project team that are not collocated to the same physical place. Virtual teams start with the assump- tion that physical barriers or spatial separation make it impractical for team members to meet in a regular, face-to-face manner. Hence, the virtual team involves establishing alternative communi- cations media that enable all team members to stay in contact, make contributions to the ongoing project, and communicate all necessary project-related information with all other members of the project team. Virtual teams are using technology to solve the thorny problem of productively link- ing geographically dispersed project partners.

Virtual teams present two main challenges: building trust and establishing the best modes of communication.18 Trust, as we have discussed, is a key ingredient needed to turn a disparate group of individuals into an integrated project team. Physical separation and disconnection can make trust slower to emerge. Communications media may create formal and impersonal settings, and the level of comfort that permits casual banter takes time to develop. This can slow down the process of creat- ing trust among team members.

What are some suggestions for improving the efficiency and effectiveness of virtual team meetings? Following are some options available to project teams as they set out to use virtual technology.19

• When possible, find ways to augment virtual communication with face-to-face opportuni- ties. Try not to rely exclusively on virtual technology. Even if it occurs only at the begin- ning of a project and after key milestones, create opportunities to get the team together to exchange information, socialize, and begin developing personal relationships.

• Don’t let team members disappear. One of the problems with virtual teams is that it becomes easy for members to “sign off” for extended periods of time, particularly if regular com- munication schedules are not established. The best solution to this problem is to ensure that communications include both regular meetings and ad hoc get-togethers, either through videoconferencing or through e-mail and Internet connections.

6.6 Virtual Project Teams 203

• Establish a code of conduct among team members. While it can be relatively easy to get agree- ment on the types of information that need to be shared among team members, it is equally important to establish rules for when contact should be made and the length of acceptable and unacceptable delays in responding to messages.

• Keep all team members in the communication loop. Virtual teams require a hyperawareness by the project manager of the need to keep communication channels open. When team mem- bers understand how they fit into the big picture, they are more willing to stay in touch.

• Create a clear process for addressing conflict, disagreement, and group norms. When projects are conducted in a virtual setting, the actual ability of the project manager to gauge team members’ reactions and feelings about the project and one another may be minimal. It is help- ful to create a set of guidelines for allowing the free expression of misgivings or disagreements among team members. For example, one virtual team composed of members of several large organizations established a Friday-afternoon complaint session, which allowed a two-hour block each week for team members to vent their feelings or disagreements. The only rule of the session was that everything said must remain within the project—no one could carry these messages outside the project team. Within two months of instituting the sessions, project team members felt that the sessions were the most productive part of project communication and looked forward to them more than to formal project meetings.

Beyond the challenges of creating trust and establishing communication methods for dispersed teams, there are other considerations that should be addressed.20 For example, selecting the appropri- ate technology tools is an important process. There is no “one best” means for communicating with all team members on all occasions. Communications options include synchronous (occurring in real time) and asynchronous (occurring outside of real time). An example of synchronous communication would be a direct conversation with another party. Asynchronous communication may include e-mail or posting to someone’s Facebook wall. The underlying intent behind the communication may be either social or informational. We can use these communication tools to establish relationships with team members in the same way they are useful for passing along important project information.

Other suggestions for effectively using technology to manage a dispersed team include:21

• No one technology works for everything; use the technology that fits the task at hand. • Vary how your team meets; always using teleconferences becomes routine and boring. • Make sure to intermix meeting types and purposes to keep the team experience fresh.

Overemphasizing just one type of meeting (social or informational) can lead to assumptions about the only types of meetings worth having.

• Communication technologies can be combined in various ways; for example, virtual whiteboards work well with videoconferencing.

• Asynchronous technologies tend to become the dominant forms as time-zone differences grow. Find methods for adding a synchronous element whenever possible.

• Training in the proper use of technology is critical to its effectiveness. Whoever facilitates the meetings must be an expert on the technologies employed.

Project Profile

tele-immersion technology eases the Use of Virtual teams

For many users of videoconferencing technology, the benefits and drawbacks may sometimes seem about equal. Although there is no doubt that teleconferencing puts people into immediate contact with each other from great geographical distances, the current limitations on how far the technology can be applied lead to some important quali- fications. As one writer noted:

I am a frequent but reluctant user of videoconferencing. Human interaction has both verbal and nonverbal elements, and videoconferencing seems precisely configured to confound the nonverbal ones. It is impossible to make eye contact properly, for instance, in today’s videoconferencing systems, because the camera and the display screen cannot be in the same spot. This usually leads to a deadened and formal affect in interactions, eye contact being a nearly ubiquitous subconscious method of affirming trust. Furthermore, participants aren’t able to establish a sense of position relative to one another and therefore have no clear way to direct attention, approval or disapproval.22


204 Chapter 6 • Project Team Building, Conflict, and Negotiation

It was to address these problems with teleconferencing that tele-immersion technology was created. Tele- immersion, a new medium for human interaction enabled by digital technologies, creates the illusion that a user is in the same physical space as other people, even though the other participants might in fact be thousands of miles away. It combines the display and interaction techniques of virtual reality with new vision technologies that transcend the traditional limitations of a camera. The result is that all the participants, however distant, can share and explore a life- sized space.

This fascinating new technology, which has emerged very recently, offers the potential to completely change the nature of how virtual project teams communicate with each other. Pioneered by Advanced Network & Services as part of the National Tele-Immersion Initiative (NTII), tele-immersion enables users at geographically distributed sites to col- laborate in real time in a shared, simulated environment as if they were in the same physical room. Tele-immersion is the long-distance transmission of life-sized, three-dimensional synthesized scenes, accurately sampled and rendered in real time using advanced computer graphics and vision techniques. The use of this sophisticated representation of three-dimensional modeling has allowed teleconferencing to take on a whole new look; all members of the project literally appear in a real-time, natural setting, almost as if they were sitting across a conference table from one another.

With enhanced bandwidth and the appropriate technology, tele-immersion video conferencing offers an enor- mous leap forward compared to the current two-dimensional industry standards in use. In its current form, the tele-immersion technology requires the videoconference member to wear polarizing glasses and a silvery head-tracking device that can move around and see a computer-generated 3D stereoscopic image of the other teleconferencers, whereby the visual content of a block of space surrounding each participant’s upper body and some adjoining workspace is essentially reproduced with computer graphics. This results in a more fully dimensional and compressible depiction of such real- world environments than is possible with existing video technology. Just how far this technology is likely to go in the years ahead is impossible to predict, but no one is betting against it becoming the basis for an entirely new manner of conducting virtual team meetings.23

As Figure 6.6 demonstrates, recent advances in technology have allowed tele-immersion conferencing to some- times dispense with extra equipment link goggles or tracking devices. The ability to translate and communicate sophis- ticated images of people, blueprints, or fully rendered three-dimensional models makes this technology unique and highly appealing as an alternative to standard telephone conferencing.

Virtual teams, though not without their limitations and challenges, offer an excellent method for applying the technical advances in the field of telecommunications to the problems encountered with global, dispersed project teams. The key to using them effectively lies in a clear recognition of what virtual technologies can and cannot do. For example, while the Internet can link team members, it cannot convey nonverbals or feelings that team members may have about the project or other members of the project. Likewise, although current videoconferencing allows for real-time, face-to-face interactions, it is not a perfect substitute for genuine “face time” among project team members. Nevertheless, the development of virtual technologies has been a huge benefit for project organizations, coming as it has at the same time that teams have become more global in their makeup and that partnering project organizations are becoming the norm for many project challenges.

6.7 conFlIct management

One study has estimated that the average manager spends over 20% of his time dealing with conflict.24 Because so much of a project manager’s time is taken up with active conflict and its residual aftermath, we need to understand this natural process within the project management

FIgure 6.6 tele-immersion technology

HO Marketwire Photos/Newscom

6.7 Conflict Management 205

context. This section of the chapter is intended to more formally explore the process of con- flict, examine the nature of conflict for project teams and managers, develop a model of conflict behavior, and foster an understanding of some of the most common methods for de-escalating conflict.

What Is conflict?

conflict is a process that begins when you perceive that someone has frustrated or is about to frustrate a major concern of yours.25 There are two important elements in this definition. First, it suggests that conflict is not a state, but a process. As such, it contains a dynamic aspect that is very important. Conflicts evolve.26 Further, the one-time causes of a conflict may change over time; that is, the reasons why two individuals or groups developed a conflict initially may no longer have any validity. However, because the conflict process is dynamic and evolving, once a conflict has occurred, the reasons behind it may no longer matter. The process of conflict has important ramifi- cations that we will explore in greater detail.

The second important element in the definition is that conflict is perceptual in nature. In other words, it does not ultimately matter whether or not one party has truly wronged another party. The important thing is that one party perceives that state or event to have occurred. That perception is enough because for that party, perception of frustration defines reality.

In general, most types of conflict fit within one of three categories,27 although it is also com- mon for some conflicts to involve aspects of more than one category.

goal-oriented conflict is associated with disagreements regarding results, project scope out- comes, performance specifications and criteria, and project priorities and objectives. Goal-oriented conflicts often result from multiple perceptions of the project and are fueled by vague or incom- plete goals that allow project team members to make their own interpretations.

Administrative conflict arises through management hierarchy, organizational structure, or company philosophy. These conflicts are often centered on disagreements about reporting relationships, who has authority and administrative control for functions, project tasks, and decisions. A good example of administrative conflict arises in matrix organization structures, in which each project team member is responsible to two bosses, the project manager and the functional supervisor. In effect, this structure promotes the continuance of administrative conflict.

interpersonal conflict occurs with personality differences between project team members and important project stakeholders. Interpersonal conflict sources include different work ethics, behavioral styles, egos, and personalities of project team members.

At least three schools of thought exist about how conflicts should be perceived and addressed. These vary dramatically, depending upon the prevailing view that a person or an organization holds.28

The first view of conflict is the traditional view, which sees conflict as having a negative effect on organizations. Traditionalists, because they assume that conflict is bad, believe that conflict should be avoided and resolved as quickly and painlessly as possible when it does occur. The emphasis with traditionalists is conflict suppression and elimination.

The second view of conflict is the behavioral or contemporary school of thought. Behavioral theorists view conflict as a natural and inevitable part of organizational life. Differentiation across functional departments and different goals, attitudes, and beliefs are natural and perma- nent states among members of a company, so it is natural that conflict will result. The solution to conflict for behavioral theorists is to manage conflict effectively rather than attempt to eliminate or suppress it.

The third view of conflict, the interactionist view, takes behavioral attitudes toward conflict one step further. Where a behavioral view of conflict accepts it when it occurs, interactionists encourage conflict to develop. Conflict, to an interactionist, prevents an organization from becom- ing too stagnant and apathetic. Conflict actually introduces an element of tension that produces innovation, creativity, and higher productivity. The interactionists do not intend that conflict should continue without some controls, however; they argue that there is an optimal level of con- flict that improves the organization. Beyond that point, conflict becomes too intense and severe and begins hurting the company. The trick, to an interactionist, is to find the optimal level of con- flict—too little leads to inertia and too much leads to chaos.

206 Chapter 6 • Project Team Building, Conflict, and Negotiation

Sources of conflict

Potential sources of conflict in projects are numerous. Some of the most common sources include the competition for scarce resources, violations of group or organizational norms, disagreements over goals or the means to achieve those goals, personal slights and threats to job security, long- held biases and prejudices, and so forth. Many of the sources of conflict arise out of the project management situation itself. That is, the very characteristics of projects that make them unique contribute some important triggers for conflict to erupt among project stakeholders.

organIzatIonal cauSeS oF conFlIct Some of the most common causes of organizational conflict are reward systems, scarce resources, uncertainty, and differentiation. Reward systems are competitive processes some organizations have set up that pit one group or functional depart- ment against another. For example, when functional managers are evaluated on the performance of their subordinates within the department, they are loath to allow their best workers to become involved in project work for any length of time. The organization has unintentionally created a state in which managers perceive that either the project teams or the departments will be rewarded for superior performance. In such cases, they will naturally retain their best people for functional duties and offer their less-desirable subordinates for project teamwork. The project managers, on the other hand, will also perceive a competition between their projects and the functional depart- ments and develop a strong sense of animosity toward functional managers whom they perceive, with some justification, are putting their own interests above the organization.

Scarce resources are a natural cause of conflict as individuals and departments compete for the resources they believe are necessary to do their jobs well. Because organizations are character- ized by scarce resources sought by many different groups, the struggle to gain these resources is a prime source of organizational conflict. As long as scarce resources are the natural state within organizations, groups will be in conflict as they seek to bargain and negotiate to gain an advantage in their distribution.

Uncertainty over lines of authority essentially asks the tongue-in-cheek question, “Who’s in charge around here?” In the project environment, it is easy to see how this problem can be badly exacerbated due to the ambiguity that often exists with regard to formal channels of authority. Project managers and their teams sit “outside” the formal organizational hierarchy in many orga- nizations, particularly in functional structures. As a result, they find themselves in a uniquely frag- ile position of having a great deal of autonomy but also responsibility to the functional department heads who provide the personnel for the team. For example, when a project team member from R&D is given orders by her functional manager that directly contradict directives from the project manager, she is placed in the dilemma of having to find (if possible) a middle ground between two nominal authority figures. In many cases, project managers do not have the authority to con- duct performance evaluations of their team members—that control is kept within the functional department. In such situations, the team member from R&D, facing role conflict brought on by this uncertainty over lines of authority, will most likely do the expedient thing and obey her functional manager because of his “power of the performance appraisal.”

Differentiation reflects the fact that different functional departments develop their own mind- sets, attitudes, time frames, and value systems, which can conflict with those of other departments. Briefly, differentiation suggests that as individuals join an organization within some functional specialty, they begin to adopt the attitudes and outlook of that functional group. For example, a member of the finance department, when asked her opinion of marketing, might reply, “All they ever do is travel around and spend money. They’re a bunch of cowboys who would give away the store if they had to.” A marketing member’s opinion of finance department personnel might be similarly unflattering: “Finance people are just a group of bean counters who don’t understand that the company is only as successful as it can be at selling its products. They’re so hung up on their margins that they don’t know what goes on in the real world.” The interesting point about these views is that, within their narrow frames of reference, they both are essentially correct: Marketing is interested primarily in making sales, and finance is devoted to maintaining high margins. However, these opinions are by no means completely true; they simply reflect the underlying attitudes and prejudices of members of the respective functional departments. The more profound the differentia- tion within an organization, the greater the likelihood that individuals and groups will divide into “us” versus “them” encampments, which will continue to promote and provoke conflict.

6.7 Conflict Management 207

InterPerSonal cauSeS oF conFlIct Faulty attributions refer to our misconceptions of the rea- sons behind another’s behavior. When people perceive that their interests have been thwarted by another individual or group, they typically try to determine why the other party has acted as it did. In making attributions about another’s actions, we wish to determine if their motives are based on personal malevolence, hidden agendas, and so forth. Often groups and individuals will attribute motives to another’s actions that are personally most convenient. For example, when one member of a project team has his wishes frustrated, it is common to perceive the motives behind the other party’s actions in terms of the most convenient causes. Rather than acknowledge the fact that reasonable people may differ in their opinions, it may be more convenient for the frustrated person to assume that the other is provoking a conflict for personal reasons: “He just doesn’t like me.” This attribution is convenient for an obvious and psychologically “safe” reason; if we assume that the other person disagrees with us for valid reasons, it implies a flaw in our position. Many individuals do not have the ego strength to acknowledge and accept objective disagreement, pre- ferring to couch their frustration in personal terms.

Faulty communication is a second and very common interpersonal cause of conflict. Faulty commu- nication implies the potential for two mistakes: communicating in ways that are ambiguous and lead to different interpretations, thus causing a resulting conflict, and unintentionally communicating in ways that annoy or anger other parties. Lack of clarity can send out mixed signals: the message the sender intended to communicate and that which was received and interpreted by the receiver. Consequently, the project manager may be surprised and annoyed by the work done by a subordinate who genuinely thought she was adhering to the project manager’s desires. Likewise, project managers often engage in criticism in the hopes of correcting and improving project team member performance. Unfortunately, what the project manager may consider to be harmless, constructive criticism may come across as a destructive, unfair critique if the information is not communicated accurately and effectively.

Personal grudges and prejudices are another main cause of interpersonal conflict. Each of us brings attitudes into any work situation. These attitudes arise as the result of long-term experi- ences or lessons taught at some point in the past. Often these attitudes are unconsciously held; we may be unaware that we nurture them and can feel a genuine sense of affront when we are chal- lenged or accused of holding biases. Nevertheless, these grudges or prejudices, whether they are held against another race, sex, or functional department, have a seriously debilitating effect on our ability to work with others in a purposeful team and can ruin any chance at project team cohesion and subsequent project performance.

Table 6.2 illustrates some of the findings from two studies that investigated the major sources of conflict in project teams.29 Although the studies were conducted more than a decade apart, the findings are remarkably consistent across several dimensions. Conflicts over schedules and project priorities tend to be the most common and intense sources of disagreement. Interestingly, Posner’s research found that cost and budget issues played a much larger role in triggering conflict than did the earlier work of Thamhain and Wilemon. The significant changes in the rank ordering of sources of conflict and their intensity may be due to shifts in priorities or practices of project man- agement over time, making issues of cost of greater concern and conflict.30 Nevertheless, Table 6.2 gives some clear indications about the chief causes of conflict within project teams and the inten- sity level (1 being the highest and 7 being the lowest) of these conflicts.

taBle 6.2 Sources of conflict in Projects and their ranking by intensity level

conflict intensity ranking

Sources of conflict thamhain & Wilemon Posner

Conflict over project priorities 2 3

Conflict over administrative procedures 5 7

Conflict over technical opinions and performance trade-offs

4 5

Conflict over human resources 3 4

Conflict over cost and budget 7 2

Conflict over schedules 1 1

Personality conflicts 6 6

208 Chapter 6 • Project Team Building, Conflict, and Negotiation

methods for resolving conflict

A number of methods for resolving group conflict are at the project manager’s disposal. Before making a decision about which approach to follow, the project manager needs to consider several issues.31 For example, will the project manager’s siding with one party to the dispute alienate the other person? Is the conflict professional or personal in nature? Does any sort of intervention have to occur or can team members resolve the issue on their own? Does the proj- ect manager have the time and inclination to mediate the dispute? All of these questions play an important role in determining how to approach a conflict situation. Project managers must learn to develop flexibility in dealing with conflict, knowing when to intervene versus when to remain neutral. We can choose to manage conflict in terms of five alternatives.32

medIate the conFlIct In this approach, the project manager takes a direct interest in the conflict between the parties and seeks to find a solution. The project manager may employ either defu- sion or confrontation tactics in negotiating a solution. Defusion implies that the project manager is less concerned with the source of the conflict than with a mutually acceptable solution. She may use phrases such as “We are all on the same team here” to demonstrate her desire to defuse the conflict without plumbing its underlying source. Confrontation, which typically involves working with both parties to get at the root causes of the conflict, is more emotional, time-intensive, and, in the short term, may actually exacerbate the conflict as both sides air their differences. In the long run, however, confrontation can be more effective as a mediating mechanism because it seeks to determine underlying causes of the conflict so they can be corrected. Project managers mediate solutions when they are not comfortable imposing a judgment but would rather work with both parties to come to some common agreement.

arBItrate the conFlIct In choosing to arbitrate a conflict, the project manager must be willing to impose a judgment on the warring parties. After listening to both positions, the project manager renders his decision. Much as a judge would do, it is best to minimize personalities in the decision and focus instead on the judgment itself. For example, saying, “You were wrong here, Phil, and Susan was right,” is bound to lead to a negative emotional response from Phil. By imposing an impersonal judgment, however, the project manager can stick with the specifics of the case at hand rather than getting into personalities. “Company policy states that all customers must receive cop- ies of project revision orders within three working days” is an example of an impersonal judgment that does not point the finger of guilt at either party.

control the conFlIct Not all conflicts can be (nor should be) quickly resolved. In some cases, a pragmatic response to a conflict might be to wait a couple of days for the two parties to cool down. This is not a cowardly response; instead it recognizes that project managers must be selec- tive about how they intervene and the optimal manner in which they can intervene. Another way to control conflict is through limiting the interaction between two parties. For example, if it is common knowledge that one member of the project team and the customer have a long history of animosity, good sense dictates that they should not be allowed to communicate directly except under the most controlled of circumstances.

accePt the conFlIct Not all conflicts are manageable. Sometimes the personalities of two proj- ect team members are simply not compatible. They disliked each other before the project and will continue to dislike each other long after the project has been completed.

elImInate the conFlIct We need to critically evaluate the nature and severity of conflicts that occur continually within a project. In some situations, it is necessary, for the good of the project, to transfer a team member or make other changes. If there is a clearly guilty party, a common response is to sanction that person, remove him from the project, or otherwise pun- ish him. If two or more people share a collective guilt for the ongoing conflict, it is often use- ful to transfer them all—sending a signal that you intend to run the project as impartially as possible.

6.8 Negotiation 209

The important point to bear in mind is that different approaches may be appropriate in differ- ent situations. Do not assume that a problem-solving session is always beneficial or warranted, nor is ignoring conflict always “lazy” management. Project managers have to learn to understand their own preferences when it comes to handling conflict. Once we have achieved a greater sense of self- awareness, we will be in a better position first to resolve our own conflicts constructively and then to deal more effectively with subordinate conflicts. The key is flexibility. It is important not to lock into any particular conflict style nor favor one resolution tactic to the exclusion of all others. Each has its strengths and drawbacks and can be an important part of the project manager’s tool chest.

Conflict often is evidence of project team progress. As we begin to assemble a group of dis- parate individuals with various functional backgrounds into a project team, a variety of conflicts are bound to be sparked. Team conflict is natural. Remember, however, that the approaches we choose to employ to deal with conflict say a great deal about us: Are we intolerant, authoritarian, and intransigent, or do we really want to find mutually beneficial solutions? We can send many messages—intentional and unintentional, clear and mixed—to the rest of the project team by the manner in which we approach team building and conflict management.

6.8 negotIatIon

One of the central points that this chapter has made is to suggest that much of our future success will rest with our ability to appreciate and manage the variety of “people” issues that are central to life in projects. negotiation is a process that is predicated on a manager’s ability to use his influ- ence productively.

Negotiation skills are so important because much of a project manager’s life is taken up in bargaining sessions of one type or another. Indeed, stakeholder management can be viewed as the effective and constant mutual negotiation across multiple parties. Project managers negotiate for additional time and money, to prevent excessive interference and specification changes from cli- ents, the loan or assignment to the team of important project team personnel with functional man- agers, and so forth. Negotiation represents the art of influence taken to its highest level. Because effective negotiation is an imperative for successful project management, it is vital that project managers understand the role negotiation plays in their projects, how to become better negotia- tors, and some of the important elements in negotiation.

questions to ask Prior to the negotiation

Anyone entering a negotiation needs to consider three questions: How much power do I have? What sort of time pressures are there? Do I trust my opponent?33

A realistic self-assessment concerning power and any limiting constraints is absolutely vital prior to sitting down to negotiate. One important reason is that it can show the negotiators where they are strong and, most importantly, what their weaknesses are. A project manager once related this story:

It was early in June and we were involved in the second week of pretty intense negotiations with a vendor for site considerations before starting a construction project. Unfortunately, the vendor discovered that we do our accounting books on a fiscal basis, ending June 30th, and he figured, correctly, that we were desperate to record the deal prior to the end of the month. He just sat on his hands for the next 10 days. Now it’s June 21st and my boss is having a heart attack about locking in the vendor. Finally, we practically crawled back to the table in late June and gave him everything he was asking for in order to record the contract.

This project manager lost out in the power and time departments! How much power do you have going into the negotiation? You are not necessarily looking

for a dominant position but a defensive one, that is, one from which the other party cannot domi- nate you. How much time do you have? The calendar can be difficult to overcome. So, too, can a domineering boss who is constantly telling you to “solve the problem with R&D, marketing, or whomever.” Once word gets out that you have a time constraint, just watch your opponent slow down the pace, reasoning correctly that you will have to agree sooner rather than later, and on her terms, not yours.

210 Chapter 6 • Project Team Building, Conflict, and Negotiation

Is it possible to trust the other party? Will the firm abide by its word, or does it have a reputa- tion for changing agreements after the fact? Is it forthcoming with accurate information? Does it play negotiation hardball? Note that not all of these questions indicate someone who is untrust- worthy. Indeed, it is appropriate to play hardball on occasion. On the other hand, the essential question is whether you can sit across a table from your opponent and believe that you both have a professional, vested interest in solving a mutual problem. If the answer is no, it is highly unlikely that you will negotiate with the same degree of enthusiasm or openness toward the other party.

Principled neg