Reflection

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 Dotcom.com 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 www.pearsoned.com/permissions/.

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

iii

BrIEF COnTEnTS

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

iv

COnTEnTS

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 Dotcom.com  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

xiii

PrEFACE

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

Management

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, www.pearsonhighered.com/irc, 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 http://247.pearsoned.com 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

ackNoWledgmeNts

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.

feedBack

The textbook team and I would appreciate hearing from you. Let us know what you think about this textbook by writing to college.marketing@pearson.com. 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 http://247pearsoned.custhelp.com.

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

jkp4@psu.edu

1

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

Success

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

(continued)

4 Chapter 1 • Introduction

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

Uncertainty

Creativity

Resources

Project Stake

Client Interest

Time

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,

(continued)

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

Success

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

Importance

Project Completion

1 Project

Efficiency

2 Impact on the

Customer

3 Business Success

4 Preparing for

the Future

Time

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

1

2

3

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

0

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.

1

2

3

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

0

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.

t a

b l e 1

.3

A c

o m

p a ri

so n

o f

P ro

je ct

M a tu

ri ty

M o

d e ls

a n

d i

n cr

e m

e n

ta l

S ta

g e s

c e n

te r

fo r

B u

si n

e ss

P ra

ct ic

e s

Le ve

l 1 : In

it ia

l P ro

ce ss

• A

d h

o c

p ro

ce ss

• M

an ag

em en

t aw

ar en

es s

Le ve

l 2 : St

ru ct

u re

, Pr

o ce

ss ,

an d

St an

d ar

d s

• B as

ic p

ro ce

ss es

, n o

t st

an d ar

d

o n a

ll p ro

je ct

s •

M an

ag em

en t

su p p o rt

s u se

• Es

ti m

at es

, sc

h ed

u le

s b as

ed

o n e

xp er

t kn

o w

le d

g e

Le ve

l 3 :

In st

it u ti o n al

iz ed

Pr

o je

ct M

an ag

em en

t •

A ll

p ro

je ct

p ro

ce ss

es a

re

re p ea

ta b le

• Es

ti m

at es

, sc

h ed

u le

s b as

ed

o n in

d u st

ry s

ta n d ar

d s

Le ve

l 4 :

M an

ag ed

• Pr

o je

ct m

an ag

em en

t p

ra ct

ic es

in

te g ra

te d w

it h c

o rp

o ra

te

p ro

ce ss

es •

So lid

a n al

ys is

o f

p ro

je ct

p er

fo rm

an ce

• Es

ti m

at es

, sc

h ed

u le

s b

as ed

o n c

o rp

o ra

te s

p ec

if ic

s

Le ve

l 5 :

O p

ti m

iz in

g •

Pr o

ce ss

es t

o m

ea su

re p

ro je

ct

ef fi ci

en cy

• Pr

o ce

ss es

in p

la ce

t o

im p

ro ve

p

ro je

ct p

er fo

rm an

ce •

C o

m p

an y

fo cu

se s

o n

c o

n ti n

u -

o u

s im

p ro

ve m

en t

K e rz

n e r’

s P ro

je ct

M a n

a g

e m

e n

t M

a tu

ri ty

M o

d e l

Le ve

l 1 : C

o m

m o n L

an g u ag

e •

Sp o ra

d ic

u se

o f

p ro

je ct

m

an ag

em en

t •

Sm al

l p o ck

et s

o f

in te

re st

in

t h e

fi rm

• N

o in

ve st

m en

t in

P M

tr

ai n in

g

Le ve

l 2 : C

o m

m o n P

ro ce

ss es

• Ta

n g ib

le b

en ef

it s

m ad

e ap

p ar

en t

• PM

s u p p o rt

t h ro

u g h o u t

th e

fi rm

• D

ev el

o p m

en t

o f

a PM

cu

rr ic

u lu

m

Le ve

l 3 :

Si n g u la

r M

et h o d o lo

g y

• In

te g ra

te d p

ro ce

ss es

• C

u lt u ra

l a n d m

an ag

em en

t su

p p o rt

• Fi

n an

ci al

b en

ef it f

ro m

P M

tr

ai n in

g

Le ve

l 4 :

B en

ch m

ar ki

n g

• A

n al

ys is

a n d e

va lu

at io

n o

f

p ra

ct ic

es •

Pr o je

ct o

ff ic

e es

ta b

lis h

ed

Le ve

l 5 :

C o

n ti n

u o

u s

Im p

ro ve

m en

t •

Le ss

o n

s le

ar n

ed ,

fi le

s cr

ea te

d •

K n

o w

le d

g e

tr an

sf er

b et

w ee

n

te am

s •

M en

to rs

h ip

p ro

g ra

m

e S i in

te rn

a ti

o n

a l’s

P ro

je ct

f ra

m e w

o rk

Le ve

l 1 : A

d H

o c

• Pr

o ce

ss es

il l- d ef

in ed

b e-

ca u se

t h ey

a re

a p p lie

d

in d iv

id u al

ly •

Li tt

le s

u p p o rt

b y

o rg

an iz

at io

n

Le ve

l 2 : C

o n si

st en

t •

O rg

an iz

at io

n is

w el

l i n te

n -

ti o n ed

in it

s m

et h o

d s

• N

o p

ro je

ct c

o n tr

o l p

ro ce

ss es

o r

le ss

o n s

le ar

n ed

Le ve

l 3 :

In te

g ra

te d

• Pr

o ce

ss es

a re

t ai

lo re

d t

o

en h an

ce a

ll PM

a sp

ec ts

• C

o m

m o n u

se a

n d

u n d er

st an

d in

g o

f m

et h o d s

ac ro

ss t

h e

fi rm

Le ve

l 4 :

C o m

p re

h en

si ve

• PM

f u lly

im p le

m en

te d

a cr

o ss

th

e fi rm

• In

fo rm

at io

n is

u se

d t

o e

va lu

at e

p ro

ce ss

es a

n d r

ed u

ce v

ar ia

ti o

n •

A d va

n ce

d P

M t

o o

ls a

n d

te

ch n iq

u es

a re

d ev

el o

p ed

Le ve

l 5 :

O p

ti m

iz in

g •

C o

n ti n

u al

e ff

o rt

t o

im p

ro ve

an

d in

n o

va te

p ro

je ct

ca

p ab

ili ty

• C

o m

m o

n f

ai lu

re s

ar e

el im

in at

ed

S e i’s

c a p

a b

il it

y M

a tu

ri ty

M o

d e l in

te g

ra ti

o n

Le ve

l 1 : In

it ia

l •

A d h

o c,

c h ao

ti c

p ro

ce ss

es

Le ve

l 2 : M

an ag

ed •

R eq

u ir em

en ts

m an

ag em

en t,

p ro

je ct

p la

n n in

g , an

d c

o n tr

o l

o cc

u r

• Pr

o ce

ss q

u al

it y

as su

ra n ce

o cc

u rs

• C

o n fi g u ra

ti o n m

an ag

em en

t is

u se

d

Le ve

l 3 :

D ef

in ed

• R eq

u ir em

en ts

d ev

el o p m

en t

an d p

ro d u ct

in te

g ra

ti o n

o cc

u r

• V er

if ic

at io

n a

n d v

al id

at io

n

o f

p ro

ce ss

es •

R is

k m

an ag

em en

t is

em

p h as

iz ed

Le ve

l 4 :

Q u an

ti ta

ti ve

M an

ag em

en t

• Pr

o ce

ss p

er fo

rm an

ce is

g au

g ed

• Q

u an

ti ta

ti ve

P M

h ig

h lig

h te

d

Le ve

l 5 :

O p

ti m

iz in

g •

In n

o va

ti o

n a

n d

d ep

lo ym

en t

ac ce

n tu

at ed

• C

au sa

l a n

al ys

is a

n d

r es

o lu

- ti o

n o

cc u

r

22

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

improvement

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.

Summary

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

(continued)

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.”

Questions

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.

Questions

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

(continued)

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!

Questions

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

Questions

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, www.pmi.org, 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 www.pmi.org/Business-Solutions/OPM3-Case-Study- 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

Notes

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

stated.

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. http://edition.cnn.com/2012/08/22/business/lagos- 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:// businessdayonline.com/2014/02/on-lagos-investment- in-infrastructure-development/#.U6hKwPldV8E; Joy, O. (2013, October 10). “Tech cities and mega dams: Africa’s giant infrastructure projects,” CNN. http://edition. cnn.com/2013/10/10/business/tech-cities-dams-africa- infrastructure/; Curnow, R. and Kermeliotis, T. (2012, April 5). “The daily grind of commuting in Africa’s economic hubs,” CNN. http://edition.cnn.com/2012/04/05/world/ 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: http://macs.about.com/b/a/087641.htm; 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: http://www.computerweekly.com/blogs/ 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. www.bostonglobe.com/news/nation/2013/09/13/ nation-bloated-nuclear-spending-comes-under-fire/ O2uP7gv06vTAEw0AIcCIlL/story.html

19. “How to establish an organizational culture that pro- motes projects,” www.bia.ca/articles/HowToEstablisha 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. www.thefiscaltimes.com/Articles/2014/06/12/How- 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. csmonitor.com/USA/Military/2013/0712/Rebuilding-Iraq- 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. www.theguardian.com/media/media-blog/ 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. www.theguardian.com/media/2013/may/24/bbc-tech- nology-project-digital-media-initiative; Commons Select Committee. (2014, April 10). “BBC’s Digital Media Initiative a complete failure.” www.parliament.uk/business/com- 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.” www.bbc.com/news/entertainment- arts-25433174; Daniel, E., and Ward, J. (2013, June). “BBC’s DMI project failure is a warning to all organisations,” Computer Weekly. www.computerweekly.com/opinion/ 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, www.sptimes.com/2005/12/11/ news_pf/travel/A_new_peak_for_Disney.

35. www.cnn.com/2010/WORLD/americas/10/15/chile. mine.rescue.recap/index.html; www.cnn.com/2010/ OPINION/10/12/gergen.miners/index.html; www. t h e n e w a m e r i c a n . c o m / i n d e x . p h p / o p i n i o n / s a m - blumenfeld/5140-how-americans-engineered-the-rescue- of-the-chilean-miners

36

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

(continued)

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

IntroductIon

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

opportunities

Develop projects that use strengths to minimize

threats

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:

Internal

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

2.2 Stakeholder Management 43

External

• 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 Manager

Clients

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

Testing

Research Labs

Quality

Market Research

Sales

After-Market Support

Advertising

Logistics

Outsourcing

Distribution

Warehousing

Manufacturing

Accounting Services

Contracting

Investments

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

Testing

Board of Directors

Chief Executive

Research Labs

Quality

Market Research

Sales

After-Market Support

Advertising

Vice President of Production

Logistics

Outsourcing

Distribution

Warehousing

Manufacturing

Vice President of Finance

Accounting Services

Contracting

Investments

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

Effective

Ineffective

Very ineffective

Functional organization

Functional matrix

Balanced matrix

Project matrix

Project organization

New product development

Construction

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 Corporate Support

Chief Operating Officer

Sales Delivery Support

PO

PO

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.

Summary

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

(continued)

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.

Questions

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!”

Questions

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.

Questions

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.

Questions

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, www.wegmans.com, 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 www.projectstakeholder.com 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. fluor.com/sustainability/ethics_compliance/Pages/ 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

Objectives

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.

Constraints

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,”

Notes

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. chalmers.se/publications/ 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,. www.bbc.com/ 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. vg247.com/2013/07/24/gibeau-you-get-the-best-games- 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. http://venturebeat.com/2013/07/23/ 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

76

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 “PM@Siemens” 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

IntroductIon

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.

solution

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.

solution

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

Score

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

(0.140)

Poor

Fair

Good

Very Good

Excellent

Strategy

(0.340)

Market Share

Retention

Cost Mgmt.

Short-term

Long-term

Finance

(0.520)

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.

Nominal

Poor 0.00000 0.000

0.050

1.000

0.500

0.300

0.150

2.00000

1.00000

0.60000

0.30000

0.10000Fair

Excellent

Total

Very Good

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

Finance

Poor 1 (.000)

Fair 2 (.100)

Alternatives

1 Perfect Project 1.000 Excellent Excellent Excellent Excellent Excellent Excellent

Excellent

Excellent

Excellent

Excellent

Excellent

Excellent

Excellent

Very Good Very Good Very Good Very Good Very Good Very Good

Very GoodFairPoor

Good

Good

Good

Good

Good

Good

Good

Good

0.762

0.538

0.284

0.600

Aligned

Not Aligned

All Very Good

Mixed

2

3

4

5

6

7

8 9

10

Total

Finance

Short-Term Long-Term

Strategy

Market Share Retention Cost Management

Technology

.1400.0816.1564.1020.3640.1560

Good 3 (.300)

Very Good 4 (.600)

Excellent 5 (1.000)

Short-term

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

k

Return

Maximum Desired Risk

Minimum Desired Return

X6

X2

X4 X5

X3

X1

Efficient Frontier

fIgure 3.4 Profile Model

3.2 Approaches to Project Screening and Selection 89

Risk

12

10

8

6

4

2

8%6% 10% 12% 16% 20% 24% 28% 32%

Return

Maximum Allowable Risk

Efficient Frontier

Saturn

Mercury

Minimum Desired Return

X2

X3

X1

X4

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

solution

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?

solution

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

where

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

solution

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

ACFt

(1 + IRR)t

where

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?

solution

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.

(continued)

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

Reject

Approval

Approval

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

High

H ig

h P

ro b

a b

il it y o

f S

u c c e s s

L o

w

T e c h

n ic

a l

F e a s ib

il it

y –

H o

w e

a s y i

s i

t?

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

MAMAA

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

Implementation

Planning

I

II

III

Pre

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.

Summary

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?

SoluTIoN

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%.

SoluTIoN

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

inflows

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

SoluTIoN

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?

Problems

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

medium

Project B is rated:

Payoff potential low Safety medium

Lack of risk medium Competitive advantage

medium

Project C is rated:

Payoff potential medium Safety low

Lack of risk medium Competitive advantage

low

Project D is rated:

Payoff potential high Safety medium

Lack of risk high Competitive advantage

medium

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.

D E

C

Risk F

B

A

Return

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.

Questions

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?

(continued)

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

Score

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.

Questions

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: www.merck.com/ about/

b. Boeing Corporation: http://www.boeing.com/boeing/ companyoffices/aboutus/index.page

c. Rolls-Royce, Plc.: www.rolls-royce.com d. ExxonMobil, Inc.: www.exxonmobil.com/Corporate/

about.aspx

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 www-01.ibm.com/software/awd- 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?

Notes

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, http://ftp.dot.state.tx.us/pub/ 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. www.atlantic-ec.com/edm/edm132/images/ 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,” RenewableEnergyWorld.com. www.renewableenergy- world.com/rea/news/article/2008/09/the-elephant- 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.

115

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

introduction

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.

administer

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

innovate

command respect

develop new processes focus on people

inspire trust

have long-term goal

focused on potentialoriginate

do the right thing

earn their position

LEADERS

MANAGERS

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.

communicating

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.

Summary

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

(continued)

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.

Questions

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.

Questions

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

Director

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

(continued)

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.

Questions

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 www.debian.org/devel/leader 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 http://lwn.net/ 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 www.computerworld.com/s/article/78274/Blind_Faith? 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

Notes

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- tion.com/people/awards/2013/0128-london-olympics- 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. www.telegraph.co.uk/finance/ 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. ac.uk/newsevents/news/2012/Pages/armittaward. aspx; Bose, M. (2012, February 7). “ Sir John Armitt: We’ve made a magical place in London for the next 100 years.” www.mihirbose.com/index.php/sir-john-armitt-weve- 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.” www.npr.org/tem- 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.” www.rediff.com/ 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. http://forbesindia.com/article/leader- 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 www.nap.edu/ 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.

144

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 Dotcom.com 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 (www.healthcare.gov) 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

(continued)

146 Chapter 5 • Scope Management

IntroductIon

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

project.

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 Completion

CBA 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.0

1.2 1.3 1.4 1.5

1.2.1

1.2.2

1.2.3

1.3.1

1.3.2

1.4.1

1.4.2

1.4.3

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

Deliverables

1.3 1.4 1.5

1.0

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

Procurement

Information Systems

Departments

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

Notification

Responsible Support

Approval

James Engineering

FIgure 5.10 responsibility Assignment Matrix

IT Installation

Project

Deliverables

1.3 1.4 1.5

1.0

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

Procurement

Information Systems

Departments

Totals

$500

$500

$500

$1,500$0

$0

$1,000

$1,000

$0

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.

Summary

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

Questions

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.

(continued)

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

Questions

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 Dotcom.com

Dotcom.com, 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 Dotcom.com 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

(continued)

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 Dotcom.com?

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

Questions

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 http://4pm.com/category/project‐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 http://www.docstoc.com/docs/85831907/Proposal- 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 https://www.mtholyoke.edu/sites/default/files/ 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.

Approvals:

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

Responsible

Notification

Support

Approval

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 healthcare.gov’s first day, documents show,” NBC News. www.nbcnews.com/news/other/only-6-able-sign- healthcare-govs-first-day-documents-show-f8C11509571; Reinen, J. (2013, September 9). “Obamacare is the worst new-product rollout in memory,” Minnpost. www. minnpost.com/health/2013/09/obamacare-worst- 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:// spectrum.ieee.org/riskfactor/computing/it/obamacare- exchange-signups-not-so-much; Lane, D. (2014, January 15). “Cover Oregon head:  State might scrap all or part of failing website,” KATU.com. www.katu.com/news/ 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,” KATU.com; www.katu.com/news/ 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. www.fgdc.gov/geospatial-lob/smartbuy/understanding- 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:// www.acquisition.gov/comp/seven_steps/library/ 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.” http://island-adv.com/2010/11/ border-% E2%80%9Cvirtual-fence%E2%80%9D-project-a- costly-failure/; Krigsman, M. (2007, August 23). “Boeing virtual fence: $30 billion failure.” www.zdnet.com/ blog/project failures/boeing-virtual-fence-30-billion- failure/36; Krigsman, M. (2007, September 24). “Update: Boeing’s virtual fence ‘unusable.’” www.zdnet.com/ blog/projectfailures/update-boeing-virtual-fence-unus- able/403; Lipowicz, A. (2010, April 21). “Senate committee chairman suggests killing Boeing’s virtual fence.” http:// washingtontechnology.com/ 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.” www.theinvestigativefund.org/investigations/ immigrationandlabor/1243/fencing_the_ border%3A _boeing%27s_high-tech_plan_falters

26. California High-Speed Rail Authority Web site, www. cahighspeedrail.ca.gov/home.aspx; Castaneda, V., and

Notes

Notes 185

Severston, A. (2010, October 11). “Economists say high- speed rail system won’t make money.” http://menlopark. patch.com/articles/economists-say-high-speed-rail- 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.” www.cc-hsr. org/assets/pdf/CHSR-Financial_Risks-101210-D.pdf; Garrahan, M. (2009, October 6). “California keen to set the pace.” Financial Times, www.ft.com/cms/s/0/1c0b3676- 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:// online.wsj.com/article/SB100014240527487037278045760 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, http://articles.latimes.com/2010/ 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. www.mercurynews.com/ci_22929875/

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:// reason.org/news/show/study-california-high-speed-rail.

27. Feickert, A. (2008). “The Marines’ Expeditionary Fighting Vehicle (EFV): Background and issues for Congress.” Congressional Research Service, Library of Congress. www. dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTR Doc.pdf&AD=ADA486513; Hodge, N. (2010, August 27). “Marines question craft needed to hit the beach,” Wall Street Journal, p. B8; www.wired.com/dangerroom/2008/08/ marines-swimmin/; Merle, R. (2007). “Problems stall Pentagon’s new fighting vehicle.” www.washing- tonpost.com/wp-dyn/content/article/2007/02/06/ AR2007020601997.html; Ackerman, S. (2010). “Senate may finally sink Marines’ swimming tank.” www.wired.com/ dangerroom/ 2010/09/senate-may-finally-sink-marines- swimming- tank/; www.aviationweek.com/aw/jsp_in- cludes/articlePrint. jsp?storyID=news/asd/2010/11/08/01. xml&headLine=null; www.aviationweek.com/aw/generic/ story.jsp?id=news/asd/2010/10/12/08.xml&channel=misc.

186

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

(continued)

Project Profile 187

188 Chapter 6 • Project Team Building, Conflict, and Negotiation

IntroductIon

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

Success?

Success?

Assemble the team

• Develop skills inventory matrix • Develop responsibility matrix • Clarify roles • Clarify methods and procedures

NO

YES

NO

YES

• 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

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

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

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

Testing

InfightingOrganized

Productive

ConveneAdjourn

Inclusion

C on

tr ol

C ooperation

Pr od

uc tiv

ity

• 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

High

Low

Completion

First Meeting

Eruption

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

Accessibility

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.

accessibility

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

(continued)

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 negotiation

One of the most influential books on negotiation in recent years is Getting to Yes, by Roger Fisher and William Ury.34 They offer excellent advice on principled negotiation, the art of getting agree- ment with the other party while maintaining a principled, win-win attitude. Among the sugges- tions they offer for developing an effective negotiating strategy are the following.

SeParate the PeoPle From the ProBlem One of the most important ideas of negotiation is to remember that negotiators are people first. What this dictum means is that negotiators are no dif- ferent from anyone else in terms of ego, attitudes, biases, education, experiences, and so forth. We all react negatively to direct attacks, we all become defensive at unwarranted charges and accusa- tions, and we tend to personalize opposing viewpoints, assuming that their objections are aimed at us, rather than at the position we represent. Consequently, in observing the saliency of the notion that negotiators are people first, we must seek ways in which we can keep people (along with their personalities, defensiveness, egos, etc.) out of the problem itself. The more we can focus on the issues that separate us and pay less attention to the people behind the issues, the greater the likeli- hood of achieving a positive negotiated outcome.

Put yourself in their shoes. An excellent starting point in negotiations is to discuss not only our own position but also our understanding of the other party’s position early in the negotia- tion process. When the other party hears a reasoned discussion of both positions, two important events occur: (1) It establishes a basis of trust because our opponent discovers that we are willing to openly discuss perceptions in the beginning, and (2) it reconstructs the negotiation as a win-win, rather than a winner-take-all, exercise.

Don’t deduce their intentions from your fears. A common side effect of almost all negotiations, particularly early in the process, is to construct supporting stereotypes of the other side. For exam- ple, in meeting with the accountant to negotiate additional funding for our project, we may adopt a mind-set in which all accountants are penny-pinching bean counters who are only waiting for the opportunity to cancel the project. Notice that even before the negotiation takes place, we have created an image of the accounting department’s members and their mind-set based on our own misperception and fears, rather than on any objective reality. When we assume that they will act in certain ways, we subconsciously begin negotiating with them as though money is their sole concern, and before we know it, we have created an opponent based on our worst fears.

Don’t blame them for your problems. In negotiations, it is almost always counterproductive to initiate a finger-pointing episode as we seek to attach blame for difficulties our project has encountered. It is far more effective to move beyond the desire to assign blame and search for win-win solutions. For example, suppose that a company has just developed a software program for internal reporting and control that continually crashes in mid-operation. One approach would be for the exasperated accounting manager to call in the head of the software development project and verbally abuse him: “Your program really stinks. Every time you claim to have fixed it, it dumps on us again. If you don’t get the bugs out of it within two weeks we’re going to go back to the old system and make sure that everyone knows the reason why.”

Although it may be satisfying for the accounting manager to react in this manner, it is unlikely to solve the problem, particularly in terms of relations with the software development project team. A far better approach would be less confrontational, seeking to frame the problem as a mutual issue that needs correction. For example, “The reporting program crashed again in midstride. Every time it goes down, my people have to reenter data and use up time that could be spent in other ways. I need your advice on how to fix the problem with the software. Is it just not ready for beta testing, are we using it incorrectly, or what?” Note that in this case, the head of the accounting department is careful not to point fingers. He refrains from taking the easy way

6.8 Negotiation 211

out through simply setting blame and demanding correction, and instead treats the problem as a problem that will require cooperation if it is to be resolved.

Recognize and understand emotion: theirs and yours. Although it is often easy to get emotional during the course of a negotiation, the impulse must be resisted as much as possible.35 It is com- mon in a difficult, protracted negotiation to see emotions begin to come to the surface, often due to anger or frustration with the tactics or attitudes of the other party. Nevertheless, it is usually not a good idea to respond in an emotional way, even when the other party becomes emotional. They may be using emotion as a tactic to get your team to respond in an equally emotional way and allow your heart to begin guiding your head—always a dangerous course. Although emotions are a natural side effect of lengthy negotiations, we need to understand precisely what is making us unhappy, stressed, tense, or angry. Further, are we astute enough to take note of the emotions emanating from our opponent? We need to be aware of what we are doing that is making the other person upset or irritable.

Listen actively. Active listening means our direct involvement in the conversation with our opponent, even when the other party is actually speaking. Most of us know from experience when people are really listening to us and when they are simply going through the motions. In the latter case, our frustration at their seeming indifference to our position can be a tremendous source of negative emotion. For example, suppose a client is negotiating with the project manager for a per- formance enhancement on a soon-to-be-released piece of manufacturing equipment. The project manager is equally desirous to leave the project alone because any reconfigurations at this time will simply delay the release of the final product and cost a great deal of extra money. Every time the client voices her issues, the project manager speaks up and says, “I hear what you’re saying, but . . . .” In this case, the project manager clearly is not hearing a word the client is saying but is simply paying lip service to the client’s concerns.

Active listening means working hard to understand not simply the words but the underly- ing motivations of the other party. One effective technique involves interrupting occasionally to ask a pointed question: “As I understand it, then, you are saying . . . .” Tactics such as this con- vince your opponent that you are trying to hear what is being said rather than simply adhering to your company’s party line no matter what arguments or issues the other side raises. Remember that demonstrating that you clearly understand the other party’s position is not the same thing as agreeing with it. There may be many points with which you take issue. Nevertheless, a construc- tive negotiation can only proceed from the point of complete and objective information, not from preconceived notions or entrenched and intransigent positions.

Build a working relationship. The idea of negotiating as though you are dealing with a party with whom you would like to maintain a long-term relationship is key to effective negotiations. We think of long-term relationships as those with individuals or organizations that we value and, hence, are inclined to work hard to maintain. The stronger the working relationship, the greater the level of trust that is likely to permeate its character.

FocuS on IntereStS, not PoSItIonS There is an important difference between the positions each party adopts and the interests that underscore and mold those positions. When we refer to “interests,” we mean the fundamental motivations that frame each party’s positions. As Fisher and Ury note, “Interests define the problem.”36 It is not the positions taken by each party that shape the negotiation nearly as much as it is the interests that are the source of the parties’ fears, needs, and desires.

Why look for underlying interests as opposed to simply focusing on the positions that are placed on the table? Certainly, it is far easier to negotiate with another party from the point of our position versus theirs. However, there are some compelling reasons why focusing on interests rather than positions can offer us an important “leg up” in successful negotiations. First, unlike positions, for every interest there are usually several alternatives that can satisfy it. For example, if my major interest is to ensure that my company will be in business over the years to come, I can look for solutions other than simply squeezing every drop of profit from the contractor in this nego- tiation. For example, I could enter into a long-term relationship with the contractor in which I am willing to forgo some profit on this job while locking the contractor into a sole-source agreement for the next three years. The contractor would then receive the additional profit from the job by paying me less than I desire (my position) while supplying me with long-term work (my interest).

212 Chapter 6 • Project Team Building, Conflict, and Negotiation

Another reason for focusing on interests argues that negotiating from positions often leads to roadblocks as each party tries to discover their opponent’s position while concealing their own. We consume valuable time and resources in making visible our various positions while hiding as long as possible our true intentions. In focusing on interests, on the other hand, we adopt a partnering mentality that acknowledges the legitimacy of both sides’ interests and seeks to find solutions that will be mutually satisfying.

Invent options for mutual gain

Managers sometimes put up roadblocks for themselves, making it difficult to consider win-win options when negotiating.

Managers can have premature judgment. We quickly arrive at conclusions about the other side and anything they say usually serves to solidify our impressions. Further, rather than seek to broaden our various options early in the negotiation, we typically go the other direction and put limits on how much we are willing to give up, how far we are willing to go, and so forth. Every premature judgment we make limits our freedom of action and puts us deeper into an adversarial, winners-losers exchange.

Some managers search only for the best answer. A common error made is to assume that bur- ied underneath all the negotiating ploys and positions is one “best” answer that will eventu- ally emerge. In reality, most negotiations, particularly if they are to result in win-win outcomes, require us to broaden our search, not limit and focus it. For example, we may erroneously define the “best” answer to typically mean the best for our side, not the other party. It is important to acknowledge that all problems lend themselves to multiple solutions. Indeed, it is through consideration of those multiple solutions that we are most likely to attain one that is mutually satisfying.

Managers assume that there’s only a “fixed pie.” Is there really only a fixed set of alternatives available? Maybe not. It is common to lock into a “I win, you lose” scenario that virtually guaran- tees hardball negotiating with little or no effort made to seek creative solutions that are mutually satisfying.

Thinking that “solving their problem is their problem” is another roadblock. Negotiation breeds egocentrism. The greater our belief that negotiation consists of simply taking care of ourselves, the greater the likelihood that we will be unwilling to engage in any win-win solutions. Our position quickly becomes one of pure self-interest.

If these are some common problems that prevent win-win outcomes, what can be done to improve the negotiation process? There are some important guidelines that we can use to strengthen the relationship between the two parties and improve the likelihood of positive out- comes. Briefly, some options to consider when searching for win-win alternatives include positive and inclusive brainstorming, broadening options, and identification of shared interests.

The use of positive and inclusive brainstorming implies that once a negotiation process begins, during its earliest phase we seek to include the other party in a problem-solving session to identify alternative outcomes. This approach is a far cry from the typical tactic of huddling to plot nego- tiation strategies to use against the other team. In involving the other party in a brainstorming session, we seek to convince them that we perceive the problem as a mutually solvable one that requires input and creativity from both parties. Inviting the other party to a brainstorming session of this type has a powerfully disarming effect on their initial defensiveness. It demonstrates that we are interested not in beating the other side, but in solving the problem. Further, it reinforces the earlier point about the necessity of separating the people from the problem. In this way, both par- ties work in cooperation to find a mutually satisfactory solution that also serves to strengthen their relationship bonds.

The concept of broadening options is also a direct offshoot of the notion of brainstorming. Broadening our options requires us to be open to alternative positions and can be a natural result of focusing on interests rather than positions. The more I know about the other party’s interests and am willing to dissect my own, the greater the probability that together we can work to create a range of options far broader than those we may initially be tempted to lock ourselves into.

Finally, a third technique for improving chances for win-win outcomes is to identify shared interests. A common negotiating approach employed by experienced bargainers is to sometimes

6.8 Negotiation 213

table the larger items to a later point in the negotiation, focusing instead on minor or peripheral issues that offer a greater likelihood of reaching agreement. Once the two parties begin to work together to identify their shared interests and gain some confidence from working in a collabora- tive way, it is possible to reintroduce the larger sticking points. By this time both sides have begun to develop a working rhythm and a level of harmony that makes it easier to look for shared inter- ests within these larger issues.

Insist on using objective criteria

One of the best methods for ensuring that a negotiation proceeds along substantive lines is to frame the discussion around objective criteria.37 Do not get bogged down in arguing per- ceptions or subjective evaluations. For example, a project manager recently almost had his new product development (NPD) project canceled because of protracted negotiations with a client over delivering an “acceptable” working prototype. Obviously, the project man- ager had a far different interpretation of the word acceptable than did the client. The project manager assumed that acceptable included normal bugs and preliminary technical problems whereas the client had used the word to imply error-free. In their desire to pin the onus of responsibility on the other, neither was willing to back away from her interpretation of the nebulous “acceptable.”

Objective data and other measurable criteria often form the best basis for accurate negotia- tions. When firms or individuals argue costs, prices, work hours, and so on, they are using estab- lished standards and concepts that both parties can understand with a minimum of interpretation error. On the other hand, the more vague the terms employed or the more subjective the language, the greater the potential to be arguing at cross-purposes, even if both parties assume that the other is using the same interpretations of these terms.

Develop fair standards and procedures. Whatever standards are used as the basis of the negotia- tion need to be clearly spelled out and put in terms that are equally meaningful to both parties. This point is particularly relevant in cross-cultural negotiations in that different countries and cul- tures often attach different meaning to terms or concepts. For example, several American heavy construction firms, including Bechtel Corporation, lodged a protest against a number of Japanese construction firms for their collusion in dividing up biddable contracts (bid rigging) prior to a major airport project in Tokyo Bay. The Japanese companies argued in turn that they were fulfill- ing the terms of recent free-competition agreements by simply allowing Bechtel to submit a bid. Further, in Japanese society, there is nothing inherently illegal or unethical about engaging in this form of bid rigging. Clearly, both parties had very different interpretations of the idea of fair and clear bidding practices.

Fair standards and procedures require that both parties come together and negotiate from the same basic understanding of the terms and liabilities. In project management, this concept is particularly relevant because construction contracting requires a universally understood set of terms and standards. When the two parties are engaged in negotiating from the point of appro- priate standards, it effectively eliminates the source of many potential misunderstandings or misinterpretations.

In visualizing the need to become adept at team building, conflict management, and nego- tiation, it is important to remember that the greatest challenges project managers typically face in running their projects are the myriad “people” challenges that result from the process of forming a diverse set of project members into a unified and collaborative team, whose goal is to pursue proj- ect success. Creating a team and initiating the project development process sows the seeds for a wide variety of conflicts among all project stakeholders. These conflicts are inevitable. They should be treated not as a liability, however, but as an opportunity. Conflict can lead to positive outcomes by solidifying team member commitment and motivation, and generating the energy to complete project activities.

Nevertheless, channeling conflict in appropriate ways requires a sure touch on the part of the project manager. Our ability to sustain influence and use negotiation in skillful ways is a great advantage in ensuring that team development and conflict serve not to derail the project but to renew it. Conflict is inevitable; it is not disastrous. Indeed, the degree to which a conflict disrupts a project’s development depends upon the project manager’s willingness to learn enough about conflict to deal with it effectively.

214 Chapter 6 • Project Team Building, Conflict, and Negotiation

Summary

1. Understand the steps involved in project team building. The first step in project team building is the selection of personnel to staff the project team. This process can be complicated, particularly due to the high potential for conflict and negotiation with functional managers who may retain effective con- trol over project team members. Following an anal- ysis of skill requirements and staff availability, the team-building process typically involves matching the best people to the identified project tasks, while at the same time understanding the need to make these staffing decisions in collaboration with other top managers or departmental heads.

2. Know the characteristics of effective project teams and why teams fail. High-performing teams are typically characterized by (1) a clear sense of mis- sion, (2) an understanding of interdependencies, (3) cohesiveness, (4) trust, (5) enthusiasm, and (6) a results orientation. On the other hand, teams that fail often do so due to poorly developed goals, poorly defined team roles, lack of motivation, poor communication, poor leadership, high project team turnover, and dysfunctional behavior.

3. Know the stages in the development of groups. Project teams do not begin their assignments as a unified, cohesive, and motivated body. Rather, their development is a challenge that must be effectively managed if we are to get maximum performance from the team. Teams go through some identifi- able stages in their development process, and proj- ect managers need to recognize and seek to manage these developmental stages as efficiently as they can. One model of team development posits a five-stage approach—forming, storming, norming, performing, and adjourning—each with its unique challenges and group behaviors. An alternative model that has been validated through research argues that groups adopt a process of “punctuated equilibrium” as they evolve.

4. describe how to achieve cross-functional coopera- tion in teams. Superordinate goals, rules and pro- cedures, physical proximity, and accessibility are all important factors in motivating people to collabo- rate. The effects of this cross-functional cooperation are twofold: They can positively impact both proj- ect task outcomes and psychosocial project team results. Task outcomes positively affect the project

at hand, while psychosocial outcomes mean that team members retain high positive attitudes toward the project experience and will enter new projects with strong motivation to succeed again.

5. see the advantages and challenges of virtual project teams. Virtual project teams are defined as the use of electronic media, including e-mail, the Internet, and teleconferencing, to link together members of a geographically dispersed project team, largely because of the globalization of project management. As multinational firms attempt to manage proj- ects from geographically dispersed units, they need sophisticated technical media that support their com- munications and networking. The sheer physical barriers caused by globalization, coupled with the increase in multiorganizational project teams, have led to the increased use of virtual technologies to link team members. Two of the biggest challenges in effec- tively creating and managing virtual teams are estab- lishing and reinforcing trust among team members and establishing effective communication patterns.

6. Understand the nature of conflict and evaluate response methods. Conflict is an inevitable result when team members with diverse functional back- grounds, personalities, experiences, and attitudes are brought together and expected to work collab- oratively. Among the organizational causes of con- flict are scarce resources, uncertainty over lines of authority, and differentiation. Interpersonal causes of conflict include faulty attributions, faulty com- munication, and personal grudges and prejudice. Conflict can be addressed through mediation, arbi- tration, control, acceptance, or elimination.

7. Understand the importance of negotiation skills in project management. Project managers routinely negotiate with a wide variety of organizational stake- holders for resources, contractual considerations, terms and conditions, and so forth. Effective project managers are often those individuals who approach negotiations in a systematic manner, taking the time to carefully analyze the nature of the negotiation, what they hope to achieve, and how much they are willing to offer to achieve their important goal. In principled negotiation, the primary objective is to seek win-win alternatives that allow both parties to negotiate to gain their goals.

Key Terms

Accessibility (p. 201) Adjourning (p. 198) Administrative conflict (p. 205) Cohesiveness (p. 193) Conflict (p. 205)

Cross-functional cooperation (p. 199) Differentiation (p. 192) Forming stage (p. 197) Frustration (p. 207) Goal-oriented conflict (p. 205)

Interaction (p. 193) Interdependencies (p. 192) Interpersonal conflict (p. 205) Negotiation (p. 209) Norming stage (p. 198)

Orientation (p. 194) Outcomes (p. 194) Performing stage (p. 198) Physical proximity (p. 201) Principled negotiation (p. 210)

Case Study 6.1 215

Psychosocial outcomes (p. 201) Punctuated equilibrium (p. 198)

Storming stage (p. 197) Superordinate goal (p. 199)

Task outcomes (p. 201) Team building (p. 188)

Trust (p. 193) Virtual teams (p. 202)

Discussion Questions

6.1 This chapter discussed the characteristics of high- performing project teams. List the factors that characterize these teams and give examples of each one.

6.2 “Trust can actually encourage disagreement and conflict among team members.” Explain why this could be the case.

6.3 Identify the stages of group development. Why is it nec- essary for project teams to move through these stages in order to be productive?

6.4 Gersick’s model of punctuated equilibrium offers an al- ternative view of group development. Why does she sug- gest that some defining moment (such as an explosion of emotion) often occurs about midpoint in the project? What does this defining event accomplish for the team?

6.5 Explain the concepts of “task” and “psychosocial” out- comes for a project. Why are psychosocial outcomes so important for project team members?

6.6 Distinguish between the traditional, behavioral, and inter- actionist views of team conflict. How might each explain and treat a project team conflict episode?

6.7 Identify the five major methods for resolving conflict. Give an example of how each might be applied in a hypotheti- cal project team conflict episode.

6.8 What are some of the guidelines for adopting a strategy of “principled negotiation”?

6.9 Explain the idea that we should “focus on interests, not po- sitions.” Can you think of an example in which you suc- cessfully negotiated with someone else using this principle?

CaSe STuDy 6.1 Columbus Instruments

(continued)

Problems have been building at Columbus Instruments, Inc. (CIC) (not its real name) for several years now with the new product development process. The last six high-visibility projects were either scrapped outright after excessive cost and schedule overruns or, once re- leased to the marketplace, were commercial disasters. The company estimates that in the past two years, it has squandered more than $15 million on poorly de- veloped or failed projects. Every time a new project venture failed, the company conducted extensive post- project review meetings, documentation analysis, and market research to try to determine the underlying cause. To date, all CIC has been able to determine is that the problems appear to lie with the project man- agement and development process. Something some- where is going very wrong.

You have been called into the organization as a consultant to try to understand the source of the prob- lems that are leading to widespread demoralization across the firm. After spending hours interviewing the senior project management staff and technical person- nel, you are convinced that the problem does not lie with their processes, which are up-to-date and logi- cal. On the other hand, you have some questions about project team productivity. It seems that every project has run late, has been over budget, and has had subop- timal functionality, regardless of the skills of the project

manager in charge. This information suggests to you that there may be some problems in how the project teams are operating.

As you analyze CIC’s project development pro- cess, you note several items of interest. First, the company is organized along strictly functional lines. Projects are staffed from the departments following negotiations between the project manager and the department heads. Second, the culture of CIC seems to place little status or authority on the project managers. As evidence of this fact, you note that they are not even permitted to write a performance evaluation on proj- ect team members: That right applies only to the func- tional department heads. Third, many projects require that team members be assigned to them on an exclusive basis; that is, once personnel have been assigned to a project, they typically remain with the project team on a full-time basis for the term of the project. The average project lasts about 14 months.

One morning, as you are walking the hallways, you notice a project team “war room” set up for the latest new product development initiative within the company. The war room concept requires that proj- ect team members be grouped together at a central location, away from their functional departments, for the life of the project. What intrigues you is a hand- lettered sign you see taped to the door of the project

216 Chapter 6 • Project Team Building, Conflict, and Negotiation

war room: “Leper Colony.” When you ask around about the sign, some members of the firm say with a chuckle, “Oh, we like to play jokes on the folks assigned to new projects.”

Further investigation of project team members suggests they are not amused by the sign. One engineer shrugs and says, “That’s just their way of making sure we understand what we have been assigned to. Last week they put up another one that said ‘Purgatory.’” When you ask the project manager about the signs later in the day, he confirms this story and adds some inter- esting information: “Around here, we use detached [meaning centralized] project teams. I get no say as to who will be assigned to the project, and lately the func- tional heads have been using our projects as a dumping ground for their poor performers.”

When you question him further, the project man- ager observes, “Think about it. I have no say in who gets assigned to the team. I can’t even fill out a per- formance review on them. Now, if you were a depart- ment head who was trying to offload a troublemaker or someone who was incompetent, what could be bet- ter than shipping them off to a project team for a year or so? Of course, you can imagine how they feel when they hear that they have been assigned to one of our project teams. It’s as if you just signed their death war- rant. Talk about low motivation!”

When you question various department heads about the project manager’s assertions, to a person they deny that this is an adopted policy. As the head of finance puts it, “We give the project teams our best available people when they ask.” However, they also admit that they have the final say in personnel assign- ment and project managers cannot appeal their choices for the teams.

After these discussions, you suggest to the CEO that the method of staffing projects may be a reason for the poor performance of CIC’s new product develop- ment projects. He ponders the implications of how the projects have been staffed in his organization, and then says, “Okay, what do you suggest we do about it?”

Questions

1. What are the implications of CIC’s approach to staffing project teams? Is the company using project teams as training grounds for talented fast-trackers or as dumping grounds for poor performers?

2. How would you advise the CEO to correct the problem? Where would you start?

3. Discuss how issues of organizational structure and power played a role in the manner in which project management declined in effectiveness at CIC.

CaSe STuDy 6.2 The Bean Counter and the Cowboy

The morning project team meeting promised to be an interesting one. Tensions between the representa- tive from marketing, Susan Scott, and finance, Neil Schein, have been building for several weeks now—in fact, since the project team was formed. As the project manager, you have been aware that Susan and Neil do not see eye to eye, but you figured that over time they would begin to appreciate each other’s perspective and start cooperating. So far, unfortunately, that has not happened. In fact, it seems that hardly a day goes by when you do not receive a complaint from one or the other regarding the other team member’s behavior, lack of commitment or cooperation, or general shoddy performance.

As the team gathers for the regular project status meeting, you start with an update on the project tasks, any problems the team members are having, and their assessment of the project’s performance to date. Before you get too far into the meeting, Susan interrupts,

saying, “John, I’m going to be out of town for the next 10 days visiting clients, so I can’t make the status meet- ings either of the next two Fridays.”

“That figures,” Neil mutters loud enough for all to hear.

Susan whirls around. “I have another job around here, you know, and it involves selling. It may be con- venient for you to drop everything and come to these meetings, but some of us have other responsibilities.”

Neil shoots back, “That’s been your excuse for missing half of the meetings so far. Just out of curios- ity,” he continues sarcastically, “how many more do you figure on blowing off while hanging out poolside on your little out-of-towners?”

Susan turns bright red. “I don’t need to put up with that from you. You bean counters have no clue how this business works or who delivers value. You’re so busy analyzing every penny that you have perma- nent eyestrain!”

Case Study 6.3 217

“Maybe I could pay attention if I didn’t have to constantly stay on the backs of you cowboys in sales,” counters Neil. “I swear you would give our products away if it would let you make your quarterly numbers, even if it does drive us into the ground!”

You sit back, amazed, as the argument between Neil and Susan flares into full-scale hostility and threatens to spin out of control. The other team mem- bers are looking at you for your response. George, from engineering, has a funny expression on his face, as if to say, “Okay, you got us to this point. Now what are you going to do about it?”

“People,” you rap on the table, “that’s enough. We are done for today. I want to meet with Susan and Neil in my office in a half hour.”

As everyone files out, you lean back in your seat and consider how you are going to handle this problem.

Questions

1. Was the argument today between Neil and Susan the true conflict or a symptom? What evidence do you have to suggest it is merely a symptom of a larger problem?

2. Explain how differentiation plays a large role in the problems that exist between Susan and Neil.

3. Develop a conflict management procedure for your meeting in 30 minutes. Create a simple script to help you anticipate the comments you are likely to hear from both parties.

4. Which conflict resolution style is warranted in this case? Why? How might some of the other resolution approaches be inadequate in this situation?

CaSe STuDy 6.3 Johnson & Rogers Software Engineering, Inc.

(continued)

Kate Thomas, a project manager with Johnson & Rogers Software Engineering, was looking forward to her first project team “meeting.” She applied quotes to the term “meeting” because she would not actually be sitting down at a table with any of the other members of the project team. She had been assigned responsibility for a large software development project that would be using team members from both inside and outside the organi- zation, none of whom were currently employed at the same Redlands, California, office where she worked. In fact, as she ticked off the names on the legal pad in front of her, she did not know whether to be impressed or ap- prehensive with the project she was about to kick off.

Vignish Ramanujam (senior programmer)—New Delhi, India

Anders Blomquist (systems designer)—Uppsala, Sweden

Sally Dowd (systems engineer)—Atlanta, Georgia Penny Jones (junior programmer)—Bristol,

England Patrick Flynn (junior programmer)—San Antonio,

Texas Erik Westerveldt (subcontractor)—Pretoria,

South Africa Toshiro Akame (customer representative)—Kyoto,

Japan

The challenge with this team, Kate quickly real- ized, was going to involve figuring out how to create

an integrated project team with these people, most of whom she had never dealt with before. Although Sally and Patrick worked for Johnson & Rogers at other plant locations, the rest of the “team” were strangers. Erik, from South Africa, was critical for the project because his company had developed some of the specialized processes the project required and was to be treated as an industrial partner. The other mem- bers of the team had been assembled either by Erik or through contacts with senior members of her own firm. She did not know, but would soon discover, how they felt about the project and their level of commit- ment to it.

The first virtual project meeting was scheduled to start promptly at 9 am Pacific Standard Time. That led to the first problem. As Kate stared at the camera mounted above the video monitor, she kept glanc- ing down at the screen for signs that other members of the team had logged on. Finally, at 9:15, she was joined by Sally, with Toshiro logging in shortly after- ward. As they chatted and continued to wait for other members to log on, time continued to pass. When, at 9:30, no one else had signed on, Kate asked the sec- retary to start making phone calls to verify that other members of the team were trying to access the system. Eventually, by 10:25, the team consisted of five mem- bers: Anders, Sally, Penny, Patrick, and Toshiro. It was decided that for the sake of getting something accom- plished, those who were logged on would get started.

218 Chapter 6 • Project Team Building, Conflict, and Negotiation

The agenda that Kate had prepared and e-mailed out the day before was produced and the meeting began. Within 10 minutes, the video link to Penny was sud- denly lost. The other team members waited for five minutes, shuffling in various states of impatience for Penny to rejoin the meeting. There was still no sign of Vignish or Erik.

The meeting quickly bogged down on techni- cal details as those in attendance realized that several technical issues could not be resolved without input from the missing team members. Though he tried his best to hide it, it became apparent that Toshiro, in particular, was frustrated with the lack of progress in this meeting. Kate suggested that they adjourn until 11, while she made another attempt to contact the missing members, but Toshiro objected, saying, “That is 3 am in my country. It is now past midnight here. I have been here today for 15 hours and I would like to get home.” It was finally agreed to reconvene tomor- row at the same time. Toshiro agreed, but with bad grace: “Can we not find a time that is more accommo- dating to my schedule?” Kate promised to look into the matter.

The next day’s meeting was a mixed success. Although everyone managed to log on to the system within a reasonable period, Penny’s connection kept going down, to the exasperation of Vignish, the senior programmer. Although the meeting was conducted with great politeness by all parties, it was equally clear that no one was willing to offer their candid opinions of the project, the goals, and how the team was expected to execute their assignments. After asking members of the team for honest feedback and getting little response, Kate eventually dropped the point. In addition, she had a nagging feeling that there was some unspoken animosity in the manner in which Patrick and Sally interacted with each other.

After some general goal setting and a discussion of team responsibilities, Kate asked if there was a time when they could next meet. In the general silence that followed, Anders spoke up, asking, “Well, how often do you hope to meet like this? To be honest, it is inconvenient for me to attend these sessions regularly, as our telecom equipment is in Stockholm and I have to drive an hour each way.”

Toshiro then spoke up as well. “I am sorry to repeat this point,” he said, “but these meeting times are extremely inconvenient for me. Could we not find a time that is more generally acceptable?”

Kate replied, “Well, how about 5 pm my time. That’s . . .,” Kate paused and quickly consulted her per- sonal planner, “9 in the morning for you.”

This suggestion was met by a wave of objections, with the first from Penny who stated, “Uh, Kate, that would be 1 am here in England.”

No sooner had she spoken than Anders, Erik, and Vignish chimed in, “Kate, that’s 2 am in Stockholm and Pretoria,” and “Kate, are you aware that that is 6 am here in New Delhi?”

Back and forth the team members argued, trying to find a reasonable time they could all meet. Finally, after going around the group several times to work out a mutually agreeable time for these teleconfer- ences, Erik spoke up: “Maybe we don’t all need to meet at the same time, anyway. Kate, why don’t you just schedule meetings with each of us as you need to talk?”

Kate objected by saying, “Erik, the whole point of these teleconferences is to get the team together, not to hold one-on-one meetings with each of you.”

Erik responded, “Well, all I know is that this is only the first videoconference and already it is becom- ing a burden.”

Penny spoke up, “You’re lucky. At least your sys- tem works. Mine keeps going up and down at this end.”

“Okay, how about just using e-mails?” suggested Erik. “That way it does not matter what the time is at our location.”

The other team members agreed that this idea made sense and seemed on the verge of endorsing the use of e-mails for communications. At this point, Kate stepped back into the discussion and stated firmly, “Look, that won’t do. We need the opportunity to talk together. E-mails won’t do that.”

More arguing ensued. Eventually, the team mem- bers signed off, agreeing that they needed to “talk fur- ther” about these issues. Kate’s reaction was one of disappointment and frustration. She sensed reluctance among the other members of the team to talk about these issues and to use the videoconferencing system in the manner she had envisioned. As Kate sat down to lunch that noon, she pondered how she should proceed from here.

Questions

1. How would you advise Kate to proceed? Analyze the conversation she had this morning. What went right? What went wrong?

2. What should Kate’s next steps be? 3. How can she use the technology of the Internet

and teleconferencing to enhance team develop- ment and performance?

The following is a negotiation scenario between two firms: SteelFabrik, Inc. (SFI) and Building Contractors of Toledo (BCT). You are asked to take either SFI’s or BCT’s side of the negotiation. How would you prepare for this negotiation? How would you attempt to create a win-win outcome for both parties?

SteelFabrik’s Perspective You are the project manager for a new steel fabrication plant construction project being built by Building Con- tractors of Toledo (BCT). Your client is SteelFabrik, Inc. (SFI), a multinational steel products manufacturer. Your timetable calls for completion of the project in 18 months and you have a budget of $6 million. During the last few weeks, it has been increasingly difficult to deal with on- site demands from your client. SFI has insisted on a list of change orders to suit their immediate needs for the plant layout and design. Your counterpart says that because SFI is paying millions for the plant, they are entitled to make appropriate changes to the project for as long as is neces- sary to “get it right.” You are concerned that every day spent in processing change orders adds further delay to your targeted completion date because engineering must approve the changes, design must alter the plans, and fabrication must change the plant’s structure.

BCT is already in trouble on this project. In order to win the work, they significantly underbid their local competitors, leaving very little profit margin in the best- case scenario. Unfortunately, now with the list of change requests, both the budget and the schedule are being stretched to the limit. You are under increasing pressure from upper management to complete the job with the expected profit margin. You have $50,000 to work with and still meet your profitability goals. You are personally under pressure within your organization because your track record for the past three years has not been good— several projects that came in over budget and behind schedule have given top management reason to watch your performance on this project very closely. Although no one has said it out loud, you are fully aware that an- other significant overrun or delay could likely cost you your job with BCT.

Because you view SFI as a potential long-term cus- tomer, you are reluctant to simply refuse their demands. You know that a win-win outcome will likely bring fu- ture SFI business to your firm and could be the source of a profitable backlog of business for at least the next five years. Your own sales department is aware that this proj- ect with SFI could lead to future business and has added to your pressure by constantly stressing the importance of keeping the customer happy. As a result, you have im- portant elements within your own organization, as well as with the customer, all expecting you to successfully complete the project to everyone’s satisfaction.

While reading your e-mails over the weekend, you have come upon the latest set of change orders from SFI for adjustments to the plant layout to accom- modate enhanced rail traffic into and out of the plant. These changes will require that the current construction work be halted, your own engineers and government regulators meet to discuss these requests, and new as- sembly and shipping areas be designed. Based on your experience, you estimate that the changes as requested will add $150,000 to the cost of the project and push the completion date back a minimum of six weeks. Worse, as you examine the change requests, you are convinced that these alterations are unnecessarily complicated and add no value to the plant’s design. The final line of the e-mail is the most troubling: SFI expects these changes to be made immediately and will not allow any sched- ule slippage to accommodate them; in fact, they men- tion that it is imperative that the steel plant become op- erational on schedule. The only good news is that your sales department has found out that SFI may be willing to spend some additional money for the changes, but they aren’t sure how much.

You have just typed out a short note scheduling a meeting for this Wednesday to negotiate an agreement on the requested changes. You are under strong pressure to reach a settlement that preserves BCT’s profit margin, but at the same time you must keep SFI happy. As you sit at your home computer this Sunday afternoon, you are al- ready dreading a return to work tomorrow morning. What approach should you take for the upcoming negotiations?

SFI’s Perspective You are a manager with SteelFabrik, Inc. (SFI) and are responsible for overseeing the construction of their fabri- cation plant in the northwest Ohio region. Recently your management informed you that because of new oppor- tunities, this plant could be extremely valuable to their company, provided the rail spur connecting it with the freight rail system could be modified and upgraded to handle high-volume traffic into and out of the facility. This facility represents a significant investment by your company in the Midwest United States, following sev- eral years of contacts with local government officials try- ing to bring new jobs to the region. As a result, you feel you are entitled to make any necessary adjustments to the project to get the most use out of it. These change requests are, in your opinion, reasonable, necessary, and not prohibitively expensive. However, for the past several weeks, you have been experiencing increasing “push-back” from the BCT project manager to a series of relatively minor change requests. Her approach has been to ridicule the need for the changes, try to use low-cost “quick fixes,” or simply talk you out of them. As a result, you are convinced that these latest change requests will

exercise in Negotiation

Exercise in Negotiation 219

220 Chapter 6 • Project Team Building, Conflict, and Negotiation

also be resisted, and your overall relationship with the BCT project manager has become increasingly strained.

You have casually informed the BCT sales represen- tative that this is the first in what your firm anticipates will be a series of similar plants to be constructed in the Great Lakes region over the next ten years. Although you made no commitments to doing future business with BCT, you have made it clear that successful performance on this project will make them the preferred choice for future work. After all, they understand your needs and have a demonstrated history of project success behind them.

You have been getting pressure from your top man- agement, headquartered in Brussels, to complete the proj- ect on time; in fact, finishing on schedule is your greatest concern. SFI has already been bidding construction proj- ects in the Great Lakes region and has several contracts pending, many of substantial size. Further, local politi- cians are anxious to show the project as an example of a successful public/private partnership and, with local elections coming up, are asking when they can announce its completion. Failure to have the plant ready on time puts you at risk of having to void a series of important construction contracts and slow down hiring, plus it would embarrass you and the region’s government. Be- cause the company’s construction contract bids are still being reviewed, you are anxious to keep this information

confidential to avoid attracting the attention of your com- petitors.

There is $250,000 in your budget to spend on ad- ditional change order costs if necessary, though you are keen to make the best possible impression with your top management by keeping costs as low as possible. You absolutely cannot agree to schedule extensions, howev- er, because of all the pending bids and other pressures to finish the plant on time. Sources in the industry have strongly implied that BCT is in some financial difficulty and needs as much future work as they can get.

Your plant engineers have revised the transportation capacity requirements for the new plant and recommend- ed significant changes to the shipping area to accommo- date extra rail traffic. These changes are deemed critical because of the business model projections your firm has developed for getting maximum use and profit from the new fabrication plant. You have sent an e-mail with a de- tailed set of needed design and construction changes to the BCT project manager late Saturday night and just got back a note requesting a formal meeting on Wednesday morning to discuss these changes and find a way to “re- solve our differences.” You know that means that she is already trying to decide how to respond to your requests, and you are now planning for the negotiation. As you sit and reflect on the pressures you are feeling from Brussels, you wonder what approach you should use.

6.1 Click on the Web page for project teams at www. projectsmart.co.uk/five-steps-to-a-winning-project-team. php. Which of these five steps seem to be easier for a proj- ect manager to perform and which seem to be more dif- ficult? Why? How do the ideas in this chapter compare to the advice given in a related link on “five essentials to proj- ect team success” at www.projectsmart.co.uk/5-essentials- to-project-team-success.php? What does this suggest about the importance of setting the stage for project suc- cess through team development?

6.2 Go to the Web site of a professional sports team and ex- plore the site. What clues do you get regarding the impor- tance of “teams” and “teamwork” from this site? Give two or three specific examples.

6.3 Go to the Web site for a pharmaceutical company. Explore the site, particularly information on new research. What kinds of project teams are used within pharmaceutical companies? Can you identify at least five functional areas within these organizations that should work together in a project team in order to develop a new drug?

6.4 Go to www.ebxml.org/project_teams/project_teams.htm and explore the projects and project teams listed. Notice the size and diversity of some of these project teams. What challenges would you find in attempting to bring these individuals together into a project team? How does the fact that some of the teams are made up of personnel from different organizations affect our best attempts to mold a project team?

6.5 Go to http://tele-immersion.citris-uc.org/ and explore the nature of the project working to develop tele-immersion technology. Connect to the link marked “Projects” and observe the different fields and uses for tele- immersion technology. What are projected advances and uses for this science into the future?

PMP certificAtion sAMPle QUestions

1. The project manager is experiencing serious, deep- rooted conflict between two key project team members. It is apparent that these differences are based on differ- ent interpretations of the project’s scope. Which conflict resolution approach would be the most useful for the project manager to employ?

a. Compromising b. Withdrawal c. Punishment d. Problem solving

2. Which of the following is not an example of a team de- velopment strategy?

a. Creating a WBS for the project b. Performance reviews c. Project team outing to a sporting event d. Team lunches

3. Two programmers are involved in a conflict that is threat- ening to disrupt the development of the project. The proj- ect manager calls the two programmers into her office and

Internet exercises

reminds them that they are both “on the same side” in working to develop the software application for the com- pany. Her conflict resolution style would best be seen as:

a. Arbitration b. Defusion c. Controlling the conflict d. Eliminating the conflict

4. Carrie is from the marketing department and she has become increasingly upset with the attitude of the pro- duction member of the project team, Andrew. He seems to either ignore her opinions or make disparaging comments every time she speaks, usually referring to marketing in an unpleasant way. Which stage of group development is the project team addressing, as evi- denced by the interactions of Carrie and Andrew?

a. Norming b. Performing c. Storming d. Adjourning

5. Among the useful means to develop a sense of team- work in personnel from different functional depart- ments are all of the following EXCEPT:

a. Colocation (physical proximity) b. Common goals c. Organizational rules governing their interaction d. Flexible working hours

Answers: 1. d—Problem solving would be the best alternative when the issues are not so much personal as they are perceptu- al (based on interpretation of the project’s scope). Compromis- ing would be a problem because it could lead to watering down the deliverables; 2. a—The other activities can all result in team development; 3. b—Because the project  manager emphasizes commonalties and working together, this would be considered a method of conflict resolution through defusion; 4. c—They are clearly exhibiting behaviors that are associated with storm- ing; 5. d—Flexible working hours have no impact on the will- ingness of personnel to work cooperatively with members of other departments.

1. Patel, P. (2009, December 9). “Engineers without borders,” IEEE Spectrum. http://spectrum.ieee.org/geek-life/ profiles/engineers-without-borders

2. Verma, V. K. (1996). Human Resource Skills for the Project Manager. Upper Darby, PA: Project Management Institute; Verma, V. K. (1997). Managing the Project Team. Newtown Square, PA: Project Management Institute.

3. Hoegl, M., and Parboteeah, K. P. (2003). “Goal setting and team performance in innovative projects: On the moder- ating role of teamwork quality,” Small Group Research, 34: 3–19; McComb, S. A., and Green, S. G. (1999). “Project goals, team performance, and shared understanding,” Engineering Management Journal, 11(3).

4. Pinto, J. K., and Prescott, J. E. (1988). “Variations in critical success factors over the stages in the project life cycle,” Journal of Management, 14(1): 5–18.

5. Hartman, F. T. (2000). Don’t Park Your Brain Outside: A Practical Guide to Improving Shareholder Value Through SMART Management. Newtown Square, PA: Project Management Institute; Karlsen, J. T., Grae, K., and Massaoud, M. J. (2008). “The role of trust in project- stakeholder relationships: A study of a construction project,” International Journal of Project Organization and Management, 1: 105–118; Lander, M. C., Purvis, R. L., McCray, G. E., and Leigh, W. (2004). “Trust-building mechanisms utilized in outsourced IS development projects: A case study,” Information and Management, 41: 509–28; Kadefors, A. (2004). “Trust in project relation- ships—inside the black box,” International Journal of Project Management, 22: 175–82; Smyth, H. J., and Thompson, N. J. (2005). “Managing conditions of trust within a framework of trust,” Journal of Construction Procurement, 11(1): 4–18.

6. Hartman, F. T. (2002). “Update on trust: A collection of trust-based research findings,” in Slevin, D. P., Pinto, J. K., and Cleland, D. I. (Eds.), Proceedings of the PMI Research Conference 2002. Newtown Square, PA: Project Management Institute, pp. 247–53.

7. Gido, J., and Clements, J. P. (2003). Successful Project Management, 2nd ed. Mason, OH: South-Western.

8. Tuchman, B. W., and Jensen, M. A. (1977). “Stages in small group development revisited.” Group and Organizational Studies, 2: 419–27.

9. Tuchman, B. W., and Jensen, M. A. (1977), ibid. 10. Verma, V. K. (1997). Managing the Project Team, p. 71, as

cited in note 2. 11. Gersick, C. (1988). “Time and transition in work teams:

Toward a new model of group development.” Academy of Management Journal, 31: 9–41; Gersick, C. (1989). “Making time predictable transitions in task groups.” Academy of Management Journal, 32: 274–309.

12. Pinto, M. B. (1988). Cross-functional cooperation in the implementation of marketing decisions: The effects of superor- dinate goals, rules and procedures, and physical environment. Unpublished doctoral dissertation, University of Pittsburgh, PA; Pinto, M. B., Pinto, J. K., and Prescott, J. E. (1993). “Antecedents and consequences of project team cross func- tional cooperation,” Management Science, 39: 1281–97.

13. Sherif, M. (1958). “Superordinate goals in the reduction of intergroup conflict,” American Journal of Sociology, 63(4): 349–56.

14. Galbraith, J. R. (1977). Organization Design. Reading, MA: Addison-Wesley.

15. Davis, T. E. (1984). “The influence of the physical envi- ronment in offices,” Academy of Management Review, 9(2): 271–83.

16. Frame, J. D. (2002). The New Project Management, 2nd ed. San Francisco, CA: Jossey-Bass.

17. Tjosvold, D. (1993). Teamwork for Customers: Building Organizations That Take Pride in Serving. San Francisco, CA: Jossey-Bass; Logue, A. C. (2002). “Building and keep- ing the dream team,” PMNetwork, 16(3): 30–36.

18. Adams, J. R., and Adams, L. L. (1997). “The virtual projects: Management of tomorrow’s team today,” PMNetwork, 11(1): 37–41; Kostner, J. (1994). Knights of the Tele-Round

Notes

Notes 221

222 Chapter 6 • Project Team Building, Conflict, and Negotiation

Table. New York: Warner Books; Delisle, C. (2001). Success and communication in virtual project teams. Unpublished doctoral dissertation. Dept. of Civil Engineering, Project Management Specialization. University of Calgary, Calgary, Alberta; Fagerhaug, T. (2002). “Virtual project organizations—design of and challenges for,” in Slevin, D. P., Pinto, J. K., and Cleland, D. I. (Eds.), Proceedings of PMI Research Conference 2002. Newtown Square, PA: Project Management Institute, pp. 217–23.

19. Coutu, D. L. (1998). “Organization: Trust in virtual teams,” Harvard Business Review, 76(3): 20–21.

20. Smith, P. G., and Blank, E. L. (2002). “From experience: Leading dispersed teams,” Journal of Product Innovation Management, 19: 294–304.

21. Smith, P. G., and Blank, E. L. (2002), ibid. 22. Lanier, J. (2001, April). “Virtually there: Three dimen-

sional tele-immersion may eventually bring the world to your desk,” Scientific American, 284(4): 66–75.

23. Ditlea, S. (2001, January). “Tele-immersion: Tomorrow’s teleconferencing,” Computer Graphics World, www.cgw. com; (2008). tele-immersion.citris-uc.org/video

24. Posner, B. Z. (1986). “What’s all the fighting about? Conflicts in project management,” IEEE Transactions on Engineering Management, EM-33: 207–11; Thamhain, H. J., and Wilemon, D. L. (1975). “Conflict management in project life cycles,” Sloan Management Review, 16(3): 31–50; Thamhain, H. J., and Wilemon, D. L. (1977). “Leadership, conflict, and program management effectiveness,” Sloan Management Review, 19(1): 69–89; Chan, M. (1989). “Intergroup conflict and conflict management in the R&D divisions of four aerospace companies,” IEEE Transactions on Engineering Management, EM-36: 95–104; Adams, J. R., and Barndt, S. E. (1988). “Behavioral implications of the project life cycle,” in Cleland, D. I., and King, W. R. (Eds.),

Project Management Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp. 206–30.

25. Thomas, K. W., and Schmidt, W. H. (1976). “A survey of managerial interests with respect to conflict,” Academy of Management Journal, 10: 315–18.

26. Thomas, K. W. (1992). “Conflict and negotiation processes in organizations,” in Dunnette, M. D. (Ed.), Handbook of Industrial and Organizational Psychology, 2nd ed. Palo Alto, CA: Consulting Psychologists Press, pp. 889–935; Pondy, L. (1968). “Organizational conflict: Concepts and mod- els,” Administrative Science Quarterly, 12: 296–320.

27. Thamhain, H. J., and Wilemon, D. L. (1975), as cited in note 24.

28. Verma, V. K. (1998). “Conflict management,” in Pinto, J. K. (Ed.), The Project Management Institute’s Project Management Handbook. San Francisco, CA: Jossey-Bass.

29. Verma, V. K. (1996), as cited in note 2; Robbins, S. P. (1974). Managing Organizational Conflict: A Nontraditional Approach. Englewood Cliffs, NJ: Prentice-Hall.

30. Thamhain, H. J., and Wilemon, D. L. (1975), as cited in note 24; Posner, B. Z. (1986), as cited in note 24.

31. Verma, V. K. (1998), as cited in note 28. 32. Ware, J. (1983). “Some aspect of problem-solving and con-

flict resolution in management groups,” in Schlesinger, L. A., Eccles, R. G., and Gabarro, J. L. (Eds.), Managing Behavior in Organization: Text, Cases, Readings. New York: McGraw-Hill, pp. 101–15.

33. Slevin, D. P. (1989). The Whole Manager. New York: AMACOM.

34. Fisher, R., and Ury, W. (1981). Getting to Yes: Negotiating Agreement Without Giving In. New York: Houghton Mifflin.

35. Fisher, R., and Ury, W. (1981), ibid. 36. Fisher, R., and Ury, W. (1981), ibid. 37. Fisher, R., and Ury, W. (1981), ibid.

223

7 ■ ■ ■

Risk Management

Chapter Outline Project Profile

The Building that Melted Cars introduction Project Managers in Practice

Mathew Paul, General Electric Company 7.1 risk ManageMent: a four-stage

Process Risk Identification

Project Profile Bank of America Completely Misjudges

Its Customers Risk Breakdown Structures Analysis of Probability and Consequences Risk Mitigation Strategies Use of Contingency Reserves Other Mitigation Strategies Control and Documentation

Project Profile Collapse of Shanghai Apartment Building

7.2 Project risk ManageMent: an integrated aPProach

Summary Key Terms Solved Problem Discussion Questions Problems Case Study 7.1 Classic Case: de Havilland’s

Falling Comet Case Study 7.2 The Spanish Navy Pays Nearly $3

Billion for a Submarine That Will Sink Like a Stone Case Study 7.3 Classic Case: Tacoma Narrows

Suspension Bridge Internet Exercises PMP Certification Sample Questions Integrated Project—Project Risk Assessment Notes

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

1. Define project risk. 2. Recognize four key stages in project risk management and the steps necessary to manage risk. 3. Understand five primary causes of project risk and four major approaches to risk identification. 4. Recognize four primary risk mitigation strategies. 5. Explain the Project Risk Analysis and Management (PRAM) process.

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Plan Risk Management (PMBoK sec. 11.1) 2. Identify Risks (PMBoK sec. 11.2) 3. Perform Qualitative Risk Analysis (PMBoK sec. 11.3) 4. Perform Quantitative Risk Analysis (PMBoK sec. 11.4) 5. Plan Risk Responses (PMBoK sec. 11.5) 6. Control Risks (PMBoK sec. 11.6)

224 Chapter 7 • Risk Management

Project Profile

the Building that Melted cars

Driving a car in London just got a lot more dangerous. A soon-to-be-completed skyscraper in the downtown area is having an impact that no one could have imagined: It is starting fires and melting cars. The building—designed by in- ternationally renowned architect Rafael Viñoly—is a dramatic edifice with curved exterior walls. Built at 20 Fenchurch Street in London’s financial center, the 38-story skyscraper is known locally as “the Walkie-Talkie” for its unusual shape.

But that curvilinear shape is exactly what’s causing the problem: The south-facing exterior wall is covered in re- flective glass, and because it’s concave, it focuses the sun’s rays onto a small area, not unlike the way a magnifying glass directs sunbeams onto a superhot pinpoint of light.

“Fundamentally it’s reflection. If a building creates enough of a curve with a series of flat windows, which act like mirrors, the reflections all converge at one point, focusing and concentrating the light,” says Chris Shepherd, from the UK’s Institute of Physics. “It’s like starting a fire with a parabolic mirror.”

The beam caused by the curved skyscraper concentrating the sun’s rays was measured at more than 110 degrees Celsius (230 degrees Fahrenheit) in September. So far, the building has been responsible for partially destroying a parked Jaguar XJ luxury car, catching carpets on fire in nearby shops, and shattering slate tiles at local restaurants. This situation is likely to be a recurring problem for any structure built within range of the powerful reflected light coming from the building.

Because the effect is caused by the sun’s elevation in the sky at certain times of the day and during a specific time of the year, experts expect the intense light and dangerous heating effect will last about two hours a day over a period of three weeks. To help in the short term, the building’s owners have contracted with local authorities to block off a limited number of parking spaces that are right in the reflected beam’s path. Longer term solutions are more problem- atic; the design of the building will not change and of course, the sun’s path is not likely to alter in the near future!

This isn’t the first time Viñoly’s architecture has been the subject of similar controversy: His Vdara Hotel in Las Vegas has been criticized for directing sunbeams onto the swimming pool deck that are hot enough to melt plastic and singe people’s hair. The technical term for the phenomenon is a solar convergence, but the hotspot more popularly became known as the “Vdara death ray.” The Vdara resolved the “death ray” effect with larger sun umbrellas, but fixing the problem in London might take a lot more work. “There are examples in the past where an architect has had to rebuild the façade,” said Philip Oldfield, an expert in tall buildings at the University of Nottingham’s Department of Architecture. “If this is serious, then I dread to think how expensive it will be.”

Architectural critic Jonathan Glancey says the story is not unprecedented. In 2003, the opening of the Walt Disney Concert Hall in Los Angeles, designed by architect Frank Gehry, had a similar problem. “The building was clad from head to toe, right down to the pavement, in stainless steel panels, and they would send the sun dazzling across the

Figure 7.1 london’s Walkie-talkie Building

Source: Lionel Derimais/Corbis

Introduction 225

introduction

Projects operate in an environment composed of uncertainty. There is uncertainty regarding proj- ect funding, the availability of necessary resources, changing client expectations, potential techni- cal problems—the list is seemingly endless. This uncertainty forms the basis for project risk and the need to engage in risk management. risk management, which recognizes the capacity of any project to run into trouble, is defined as the art and science of identifying, analyzing, and respond- ing to risk factors throughout the life of a project and in the best interests of its objectives. The difference between projects that fail and those that are ultimately successful has nothing to do with the fact that one lacks problems the other has. The key lies in the plans that have been made to deal with problems once they arise. The Project Management Institute defines project risk as “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, or quality. A risk may have one or more causes and if it occurs, may have one or more impacts.” This definition is important because, unlike the past, when project risk was automatically assumed to lead to negative consequences, it is now recognized as the source of either opportunities or threats. As a result, whereas in the past leading project management researchers assumed that project risk was “an estimate of the probability of loss from a large population of unwanted circumstances,”2 risk in the modern sense argues that the uncertainty that exists in any project can result in either positive or negative outcomes. Project managers must acknowledge the possibility that the same risk event may bring several outcomes, of both a positive and detrimental effect on the project. Underlying these definitions is the recog- nition that many events, both within the organization and outside its control, can affect our best efforts to successfully complete projects.

Risk management consists of anticipating, at the beginning of the project, unexpected situa- tions that may arise that are beyond the project manager’s control. These situations have the capac- ity to severely undermine the success of a project. Broadly speaking, for the manager, the process of risk management includes asking the following questions:

• What is likely to happen (the probability and impact)? • What can be done to minimize the probability or impact of these events? • What cues will signal the need for such action (i.e., what clues should I actively look for)? • What are the likely outcomes of these problems and my anticipated reactions?

This chapter will explore the concept of project risk management in detail. We will address some of the principal sources of uncertainty, and hence risk, in projects. The chapter will also provide infor- mation on identifying the key steps to consider in formulating project risk management processes, methods for assessing risk impact, and processes for mitigating negative effects.

Project risk is based on a simple equation:

Event Risk = (Probability of Event) (Consequences of Event)

In other words, all risks must be evaluated in terms of two distinct elements: the likelihood that the event is going to occur as well as the consequences, or effect, of its occurrence. The risk of a project manager in your company being struck by lightning on the way to work would clearly constitute a high level of consequence to the project, but the probability of such an occurrence is sufficiently low to minimize your need to worry about it. On the other hand, people do change jobs, so an

sidewalks to hotspots where people were. It was measured up to 60C (140F). Local people living there complained they were having to crank their air conditioning up to maximum to cool things down,” he says. Blinding glare also affected drivers passing the building. After computer models and sensor equipment identified the panels causing the problem, they were sanded down to break up the sun’s rays.

In the case of the London Walkie-Talkie building, developers could employ a number of possible solutions. “They could coat the windows to reduce reflection—which would be a cheap fix—but the downside of that is it could reduce the light entering the building. Another solution would be for them to misalign the window frames, to slightly alter them by about a millimeter, but that would be very expensive,” Chris Shepherd noted.1

226 Chapter 7 • Risk Management

event such as the loss of a key project team member midway through the development phase may have both a potentially serious impact and a high degree of probability in some organizations. Hence, in those project environments, it would be appropriate to develop mitigation strategies to address this risk, given its high likelihood of occurring and the negative consequences it would engender. For example, the project manager could develop a bonus or other incentive program to reward personnel who remain on the project team as a useful response (risk mitigation) for the potential loss of key personnel during the project.

Risk and opportunity are mirror opposites of the same coin—opportunity emerges from favorable project uncertainties and negative consequences from unfavorable events. Figure 7.2 illustrates the dynamics of risk and opportunity over the project life cycle compared to the severity of negative consequences. Early in the life of a project, both risk and opportunity are high. The concept may be thought valuable, and the opportunities are strong, as are the nega- tive risks. This result is due to the basic uncertainty early in a project’s life cycle. Until we move forward into the development phases, many unanswered questions remain, adding to overall project uncertainty. On the other hand, the severity of negative consequences (the “amount at stake”) is minimal early in the project’s life. Few resources have yet been committed to the project, so the company’s exposure level is still quite low. As the project progresses and more budget money is committed, the overall potential for negative consequences ramps up dra- matically. At the same time, however, risk continues to diminish. The project takes on a more concrete form and many previously unanswered questions (“Will the technology work?” “Is the development time line feasible?”) are finding answers. The result is a circumstance in which overall opportunity and risk (defined by their uncertainty) are dropping just as the amount the company has at stake in the project is rising.

The periods of greatest worry shown in Figure 7.2 are the execute and finish stages, at which point uncertainty is still relatively high and the amount at stake is rapidly increasing. The goal of a risk management strategy is to minimize the company’s exposure to this unpleasant combination of uncertainty and potential for negative consequences.

Total Project Life Span

Time

Major Phase 1

Major Phase 2

Major Phase 3

Major Phase 4

Conceive (C)

Develop (D)

Execute (E)

Finish (F)

D o

ll a r

v a lu

e

In c re

a s in

g r

is k

PLAN PRODUCE

Period of highest

risk impact

Com bin

ed ris

k im

pa ct

Amount a t stake

Opportunity and risk

Figure 7.2 risk Versus Amount at Stake: the challenge in risk Management

Source: R. Max Wideman. (2004). A Management Framework for Project, Program and Portfolio Integration. Victoria, BC, Canada, 2004. Copyright © 2004 by R. Max Wideman, AEW Services Vancouver, BC, Canada: Trafford Publishing. Figure from page 64. Reproduced with permission of R. Max Wideman.

Introduction 227

Box 7.1

Project Managers in Practice

Mathew Paul, General Electric Company

Mathew Paul is the Program Leader for Liquefied Natural Gas (LNG) Locomotives at GE Transportation in Erie, PA. He is currently responsible for leading the introduction of GE’s natural gas locomotives for domestic markets from the Engineering function. Mathew completed his Bachelor’s in Mechanical Engineering from The University of Kerala, India, in 1998. After a short stint at Cochin Port Trust and Lucent Technologies in India, he decided to pursue his Master’s in Mechanical Engineering at The University of Alabama, Tuscaloosa. He also holds a Master’s in Business Administration from Fogelman’s College of Business at The University of Memphis, Tennessee. He is PMP certified and a Six Sigma Green Belt.

Mathew’s career started as an Engineer at Cummins working on new internal combustion engine intro- duction projects to meet customer requirements and environmental regulations. His specific job was to identify combustion recipes and meet engine performance requirements. However, during the recession of 2008, he was given the responsibility of leading cost reductions as well as identifying profitable projects for the business. Identifying components that either need to be avoided in the engine or redesigned to gain economies of scale was not an easy task due to the wide application and customer base. Project management methodologies had to be implemented to execute the tasks and show the benefits to customers. It was in meeting these challenges that Mathew learned the art of project management and decided to switch careers to project management.

In 2010, Mathew led the introduction of a low-cost Cummins fuel injection system in China for the trucking market to capture market share and reduce dependence on other firms’ products. It was the first of its kind for Cummins Fuel Systems and the team quickly realized that a different approach was required to be successful in China. His specific tasks included managing a project comprised of people from both China and the United States in designing, developing, testing, and manufacturing the fuel system. Due to the magni- tude of the project, project management methodologies were introduced for the first time at Cummins Fuel Systems. In his words, “The main challenge was to use the data-based approach in communicating with cus- tomers, suppliers, and team members as the Chinese culture is mostly customer-centric and saying ‘no’ was never appreciated. The profit margin per unit was very low and business was based on volume. Maintaining risks—both in quality and cost—was critical for the success of the project.”

After the successful implementation of the low-cost fuel system for Cummins, Mathew moved to GE Transportation to introduce PowerHaul™ locomotives in Australia and Korea. Paul recounts, “Even though the product was similar, the challenges were different—while meeting tight schedules was critical for Australia, maintaining customer relations and the highest quality were primary requirements for Korea.” Mathew was also tasked to lead GE Transportation’s first natural gas locomotive project for domestic markets. Due to the

Figure 7.3 An example of the Next-Generation Ge locomotives that Mathew Paul Supports

Source: Sean Gallup/Getty Images

(continued )

228 Chapter 7 • Risk Management

7.1 risk ManageMent: a Four-stage Process

Systematic risk management comprises four distinct steps:

• risk identification—the process of determining the specific risk factors that can reasonably be expected to affect your project.

• Analysis of probability and consequences—the potential impact of these risk factors, deter- mined by how likely they are to occur and the effect they would have on the project if they did occur.

• risk mitigation strategies—steps taken to minimize the potential impact of those risk factors deemed sufficiently threatening to the project.

• control and documentation—creating a knowledge base for future projects based on lessons learned.

risk identification

A useful method for developing a risk identification strategy begins by creating a classification scheme for likely risks. Remember that risk implies the potential for both positive and negative effects on the project. Risks commonly fall into one or more of the following classification clusters:3

• financial risk—Financial risk refers to the financial exposure a firm opens itself to when developing a project. If there is a large up-front capital investment required, as in the case of Boeing or Airbus Industries’ development of a new airframe, the company is voluntarily assuming a serious financial risk in the project. Construction companies building structures “on spec” provide another example. Without a contracted buyer prior to the construction, these companies agree to accept significant financial risk in the hopes of selling office space or the building itself after it is completed.

• technical risk—When new projects contain unique technical elements or unproven technol- ogy, they are being developed under significant technical risk. Naturally, there are degrees of such risk; in some cases, the technical risk is minimal (modifications to an already- developed product), whereas in other situations the technical risk may be substantial. For example, Goodrich Corporation developed a modification to its electronic hoist system, used for cable hoists in rescue helicopters. Because the company had already developed the technology and was increasing the power of the lift hoist only marginally, the technical risk was considered minimal. On the other hand, the Spanish ship-builder Navantia is currently wrestling with seri- ous performance problems in its newest generation of submarine, the S-80 class, because of the decision to include too many ground-breaking technical upgrades in one ship. The problems with the S-80 are so severe that the submarine itself is considered unsafe and not ready for sea trials (see Case Study 7.2 at the end of the chapter). The greater the level of technical risk, the greater the possibility of project underperformance in meeting specification requirements.

availability of shale gas in the United States, the move to natural gas as the predominant fuel for locomo- tives seemed a logical next step. However, being a new technology, the safety of personnel and environment was considered as the paramount criteria. “The project was huge as part of my job involved coordinating the work of 250 people from five different countries with an initial investment of over $70 million dollars. We constructed and followed risk analysis and risk mitigation plans that had to be constantly updated—pretty much every day—due to the nature of the project. The project was capital intensive and eagerly awaited by customers, government, and competitors.”

Mathew recollects that every project to date had been different and that makes it critical to follow a project management methodology for standard guidelines. He notes that planning is critical for the success of the project and executing the plan is essential; however, the key for any project manager is to have a “sixth” sense about potential risks and be able to respond to it at the earliest. Even with these challenges, the final outcome for any project manager is very fulfilling. “When the first natural gas locomotive was cranked and pulled the load at the desired speed, my eyes watered with joy. I got to experience several firsts in my life. When the first Cummins Tier 3 19L engine was rolled out of their Seymour engine plant, when the first fuel system rolled out of Cummins Wuhan plant, and when the first PowerHaul™ GE engine was unveiled at the customer property in Australia, to cite a few.” As Paul has found, that is the moment when years of hard work, volumes of documentation, and hours of meeting converge and only a project manager can envision the final product and strive towards attaining the same on a daily basis.

7.1 Risk Management: A Four-Stage Process 229

• commercial risk—For projects that have been developed for a definite commercial intent (profitability), a constant unknown is their degree of commercial success once they have been introduced into the marketplace. Commercial risk is an uncertainty that companies may will- ingly accept, given that it is virtually impossible to accurately predict customer acceptance of a new product or service venture.

• execution risk—What are the specific unknowns related to the execution of the project plan? For example, you may question whether geographical or physical conditions could play a role. For example, developing a power plant on the slopes of Mount Pinatubo (an active volcano) in the Philippines would involve serious execution risks! Likewise, poorly trained or insufficient project team personnel might constrain project execution. Execution risk is a broad category that seeks to assess any unique circumstances or uncertainties that could have a negative impact on execution of the plan.

• contractual or legal risk—This form of risk is often consistent with projects in which strict terms and conditions are drawn up in advance. Many forms of contracted terms (e.g., cost- plus terms, fixed cost, liquidated damages) result in a significant degree of project risk. Companies naturally seek to limit their legal exposure through legal protection, but it is sometimes impossible to pass along contractual risk to other parties. For example, most U.S. railroads will not accept penalty clauses for late deliveries of components because they have an almost monopolistic control of the market. Therefore, organizations utilizing rail transpor- tation must accept all delivery risk themselves.

After understanding the broad categories of risk, you want to anticipate some of the more common forms of risk in projects. The following list, though not inclusive, offers a short set of some of the more common types of risk to which most projects may be exposed:

• Absenteeism • Resignation • Staff being pulled away by management • Additional staff/skills not available • Training not as effective as desired • Initial specifications poor or incomplete • Work or change orders multiplying due to various problems • Enhancements taking longer than expected

Although the broad categories and common types of risk in the preceding lists are both good starting points, you also need to consider common industry-specific risks that run across different types of projects in the specific field in which you are working. A number of methods, both quali- tative and quantitative, are available for conducting risk factor identification for industry-specific risks, including:

• Brainstorming meetings—Bringing the members of the project team, top management, and even clients together for a brainstorming meeting can generate a good list of potential risk factors. Brainstorming is a qualitative idea-creation technique, not one focused on decision making. In order to be effective, brainstorming meetings must be free of judgments, criticism of others’ viewpoints, and pressure to conform. A mini-scenario of risk management is at work. Think about it: Would you be willing to place your most creative ideas on the table in front of 10 other people if you were at risk of being immediately critiqued? Or might you be tempted to hold an idea for later if your boss required that you present it in a fully developed way? In short, the brainstorming environment needs to be made safe for the risk-averse.

• Expert opinion—This technique can be used in two alternative ways in assessing project risks. The more quantifiable method, commonly referred to as the Delphi approach, collects and consolidates the judgments of isolated anonymous respondents. For Delphi to be used effec- tively, some preliminary screening of potential contributors is usually necessary. The collec- tive “wisdom” of the set of experts is then used as the basis for decision making. The simpler, more intuitive method for using expert judgments is based on the principle that “experience counts.” You simply identify and consult people within the organization who have had simi- lar experiences in running projects in the past or who have been with the firm long enough to have a clear grasp of the mechanics of project risk analysis. As obvious as this may seem, this opportunity may not be clear to everyone, particularly if management shifts recently have taken place in a firm or if new employees are not aware of the firm’s project history.

230 Chapter 7 • Risk Management

• History—In many cases the best source of information on future risks is history. Has a firm encountered a consistent pattern of problems while pursuing projects over time? What “storm signals,” or events that have preceded past problems, have been detected? Experience can be used to identify not only risk factors but their leading indicators as well. The problem with experience is that it is no guarantee of future events. The issues or conditions that con- tributed to project risk in the past decade, year, or even month may not be relevant to current market conditions or the state of project work as it is now being conducted. Hence, history can be useful for identifying key project risk factors provided all parties employ a reason- able degree of caution when evaluating current projects through the portal of past events. Rauma Corporation of Finland, for example, developed state-of-the-art logging equipment that worked well in locations with good infrastructure to allow for frequent servicing. When it attempted to use the equipment in remote rain forest regions of Indonesia, however, the company found it had not anticipated the problems involved in routine servicing, includ- ing having to fly the machinery hundreds of miles out of the forests to servicing centers. Experience had not prepared the company for new risks.

• Multiple (or team-based) assessments—Using single-case sources to identify project risks is itself a risky proposition because of the potential bias in any one person’s viewpoint.4 It makes sense that no one individual, regardless of her perceived degree of expertise, can possibly discern all sources of threat and project risk. Although an engineer is likely to be more attuned to technical risks, a cost accountant to budgetary risks, and so forth, not even the most seasoned manager with experience in many fields is all-knowing. A team-based approach to risk factor identification encourages identification of a more comprehensive set of potential project risks. At the same time, a collaborative approach can help persuade the half-convinced or uncommitted members of the team to support project goals.5

Project Profile

Bank of America completely Misjudges its customers

When Bank of America (BofA) decided it would begin to charge customers $5 per month in 2012 just to gain access to their funds via their debit cards, it was unprepared for a response that was far more hostile than it could have imagined. After announcing the new fee in late September 2011, the giant bank anticipated some negative reaction from its customers but thought that after an initial angry response, most would fall in line and grudgingly accept the fee. Perhaps BofA felt secure due to the initial decision by some of its largest competitors, including Wells Fargo, SunTrust, and JPMorgan Chase, to mirror the fees. If BofA thought “might made right,” it was in for a giant surprise.

The announcement of a pending new charge just to allow customers to use their debit cards led to massive consumer anger directed at the bank and a pledge that the new fees would not be accepted. These informal protests were galvanized and given a degree of organization by the creation of several viral Internet and Facebook sites to support two major dates in November 2011: “Bank Transfer Day” (November 5) and “Dump your Bank Day” (November 8). Wells Fargo, SunTrust, and JPMorgan Chase banks all dropped their fee-charging plan in the face of these gathering protests, leaving BofA standing alone and continuing to assert its intention of charg- ing the debit card fee. By October 2011, a poll by TheStreet showed a whopping 83% of BofA customers said they would indeed take the time out of their busy schedules and dump BofA. Contributing to the poor timing of the BofA announcement was the continuation of the “Occupy Wall Street” protests against financial institutions. Seen in this light, the timing of BofA’s decision could not have been worse.

Belatedly realizing its mistake, BofA announced on November 1, 2011, that it was cancelling the $5 debit card fee. Although it is uncertain how many customers BofA lost as a result of this misguided decision, there is no doubt that it sacrificed a huge amount of customer goodwill. In a recession, when Americans were carefully watching their spending, BofA’s decisions made no sense. Charging $5 to be allowed to use your own money angered too many and the announce- ment to drop the charge came too late, causing people to bail on BofA.6

7.1 Risk Management: A Four-Stage Process 231

risk Breakdown structures

In identifying and categorizing various project risks, one useful tool is the risk Breakdown structure (RBS). An RBS is defined as “a source-oriented grouping of project risks that organizes and defines the total risk exposure of the project.”7 Remember in Chapter 5 that we developed the Work Breakdown Structure (WBS) as a means to hierarchically organize and define the various elements of the project scope by breaking up the deliverables into increasingly distinct elements, known as work packages. An RBS employs a similar approach; however, in this case, our goal is to create a hierarchical representation of the project’s risks, starting at the higher, general level and breaking the risks down to more specific risks at lower levels. For example, at the highest level, you have both external and internal risks. Specifying more closely, you may identify “Market risks,” “Technical risks,” “Environmental Impact risks,” and “Quality risks” as second level categories. From this first level, your project team breaks out the specific types of risk associated with each of these broader concepts. Figure 7.4 gives an example of an RBS for this hypothetical project. Moving down to more specific risks, we can further classify “Market Risks” as consisting of customer acceptance and profit potential. Likewise, for “Environmental Impact,” we have identified two specific risks: pollution risks and community protest potential. A similar de-classification can be conducted across each broader category of project risk. You can see that the advantage of the RBS is that it provides the project team with a visual representation of the critical risks for their project, as well as highlighting the specific components of these risks. This identification method helps with the next step in project risk management: the analysis of probability and consequences associated with each risk.8

analysis of Probability and consequences

The next step in the process consists of trying to attach a reasonable estimate of the likelihood of each of these risk events occurring. We can construct a risk impact matrix similar to the one shown in Figure 7.5.9 The matrix reflects all identified project risks, each prioritized according to the probability of its occurrence, along with the potential consequences for the project, the project

External

Internal

Performance

Level 1 Level 2 Level 3

Market

Environmental Impact

Technical

Organizational

Profit Potential

Customer Acceptance

Community Protests

Pollution Risk

Skilled Resources

Funding Safety

Figure 7.4 risk Breakdown Structure (rBS)

Once the process of risk factor analysis is complete and the variety of circumstances or sources of risk have been uncovered, an assessment of potential risk impact can be undertaken.

232 Chapter 7 • Risk Management

team, or the sponsoring organization should the worst come to pass. Probability combined with consequences provides a sense of overall risk impact. With such a prioritization scheme, the project team is better able to focus their attention where their energy can do the most good.

Figure 7.6 shows a risk impact matrix in use by several Fortune 500 companies. Note that instead of a high-low classification, this alternative one features three levels: high, medium, and low. This matrix is further refined by classifying risk impact as either serious, moderate, or minor. The fundamental reason for employing this more complete matrix is to develop a sense of priority in addressing the various risks.

After a project team has worked through and completed a detailed matrix, it is better equipped to recognize the sorts of risks to which the project is subject and the “criticality” of each of those risks in terms of their potential impact on project performance. Clearly, the types of risks that are most relevant to project planning are those that the team classifies as having both high likelihood of occurring (probability) and high potential for harming the project (impact). Risks that fall into this category require detailed contingency planning in order to adequately protect the project’s devel- opment cycle. Figure 7.6 shows how projects might be classified on the basis of their potential risk impact. The team first identifies the risk factors and then evaluates their impact using the matrix. You can see how the high-low-moderate classification scheme plays out in this example.

It is also useful to revisit our earlier point about the potential opportunities that may emerge from the uncertainty of project risk. That is, when analyzing the probability and consequences of risk events, we should include, as part of our calculation, the ways in which these uncertainties can

Consequences

Low Medium High

D

B

C A

L ik

e li

h o

o d

H ig

h L

o w

M e d

iu m

Figure 7.6 classifying Project risks

Consequences

Low High

L ik

e li

h o

o d

H ig

h L

o w

Figure 7.5 risk impact Matrix

7.1 Risk Management: A Four-Stage Process 233

open up opportunities for the organization. For example, if our project team identifies several project risks (market, technical, political, etc.), brainstorming sessions can help us determine if these risks are distinctly negative or if they open up the possibility of finding innovative, win-win solutions by transforming them into opportunities. For example, a firm may have concern about the risk from possible governmental regulations regarding reducing greenhouse gases to slow man-made climate change. These concerns can lead a firm to adopt one of two actions: (1) defensive— employing lob- byists to try and derail the legislation to maintain business as usual, or (2) opportunistic— getting out ahead of the regulations by challenging business units to start employing nontraditional, sus- tainable solutions to technical challenges, leading to new products or processes that they can market to other firms facing similar challenges. As a result, part of our analysis of risk probability conse- quences should always take into consideration both negative and positive consequences.

Table 7.1 illustrates this quantitative method using the example of a firm developing a new software product for the retail market. The scenario considers both probability of failure and con- sequences of failure. In probability of failure, we are interested in identifying any factors that can significantly affect the probability that the new prject can be successfully completed. Think of this category as requiring us to focus on the potential causes of failure. For the example in this section, let us assume that the issues identified as potential contributors are (1) maturity of the soft- ware design—is it a new product or based on an existing software platform? (2) complexity of the

taBle 7.1 Determining likely risks and consequences

Probability of failure (Pf)

Score Maturity complexity Dependency

Low (0.1) Existing software Simple design Not limited to existing system or clients. No external or uncontrollable events are likely to have an impact on the project.

Minor (0.3) Minor redesign Minor increase in complexity

Schedule or performance depends on an existing system. Effect on cost or schedule is minor.

Moderate (0.5) Major change Moderate increase Moderate risk to schedule or performance due to dependence on existing system, facility, or processes. Effect on cost is moderate.

Significant (0.7) Technology is available, but complex design

Significant increase Schedule or performance depends on new system or process. Significant cost or schedule risk.

Major (0.9) State of art, some research complete

Extremely complex Schedule and performance depend on new system and process. Very high cost or schedule risk.

consequence of failure (Cf)

Score cost Schedule reliability Performance

Low (0.1) Budget estimate not exceeded

Negligible impact on program, no impact on critical path

Minimal or no reliability consequence

Minimal or no performance consequence.

Minor (0.3) Cost estimate exceeds budget by < 5%

Minor slip in schedule (less than 5%)

Small reduction in reliability

Small reduction in system performance.

Moderate (0.5) Cost estimate exceeds budget by < 15%

Small slip in schedule starting to impact critical path

Some reduction in reliability

Some reduction in system performance. May require moderate debugging.

Significant (0.7) Cost estimate exceeds budget by < 30%

Development time slips in excess of 1 month, requires readjustment of critical path

Significant degradation in reliability

Significant degradation in system performance. Guarantees are at risk. Serious debugging required.

Major (0.9) Cost estimate exceeds budget by > 50%

Large schedule slips ensure the system will miss client time frame

Reliability goals cannot be achieved under current plan

Performance goals cannot be achieved. Results may not be usable.

234 Chapter 7 • Risk Management

product—is the design relatively simple or is it highly complex in structure? and (3) dependency— can the product be developed independently of any system currently in place in the company or is it tied to current operating systems or practices? A number of factors can have an impact on the probability of a new project’s successful completion. Although our example identifies three (matu- rity, complexity, and dependency), depending upon the project, a team may identify many unique issues or factors that will increase the probability of failure.

Under the dimension of consequences of failure, we are concerned with the issues that will highlight the effects of project failure. The consequences of failure require us to critically evaluate the results of a project’s success or failure along a number of key dimensions. For this example, the organization has identified four elements that must be considered as critical effects of project failure: (1) cost—budget adherence versus overruns, (2) schedule—on time versus severe delays, (3) reliability—the usefulness and quality of the finished product, and (4) performance—how well the new software performs its designed functions. As with items shown under probability of fail- ure, the set of issues related to the consequences of failure that should be clearly identified will be unique to each project.

Table 7.2 demonstrates the process of creating a project risk score. The scores for each indi- vidual dimension of probability and consequence are added and the sum is divided by the num- ber of factors used to assess them. For example, under probability of failure, the scores of the three assessed elements (maturity, complexity, and dependency) are totaled to derive an overall score, and that number is divided by 3 to arrive at the probability score. This table shows the overall risk factor formula for the sample project, based on the quantitative assessment. A common rule of thumb assigns any project scoring below .30 as “low risk,” projects scoring between .30 and .70 as “medium risk,” and projects scoring over .70 as “high risk.”

risk Mitigation strategies

The next stage in risk management is the development of effective risk mitigation strategies. In a general sense, there are four possible alternatives a project organization can adopt in deciding how to address risks: (1) accept risk, (2) minimize risk, (3) share risk, or (4) transfer risk.

accePt risk One option that a project team must always consider is whether the risk is suffi- ciently strong that any action is warranted. Any number of risks of a relatively minor nature may be present in a project as a matter of course. However, because the likelihood of their occurrence is so small or the consequences of their impact are so minor, they may be judged acceptable and ignored. In this case, the decision to “do nothing” is a reasoned calculation, not the result of inat- tention or incompetence. Likewise, for many types of projects, certain risks are simply part of the equation and must be factored in. For example, it has been estimated that the U.S. recording

taBle 7.2 calculating a Project risk factor

1. Use the project team’s consensus to determine the scores for each Probability of Failure category: Maturity (Pm), Complexity (Pc), Dependency (Pd).

2. Calculate Pf by adding the three categories and dividing by 3:

Pf = (Pm + Pc + Pd)>3 3. Use the project team’s consensus to determine the scores for each Consequence of Failure category:

Cost (Cc), Schedule (Cs), Reliability (Cr), Performance (Cp). 4. Calculate Cf by adding the four categories and dividing by 4:

Cf = (Cc + Cs + Cr + Cp)>4 5. Calculate Overall Risk Factor for the project by using the formula:

RF = Pf + Cf - (Pf)(Cf) rule of thumb:

Low risk RF 6 .30 Medium risk RF = .30 to .70

High risk RF 7 .70

7.1 Risk Management: A Four-Stage Process 235

industry spends millions every year in developing, producing, and promoting new recording art- ists, knowing full well that of the thousands of albums produced every year, less than 5% are profitable.10 Likewise, Chapter 3 detailed the extraordinary lengths that pharmaceutical manu- facturers must go to and the high percentage of failures they accept in order to get a small per- centage of commercially successful drugs to the marketplace. Hence, a high degree of commercial risk is embedded in the systems themselves and must be accepted in order to operate in certain industries.

MiniMize risk Strategies to minimize risk are the next option. Consider the challenges that Boeing Corporation faces in developing new airframes, such as the newly introduced 787 model. Each aircraft contains millions of individual parts, most of which must be acquired from ven- dors. Further, Boeing has been experimenting with the use of composite materials, instead of aluminum, throughout the airframe. The risks to Boeing in the event of faulty parts leading to a catastrophic failure are huge. For example, several early flights were plagued by meltdowns in the aircraft’s lithium ion batteries, manufactured in Japan by GS Yuasa. Consequently, the process of selecting and ensuring quality performance from vendors is a challenge that Boeing takes extremely seriously. One method Boeing employs for minimizing risk in vendor quality is to insist that all significant vendors maintain continuous direct contact with Boeing quality assessment teams. Also, in considering a new potential vendor, Boeing insists upon the right to intervene in the vendor ’s production process in order to ensure that the resulting quality of all supplier parts meets its exacting standards. Because Boeing cannot produce all the myriad parts needed to fabricate an aircraft, it seeks to minimize the resultant risk by adopting strategies that allow it to directly affect the production processes of its suppliers.

share risk Risk may be allocated proportionately among multiple members of the project. Two examples of risk sharing include the research and development done through the European Space Agency (ESA) and the Airbus consortium. Due to tremendous barriers to entry, no one country in the European Union has the capital resources and technical skills to undertake the development of the Ariane rocket for satellite delivery or the creation of a new airframe to compete with Boeing in the commercial aircraft industry. ESA and Airbus partners from a number of countries have jointly pooled their resources and, at the same time, agreed to jointly share the risk inherent in these ventures.

In addition to partnerships that pool project risk, ameliorating risk through sharing can be achieved contractually. Many project organizations create relationships with suppliers and cus- tomers that include legal requirements for risk to be shared among those involved in the project. Host countries of large industrial construction projects, such as petrochemical or power generation facilities, have begun insisting on contracts that enforce a “Build-Own-Operate-Transfer” provision for all project firms. The lead project organization is expected to build the plant and take initial ownership of it until its operating capacity has been proven and all debugging occurs before finally transferring ownership to the client. In this way, the project firm and the host country agree to jointly accept financial (risk) ownership of the project until such time as the project has been completed and its capabilities proven.

transFer risk In some circumstances, when it is impossible to change the nature of the risk, either through elimination or minimization, it may be possible to shift the risks bound up in a project to another party. This option, transferring risk to other parties when feasible, acknowledges that even in the cases where a risk cannot be reduced, it may not have to be accepted by the project organization, provided that there is a reasonable means for passing the risk along. Companies use several methods to transfer risks, depending upon their power relative to the client organizations and the types of risks they face. For example, if our goal is to prevent excessive budget overruns, a good method for directly transferring risk lies in developing fixed-price contracts. fixed-price contracts establish a firm, fixed price for the project upfront; should the project’s budget begin to slip, the project organization must bear the full cost of these overruns. Alternatively, if our goal is to ensure project functionality (quality and performance), the concept of liquidated damages offers a way to transfer risk through contracts. liquidated damages represent project penalty clauses that kick in at mutually agreed-on points in the project’s development and implementation. A project organization installing a new information system in a large utility may, for example, agree to a

236 Chapter 7 • Risk Management

liquidated damages clause should the system be inoperable after a certain date. Finally, insurance is a common option for some organizations, particularly in the construction industry. Used as a risk mitigation tool, insurance transfers the financial obligation to an insuring agency.

use of contingency reserves

contingency reserves in several forms, including financial and managerial, are among the most common methods to mitigate project risks. They are defined as the specific provision for unfore- seen elements of cost within the defined project scope. Contingency reserves are viewed differ- ently, however, depending upon the type of project undertaken and the organization that initiates it. In construction projects, it is common to set aside anywhere between 10% and 15% of the con- struction price in a contingency fund. A contract to construct a $5 million building will actually be built to the cost of approximately $4.5 million, with the balance retained for contingency. In other fields, however, project teams are much more reluctant to admit to the up-front need for establish- ing contingency reserves, fearing that customers or other project stakeholders will view this as a sign of poor planning or inadequate scope definition (see Chapter 5).

The best way to offset concerns about the use of contingency reserves is to offer documenta- tion of past risk events—unforeseen or uncontrollable circumstances that required the need for such contingency planning. Some of the concerns that might be generated may also be offset if the project team has done its homework and demonstrated in a detailed plan how contingency funds will be released as they are needed. Since the goal of creating contingency funds is to ensure against unforeseen risks, the key to their effective use lies in proactive planning to establish reason- able triggers for their release.11

task contingency Perhaps the most common form of contingency reserve is task contingency, which is used to offset budget cutbacks, schedule overruns, or other unforeseen circumstances accruing to individual tasks or project work packages. These budget reserves can be a valuable form of risk management because they provide the project team with a buttress in the face of task completion difficulties. It may be found, for example, that some components or work packages of the project are highly unique or innovative, suggesting that development estimates and their related costs cannot be estimated with anything less than a bound of {20% or even greater. Hence, task contingency becomes extremely important as a method for offsetting the project team’s inabil- ity to make an accurate budget estimate.

exaMPle 7.1 Calculating Contingency Expected Cost

Suppose a project task is estimated to cost $10,000 to complete, but it is viewed as a high-risk operation. A task contingency multiplier would require our budget to reflect the following:

(Task estimated cost)(Task contingency multiplier) = Expected cost 1+10,0002 11.22 = +12,000

Naturally, as the project moves forward, it may be possible to reduce budget reserve requirements for task contingency because the project’s scope will have been made clearer and its development will have progressed; that is, many of the tasks for which the contingency fund was established will have been completed. As a result, it is quite common for project organizations to assign a bud- get reserve to a project that is diminished across the project’s development cycle.

Managerial contingency While task contingency may involve the risk associated with the development of individual work packages or even tasks, managerial contingency is an additional safety buffer applied at the project level. Managerial contingency is budget safety measures that address higher-level risks. For example, suppose a project team has begun development of a new wireless communication device set to operate within guidelines established for technical perfor- mance. At some point in the midst of the development process, the primary client requests major

7.1 Risk Management: A Four-Stage Process 237

scope changes that will dramatically alter the nature of the technology to be employed. Managerial contingency typically is used as a reserve against just such a problem. Another way managerial contingency may be used is to offset potentially disastrous “acts of God,” which are natural disas- ters that, by definition, are unforeseeable and highly disruptive.

One final point about budget reserves at either the task or managerial level: It is extremely important that open channels of communication be maintained between top management and the project manager regarding the availability and use of contingency reserve funds. Project managers must be fully aware of the guidelines for requesting additional funding and how extra project budget is to be disbursed. If either the project manager or top management group uses contingency reserves as a political tool or method for maintaining control, the other party will quickly develop an attitude of gamesmanship toward acquiring those reserves. In this case, the atmosphere and communications between these key stakeholders will become characterized by distrust and secrecy—two factors guaranteed to ensure that a project is likely to fail.

insurance insurance can be a useful means for risk mitigation, particularly in certain types of projects, such as construction. Risks in construction go beyond technical risks or monetary/ commercial risks to include health and safety concerns. Not all organizations or countries enforce the same rules regarding occupational health and safety standards. For example, there are countries in the developing world that do not require (or enforce) the use of safety har- nesses for workers on skyscrapers, even though a fall would be fatal. Contractors acquire insur- ance as a means to offset the risks from the project that are often covered under contractual terms. For example, a construction contractor will routinely acquire insurance against loss or theft of building materials, workers’ compensation, and professional or general liability. One of the duties of project managers in these settings is to ensure that all certificates of compliance are up to date; that is, all necessary insurance has been acquired and is valid for the life of the project to mitigate against potential risks.

other Mitigation strategies

In addition to the set of mitigation strategies already discussed, many organizations adopt practi- cal approaches to minimizing risk through creating systems for effectively training all members of their project teams. One successful method for dealing with project risks involves mentoring new project managers and team members. In a mentoring program, junior or inexperienced project personnel are paired with senior managers in order to help them learn best practices. The goal of mentoring is to help ease new project personnel into their duties by giving them a formal con- tact who can help clarify problems, suggest solutions, and monitor them as they develop project skills. Another method for mitigating risks involves cross-training project team personnel so that they are capable of filling in for each other in the case of unforeseen circumstances. Cross-training requires that members of the project team learn not only their own duties but also the roles that other team members are expected to perform. Thus, in the case where a team member may be pulled from the project team for an extended period, other team members can take up the slack, thereby minimizing the time lost to the project’s schedule.

control and documentation

Once project risk analysis has been completed, it is important to begin developing a report- ing and documentation system for cataloging and future reference. Control and documentation methods help managers classify and codify the various risks the firm faces, its responses to these risks, and the outcome of its response strategies. Table 7.3 gives an example of a simpli- fied version of the risk management report form that is used in several organizations. Managers may keep a hard-copy file of all these analyses or convert the analyses to databases for better accessibility.

Having a repository of past risk analysis transactions is invaluable, particularly to novice project managers who may recognize the need to perform risk management duties but are not sure of the best way to do them or where to begin. The U.S. Army, for example, has invested sig- nificant budget and time in creating a comprehensive database of project risk factors and their mitigation strategies as part of project management training for their officers. Newly appointed

238 Chapter 7 • Risk Management

officers to Army procurement and project management offices are required to access this informa- tion in order to begin establishing preliminary risk management strategies prior to initiating new programs. Figure 7.7 illustrates a contingency document for adjustments to the project plan.

Establishing change management as part of risk mitigation strategies also requires a useful documentation system that all partners in the project can access. Any strategy aimed at minimizing

taBle 7.3 Sample risk Management report form

Customer: __________________________________________ Project Name: _______________________________

Budget Number: _____________________________________ Project Team: _______________________________

Date of Most Recent Evaluation: _____________________________________________________________________

Risk Description: _____________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

Risk Assessment: _____________________________________ Risk Factor: __________________________________

Discussion: _______________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

Risk Reduction Plan: _________________________________ Owner: _______________________________________

__________________________________________________________________________________________________

Time Frame to Next Assessment: ___________________________________________________________________

Expected Outcome: _______________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

Probable Event

Adjustment to Plans

Absenteeism

Resignation

Pull-aways

Unavailable staff/skills

Spec change

Added work

Need more training

Vendors late

Figure 7.7 contingency Document for Adjustments to Project Plan

7.1 Risk Management: A Four-Stage Process 239

a project risk factor, along with the member of the project team responsible for any action, must be clearly identified. The sample risk management report form shown in Table 7.3 includes the important elements in such change management. In order to be effective, the report must offer a comprehensive analysis of the problem, the plan for its minimization, a target date, and the expected outcome once the mitigation strategy has been implemented. In short, as a useful control document, a report form has to coherently identify the key information: what, who, when, why, and how.

• What—Identify clearly the source of risk that has been uncovered. • Who—Assign a project team member direct responsibility for following this issue and main-

taining ownership regarding its resolution. • When—Establish a clear time frame, including milestones if necessary, that will determine

when the expected mitigation is to occur. If it is impossible to identify a completion date in advance, then identify reasonable process goals en route to the final risk reduction point.

• Why—Pinpoint the most likely reasons for the risk; that is, identify its cause to ensure that efforts toward its minimization will correspond appropriately with the reason the risk emerged.

• How—Create a detailed plan for how the risk is to be abated. What steps has the project team member charted as a method for closing this particular project “risk window”? Do they seem reasonable or far-fetched? Too expensive in terms of money or time? The particular strategy for risk abatement should, preferably, be developed as a collaborative effort among team members, including those with technical and administrative expertise to ensure that the steps taken to solve the problem are technically logical and managerially possible.

Documentation of risk analysis such as is shown in Table 7.3 and Figure 7.7 represents a key final component in the overall risk management process.

Project Profile

collapse of Shanghai Apartment Building

The science and engineering principles surrounding the construction of simple apartment blocks are well known and have been practiced for centuries. And yet, even in the most basic of construction projects, events can sometimes tran- spire to produce shocking results. Just such a story occurred in late June of 2009 in China, when a Shanghai high-rise, 13-story apartment building literally toppled onto its side. The nearly completed structure was part of an 11-building apartment complex in a new development known as “Lotus Riverside.” Because the 629-unit apartment building was not yet completed, it was virtually empty. Although one worker was killed in the accident, the tragedy could have been far worse had the building been fully occupied.

Figure 7.8 Shanghai Apartment Building collapse

Source: Imago stock&people/Newscom

(continued)

240 Chapter 7 • Risk Management

Foundation

Removed dirt

Underground garage

Concrete pilings

5 m

10 m

Figure 7.9 Schematic of causes of collapse

The demand for affordable housing in Chinese cities has never been greater. With the economy humming along and a high demand for workers in economic regions such as Shanghai, there is a critical shortage of available housing. Private and governmental organizations are working to rapidly install new apartment blocks to keep up with this huge demand. Unfortunately, one of the risks with rapid building is the temptation to cut corners or use slipshod methods. When speed is paramount, the obvious concern is whether acceptable standards of building are being maintained.

In the Lotus Riverside building project, unfortunately, the construction firm opted for a procedure that is gener- ally frowned upon (indeed, the method is outlawed in Hong Kong due to its inherent riskiness). Under this system, rather than pour a deep concrete base on which to rest the structure, a series of prestressed, precast concrete pilings were used as a set of anchors to “pin” the building into the ground. Although this system can work effectively with shorter buildings, it has long been considered unsafe for larger, higher structures.

The problem was made critical when the construction crews began digging an underground garage on the south side of the building to a depth of nearly 5 meters. The excavated dirt was piled on the north side of the building to a height of 10 meters. The underground pilings began receiving severe lateral pressure from the excavation, which was further compromised by heavy rainstorms. The storms undermined the apartment building on the south side, causing more soil erosion and putting even greater lateral pressure (estimated at 3,000 tons) on the anchor piling system (see Figure 7.9). Suddenly, the pilings began snapping and the building toppled over on its side. Local officials noted that the only lucky result of the collapse was that the building fell into an empty space. Considering that all the buildings in the complex had been constructed in a similar manner, there was a very real possibility of creating a chain reaction of toppling buildings, much like a set of dominos falling over.

The Chinese government immediately began to aggressively trace the cause of the collapse, question- ing the private contractor’s use of unskilled workers, questionable construction practices, and overall quality control. China’s official news agency, Xinhua, said officials were taking “appropriate control measures” against nine people, including the developer, construction contractor, and supervisor of the project, after it was reported that the company’s construction license had expired in 2004. Although it is certain that penalties will be imposed for the building failure, a less certain future awaits the tenants of the other buildings in the complex. After all, what more visible evidence could there be of the unsoundness of the construction in the complex than seeing a “sister building” lying on its side not far from the other structures? Hundreds of prospective tenants have besieged government offices, demanding refunds for apartments in the same complex that they purchased for upward of $60,000 but are now too frightened to live in.

Meanwhile, China Daily, the state-run newspaper, published an angry editorial blaming the collapse on the often corrupt relationship between Chinese property developers and local government officials who depend on property taxes and land sales for a significant proportion of their income. The paper raised fears—expressed by some construction industry insiders in China—that many buildings designed to have a 70-year life span “would not stand firm beyond 30 to 40 years” because of corner-cutting during China’s rampant construction boom. “It is ironic that such an accident happened in Shanghai—one of the most advanced and international Chinese cities,” the paper concluded. “The sheer fact that such a collapse occurred in the country’s biggest metropolis should serve as warning to all developers and the authorities to ensure that construction projects do not cut corners and endanger people’s lives.”12

7.2 Project Risk Management: An Integrated Approach 241

7.2 Project risk ManageMent: an integrated aPProach

The European Association for Project Management has developed an integrated program of risk management, based on efforts to extend risk management to cover a project’s entire life cycle. This program, known as Project risk Analysis and Management (PrAM), presents a generic methodology that can be applied to multiple project environments and encompasses the key components of project risk management.13 The ultimate benefit of models such as PRAM is that they present a systematic alternative to ad hoc approaches to risk assessment, and hence can help organizations that may not have a clearly developed, comprehen- sive process for risk management and are instead locked into one or two aspects (e.g., risk identification or analysis of probability and consequences). The PRAM model offers a step- by-step approach to creating a comprehensive and logically sequenced method for analyzing and addressing project risk.

Among the key features of the PRAM methodology are the following:

• The recognition that risk management follows its own life cycle, much as a project follows a life cycle. Risk management is integrated throughout the project’s entire life cycle.

• The application of different risk management strategies at various points in the project life cycle. The PRAM approach tailors different strategies for different project life cycle stages.

• The integration of multiple approaches to risk management into a coherent, synthesized approach. PRAM recommends that all relevant risk management tools be applied as they are needed, rather than in a “pick-and-choose” approach.

Each of the nine phases in the PRAM approach is based on a specific purpose and requires the completion of a comprehensive set of targets (deliverables). Completing PRAM gives the project team a template for getting the most out of risk management and helps them sharpen their efforts in the most productive manner. It also creates a document for merging risk management with overall project planning, linking them in a collaborative sense.

The nine phases of a comprehensive project risk assessment include the following steps:

1. Define—Make sure the project is well defined, including all deliverables, statement of work, and project scope.

2. Focus—Begin to plan the risk management process as a project in its own right, as well as determining the best methods for addressing project risk, given the unique nature of the proj- ect being undertaken.

3. Identify—Assess the specific sources of risk at the outset of the project, including the need to fashion appropriate responses. This step requires that we first search for all sources of risk and their responses and then classify these risks in some manner to prioritize or orga- nize them.

4. Structure—Review and refine the manner in which we have classified risks for the project, determine if there are commonalities across the various risks we have uncovered (suggesting common causes of the risks that can be addressed at a higher level), and create a prioritiza- tion scheme for addressing these risks.

5. Clarify ownership of risks—Distinguish between risks that the project organization is willing to handle and those that the clients are expected to accept as well as allocate responsibility for managing risks and responses.

6. Estimate—Develop a reasonable estimate of the impacts on the project of both the identified risks and the proposed solutions. What are the likely scenarios and their relative potential costs?

7. Evaluate—Critically evaluate the results of the estimate phase to determine the most likely plan for mitigating potential risks. Begin to prioritize risks and the project team’s responses.

8. Plan—Produce a project risk management plan that proactively offers risk mitigation strate- gies for the project as needed.

9. Manage—Monitor actual progress with the project and associated risk management plans, responding to any variances in these plans, with an eye toward developing these plans for the future.

242 Chapter 7 • Risk Management

Table 7.4 shows a generic risk management process following the PRAM methodology. At each of the risk management phases, specific project deliverables can be identified, allowing the project team to create comprehensive project risk management documentation while addressing specific steps along the way. These deliverables are important because they indicate to project managers exactly the types of information they should be collecting at different phases of the project and the materials they should make available to relevant stakeholders.

The PRAM model for risk management is extremely helpful because it offers project manag- ers a systematic process for best employing risk assessment and mitigation strategies. Composed of nine interconnected steps that form a logical sequence, PRAM creates a unifying structure under which effective risk management can be conducted. Because it follows the logic of the project life cycle, PRAM should be conducted not as a “one-shot” activity but as an ongoing, progressive scheme that links project development directly to accurate risk assessment and management.

taBle 7.4 A Generic risk Management Process (rMP) following the PrAM Methodology

Phases Purposes Deliverables

Define Consolidate relevant existing information about the project.

A clear, unambiguous, shared understanding of all key aspects of the project documented, verified, and reported.

Focus 1. Identify scope and provide a strategic plan for the RMP.

2. Plan the RMP at an operational level.

A clear, unambiguous, shared understanding of all relevant key aspects of the RMP, documented, verified, and reported.

Identify 1. Identify where risk might arise. 2. Identify what we might do about this risk

in proactive and reactive response terms. 3. Identify what might go wrong with our

responses.

All key risks and responses identified; both threats and opportunities classified, characterized, documented, verified, and reported.

Structure 1. Test simplifying assumptions. 2. Provide more complex structure when

appropriate.

A clear understanding of the implications of any important simplifying assumptions about relationships among risks, responses, and base plan activities.

Ownership 1. Client contractor allocation of ownership and management of risks and responses.

2. Allocation of client risks to named individuals. 3. Approval of contractor allocations.

Clear ownership and management allocations effectively and efficiently defined, legally enforceable in practice where appropriate.

Estimate 1. Identify areas of clear significant uncertainty. 2. Identify areas of possible significant

uncertainty.

1. A basis for understanding which risks and responses are important.

2. Estimates of likelihood and impact on scenario or in numeric terms.

Evaluate Synthesis and evaluation of the results of the estimate phase.

Diagnosis of all important difficulties and comparative analysis of the implications of responses to these difficulties, with specific deliverables like a prioritized list of risks.

Plan Project plan ready for implementation and associated risk management plan.

1. Base plans in activity terms at the detailed level of implementation.

2. Risk assessment in terms of threats and opportunities prioritized, assessed in terms of impact.

3. Recommended proactive and reactive contingency plans in activity terms.

Manage 1. Monitoring. 2. Controlling. 3. Developing plans for immediate

implementation.

1. Diagnosis of a need to revisit earlier plans and initiation of replanning as appropriate.

2. Exception reporting after significant events and associated replanning.

Summary 243

Finally, in identifying the key deliverables at each step in the process, the PRAM model ensures a similarity of form that allows top management to make reasonable comparisons across all projects in an organization’s portfolio.

Project risk management demonstrates the value of proactive planning for projects as a way to anticipate and, hopefully, mitigate serious problems that could adversely affect the proj- ect at some point in the future.14 The value of this troubleshooting process is that it requires us to think critically, to be devil’s advocates when examining how we are planning to develop a project. Research and common sense suggest, in the words of the adage, “An ounce of preven- tion is worth a pound of cure.” The more sophisticated and systematic we are about conducting project risk management, the more confident we can be, as the project moves through planning and into its execution phase, that we have done everything possible to prepare the way for proj- ect success.

Summary

1. define project risk. Project risk is defined as any possible event that can negatively affect the viability of a project. We frequently use the equation: Risk event = (Probability of event)(Consequences of event). Effective risk management goes a long way toward influencing project development. To be effective, however, project risk management needs to be done early in the project’s life. To quote Shakespeare’s Macbeth: “If it were done, when ’tis done; then ’twere well it were done quickly.”15 As an important element in overall project planning, risk management identifies specific risks that can have a detrimental effect on project performance and quan- tifies the impact each risk may have. The impact of any one risk factor is defined as the product of the likelihood of the event’s occurrence and the adverse consequences that would result. The tremendous number of unknowns in the early phases of a project makes this the time when risk is highest. As the proj- ect moves forward, the team continues to address risk with technical, administrative, and budgetary strategies.

2. recognize four key stages in project risk man- agement and the steps necessary to manage risk. There are four distinct phases of project risk management: (1) risk identification, (2) analysis of probability and consequences, (3) risk mitigation strategies, and (4) control and documentation. Risk identification focuses on determining a realistic set of risk factors that a project faces. In analysis of probability and consequences, the project team prioritizes its responses to these various risk fac- tors by assessing the “impact factor” of each one. Impact factors are determined either in a qualita- tive manner, using a matrix approach and consen- sus decision making, or in more quantitative ways, in which all relevant probability and consequence parameters are laid out and used to assess overall

project risk. The project team begins the process of developing risk mitigation strategies once a clear vision of risk factors is determined. The last step in the risk management process, control and doc- umentation, is based on the knowledge that risk management strategies are most effective when they have been codified and introduced as part of standard operating procedures. The goal is to cre- ate systematic and repeatable strategies for project risk management.

3. Understand five primary causes of project risk and four major approaches to risk identification. The five primary causes of project risk are (1) financial risk, (2) technical risk, (3) commercial risk, (4) execu- tion risk, and (5) contractual or legal risk. Among the most common methods for risk identification are (1)  brainstorming meetings, (2) expert opin- ion, (3) past history, and (4) multiple or team-based assessments.

4. recognize four primary risk mitigation strategies. Risks can be mitigated through four primary approaches. First, we can simply accept the risk. We may choose to do this in a situation in which we either have no alternative or we consider the risk small enough to be acceptable. Second, we can seek to minimize risk, perhaps through entering partnerships or joint ventures in order to lower our company’s exposure to the risk. Third, we can share risk with other organizations or project stakeholders. Finally, when appropriate, we may seek to transfer risk to other project stakeholders.

5. explain the Project risk Analysis and Management (PrAM) process. PRAM is a generic project risk management approach that offers a model for the life cycle steps a project team might adopt in developing a risk management methodology. Nine distinct steps in the PRAM model present each phase of the process and its associated deliverables.

244 Chapter 7 • Risk Management

Key Terms

Analysis of probability and consequences (p. 228)

Change management (p. 238)

Commercial risk (p. 229) Contingency reserves

(p. 236) Contractual or legal risk

(p. 229)

Control and documentation (p. 228)

Cross-training (p. 237) Execution risk (p. 229) Financial risk (p. 228) Fixed-price contact

(p. 235) Insurance (p. 237) Liquidated damages

(p. 235)

Managerial contingency (p. 236)

Mentoring (p. 237) Project risk (p. 225) Project Risk Analysis and

Management (PRAM) (p. 241)

Risk Breakdown Structure (p. 231)

Risk identification (p. 228)

Risk management (p. 225)

Risk mitigation strategies (p. 228)

Task contingency (p. 236) Technical risk (p. 228)

7.1 QuANtitAtiVe riSk ASSeSSMeNt Refer to the risk factors shown in Table 7.1. Assume your project team has decided upon the following risk values:

Pm = .1 Cc = .7 Pc = .5 Cs = .5 Pd = .9 Cr = .3

Cp = .1

You wish to determine the overall project risk using a quanti- tative method. Following the formulas shown in Table 7.2, we can calculate both the probability of project risk score and the consequences of project risk score, as follows:

Pf = (.1 + .5 + .9)/3 = .5 Cf = (.7 + .5 + .3 + .1)/4 = .4

RF = .5 + .4 - (.5)(.4) = .70 conclusion: Medium risk to overall project.

Solved Problem

7.1 Assessing risk factors. Consider the planned construc- tion of a new office building in downtown Houston at a time when office space is in surplus demand (more office space than users). Construct a risk analysis that examines the various forms of risk (technical, commercial, financial, etc.) related to the creation of this office building. How

would your analysis change if office space were in high demand?

7.2 Qualitative risk Assessment. Imagine that you are a member of a project team that has been charged to de- velop a new product for the residential building indus- try. Using a qualitative risk analysis matrix, develop

Problems

Discussion Questions

7.1 Do you agree with the following statement: “With proper planning it is possible to eliminate most/all risks from a project”? Why or why not?

7.2 In evaluating projects across industries, it is sometimes possible to detect patterns in terms of the more common types of risks they routinely face. Consider the develop- ment of a new software product and compare it to coordi- nating an event, such as a school dance. What likely forms of risk would your project team face in either of these circumstances?

7.3 Analyze Figure 7.2 (degree of risk over the project life cycle). What is the practical significance of this model? What implications does it suggest for managing risk?

7.4 What are the benefits and drawbacks of using the various forms of risk identification mentioned in the chapter (e.g., brainstorming meetings, expert opinion, etc.)?

7.5 What are the benefits and drawbacks of using a qualitative risk impact matrix for classifying the types of project risk?

7.6 What are the benefits and drawbacks of using a quanti- tative risk assessment tool such as the one shown in the chapter?

7.7 Give some examples of projects using each of the risk mitigation strategies (accept, minimize, share, or transfer). How successful were these strategies? In hindsight, would another approach have been better?

7.8 Explain the difference between managerial contingency and task contingency.

7.9 What are the advantages of developing and using a sys- tematic risk management approach such as the PRAM methodology? Do you perceive any disadvantages of the approach?

7.10 Consider the following observation: “The problem with risk analysis is that it is possible to imagine virtually any- thing going wrong on a project. Where do you draw the line? In other words, how far do you take risk analysis be- fore it becomes overkill?” How would you respond?

Case Study 7.1 245

a risk assessment for a project based on the following information:

identified risk factors likelihood

1. Key team members pulled off project 1. High

2. Chance of economic downturn 2. Low

3. Project funding cut 3. Medium

4. Project scope changes 4. High

5. Poor spec. performance 5. Low

Based on this information, how would you rate the conse- quences of each of the identified risk factors? Why? Con- struct the risk matrix and classify each of the risk factors in the matrix.

7.3 developing risk Mitigation strategies. Develop a pre- liminary risk mitigation strategy for each of the risk fac- tors identified in Problem 2. If you were to prioritize your efforts, which risk factors would you address first? Why?

7.4 Quantitative risk Assessment. Assume the following information:

Probability of failure consequences of failure

Maturity = .3 Cost = .1

Complexity = .3 Schedule = .7

Dependency = .5 Performance = .5

Calculate the overall risk factor for this project. Would you assess this level of risk as low, moderate, or high? Why?

7.5 Quantitative risk Assessment. Assume the following information for an IT project.

Probability of failure consequences of failure

Maturity = .7 Cost = .9 Complexity = .7 Schedule = .7 Dependency = .5 Client Concerns = .5 Programmer Skill = .3

Performance = .3 Future Business = .5

Calculate the overall risk factor for this project. Would you assess this level of risk as low, moderate, or high? Why?

7.6 developing risk Mitigation strategies. Assume that you are a project team member for a highly complex project based on a new technology that has never been directly proven in the marketplace. Further, you require the ser- vices of a number of subcontractors to complete the design and development of this project. Because you are facing se- vere penalties in the event the project is late to market, your boss has asked you and your project team to develop risk mitigation strategies to minimize your company’s expo- sure. Discuss the types of risk that you are likely to encoun- ter. How should your company deal with them (accept them, share them, transfer them, or minimize them)? Justify your answers.

7.7 Assessing risk and Benefits. Suppose you are a mem- ber of a project team that is evaluating the bids of poten- tial contractors for developing some subassemblies for your project. Your boss makes it clear that any successful bid must demonstrate a balance between risk and price. Explain how this is so; specifically, why are price and risk seen as equally important but opposite issues in determin- ing the winner of the contract? Is a low-price/high-risk bid acceptable? Is a high-price/low-risk bid acceptable? Why or why not?

CaSE STuDy 7.1 Classic Case: de Havilland’s Falling Comet

(continued)

The Development of the Comet

The de Havilland Aircraft Company of Great Britain had long been respected in the aircraft manufactur- ing industry for its innovative and high-performance designs. Coming off its excellent work during World War II, the company believed that it stood poised on the brink of success in the commercial airframe indus- try. The de Havilland designers and executives accu- rately perceived that the next generation of airplane would be jet-powered. Consequently, they decreed that their newest commercial airframe, tentatively called the Comet, would employ jet power and other leading- edge technology.

Jets offered a number of advantages over propeller-driven airplanes, the most obvious of which was speed. Jets could cruise at nearly 450 miles per

hour compared with the 300 miles per hour a pro- peller could generate. For overseas flight, in particu- lar, this advantage was important. It could reduce the length of long flights from a mind-numbing two to three days to mere hours, encouraging more and more businesspeople and tourists to use airplanes as their primary method for travel. Further, jets tended to be quieter than propeller-driven aircraft, giving a more comfortable interior sound level and ride to passengers.

De Havilland engineers sought to create a stream- lined airplane that could simultaneously carry up to 50 passengers in comfort, while maintaining aerody- namics and high speed. After working with a number of design alternatives, the Comet began to take shape. Its design was, indeed, distinctive: The four jet engines

246 Chapter 7 • Risk Management

were embedded in pairs in the wing roots, at the point where they joined the fuselage. From the front, the aircraft looked as though its wings were literally held in place by the engines. The result of these innovative engineering designs was an aircraft that had remark- able stability in flight, was sleek in appearance, and was very fast.

Another distinctive feature of the aircraft was the pressurized cabin, intended to maintain passenger comfort at cruising altitudes of up to 30,000 feet. In its original testing for safety, de Havilland engineers had pressurized the airframe to more than five times the recommended air density to ensure that there was a clean seal. Consequently, they were confident that the pressurization system would perform well at its lower, standardized settings. Finally, in an effort to add some flair to the design, each window in the passenger cabin was square, rather than the small, round or oval shapes so commonly used.

Knowing that it was facing competition from Boeing Corporation to be first to market with a com- mercial jet, de Havilland’s goal was to introduce its new aircraft as quickly as possible, in order to establish the standard for the commercial airline industry. At first, it appeared the company had succeeded: BOAC (British Overseas Airways Corporation) ordered sev- eral Comets, as did Air France and the British mili- tary. De Havilland also received some queries from interested American airline companies, notably Pan American Airlines. It looked as though de Havilland’s strategy was working; the company was first to

market with a radical new design, using a number of state-of-the-art technologies. BOAC’s first nine Comet 1 s entered service with the airline on May 2, 1952. The future looked bright.

Troubles

In early May of 1953, a brand new Comet operated by BOAC left Calcutta, India, and flew off into the after- noon sky. Six minutes later and only 22 miles from Calcutta’s Dum Dum Airport, the aircraft exploded and plunged to earth, killing all 43 passengers and crew on board. There had been no indication of prob- lems and no warning from the pilots of technical dif- ficulties. Investigators from Great Britain and India tended to believe the crash came about due to pilot error coupled with weather conditions. Evidence from the wreckage, including the tail section, seemed to indicate that the aircraft had been struck by something heavy, but without any additional information forth- coming, both the authorities and de Havilland engi- neers laid the blame on external causes.

January 10, 1954, was a mild, clear day in Rome as passengers boarded their BOAC aircraft for the final leg of their flight from Singapore to London. When the airplane reached its cruising altitude and speed, it dis- integrated over the Mediterranean Sea, near the island of Elba. Most of the airplane was lost at the bottom of the sea, but amid the flotsam 15 bodies of passen- gers and crew were recovered. A local physician who examined the remains noted: “They showed no look of terror. Death must have come without warning.”

Figure 7.10 the de Havilland comet

Source: Heanly Mirrorpix/Newscom

Case Study 7.1 247

As a safety precaution, BOAC instituted a ban on the use of Comets until the airplanes had been thoroughly checked over. Technicians could find nothing wrong with the new aircraft and, following recertification, the airplanes were again brought back into service.

Alas, it was too soon. On April 8, only 16 days after the Comet was reintroduced into service, a third aircraft, operated by South African Airways, departed from Rome’s Ciampino airport for Cairo, one of the legs of its regular flight from London to Johannesburg. Under perfect flying weather, the airplane rapidly gained its cruising altitude of 26,000 feet and its air- speed of almost 500 miles an hour. Suddenly, the flight radio went silent and failed to answer repeated calls. A search of the ocean off the island of Stromboli, Italy, turned up an oil slick and some debris. Because of the depth of the water and the time necessary to arrive at the crash site, there was little to be found by search crews. Five bodies were all that were recovered this time, though with an eerie similarity to the victims of the second disaster: Facial expressions showed no fear, as though death had come upon them suddenly.

What Went Wrong?

Investigators swarmed over the recovered wreckage of the aircraft and reexamined the pieces from the first Calcutta accident while also conducting underwater searches at the sight of the second crash near the island of Elba. Guided by underwater cameras, investigators were able to collect sufficient aircraft fragments (in fact, they finally recovered nearly 70% of the airframe) to make some startling discoveries. The foremost finding, from the recovery of the entire, intact tail section, was that the fuselage of the aircraft had exploded. Second, it appeared that engine failure was not the cause of the accidents. Another finding was equally important: The wings and fuselage showed unmistakable signs of metal fatigue, later shown to be the cause of failure in all three aircraft. This point was important because it advanced the theory that the problem was one of structural design rather than simple part failure.

Britain’s Civil Aviation Board immediately grounded the entire Comet fleet pending extensive reviews and airworthiness certification. For the next five months, the CAB set out on an extensive series of tests to isolate the exact causes of the mysterious crashes. Before testing was complete, one Comet had been tested literally to destruction, another had its fuel tanks ruptured, more than 70 complete test flights were made in a third, and between 50 and 100 test models were broken up. The results of the extensive tests indi- cated a number of structural and design flaws.

Although the aircraft’s designers were convinced that the structure would remain sound for 10,000 flight

hours before requiring major structural overhaul- ing, simulations showed unmistakable signs of metal fatigue after the equivalent of only 3,000 flight hours. Experts argued that even when fatigue levels were revised downward to less than 3,000 hours, Comets would not be safe beyond 1,000 flying hours, a ludi- crously low figure in terms of the amount of use a commercial airliner is expected to receive. In addition, testing of the fuselage offered disturbing indications of the cause of failure. Specifically, cracks began devel- oping in the corners of the cabin windows, and these cracks were exacerbated by repeated pressurization and depressurization of the cabin. The investigators noted that this result was most pronounced along the rivet lines near the fuselage windows.

Testing also demonstrated that the wings had a low resistance to fatigue. At a number of stages in the tests, serious cracks appeared, starting at the rivet holes near the wheel wells and finally resulting in rivet heads in the top wing surface actually shearing off. Engineers and investigators were finding incontrovertible evi- dence in the pieces of recovered wreckage that the cause of the sudden disintegration of the aircraft could only have been due to cabin pressure blowout. Engineers suspected that the critical failure of the aircraft occurred following sudden depressurization, when one or more windows were literally blown out of the aircraft. This led to a sudden “gyroscopic moment” as the aircraft nosed down and began its plunge to earth.

Although at the time no one would admit it, the handwriting was on the wall. After two years, in which Comets carried more than 55,000 passengers over 7 million air miles, the Comet 1 was never to fly again. De Havilland had indeed won the race to be first to market with a commercial jet—a race that it would have been better to have never run at all.16

Questions

1. How could risk management have aided in the development of the Comet?

2. Discuss the various types of risk (technical, finan- cial, commercial, etc.) in relation to the Comet. Develop a qualitative risk matrix for these risk factors and assess them in terms of probability and consequences.

3. Given that a modified version of the Comet (the Comet IV) was used until recently by the British government as an antisubmarine warfare air- craft, it is clear that the design flaws could have been corrected given enough time. What, then, do you see as de Havilland’s critical error in the development of the Comet?

4. Comment on this statement: “Failure is the price we pay for technological advancement.”

248 Chapter 7 • Risk Management

CaSE STuDy 7.2 The Spanish Navy Pays Nearly $3 Billion for a Submarine That Will Sink Like a Stone

In 2003, shipbuilders at Navantia, Spain’s state- owner shipyard, welcomed a contract from their navy to construct four state-of-the-art submarines. The S-80 class was going to be an engineering mar- vel, filled with the latest and most cutting-edge technology, including a diesel-electric propulsion system that would be 20% lighter than other ships, while delivering 50% more power. As the list of up- grades and new technical gadgetry grew, the deliv- ery date for the Isaac Peral—the lead ship in the S-80 class—continued to ship further behind schedule. Nevertheless, it wasn’t the continuous upgrading and addition of new equipment that finally slammed the brakes on the project; it was the startling warning from Navantia’s engineers that the Isaac Peral was not seaworthy. The submarine, named in honor of the Spanish man credited by some as the inventor of the underwater vessel, was 75–100 tons overweight, an excess that could make it difficult or impossible for the submarine to surface after submerging. As a re- sult, the Spanish navy was faced with the challenge of fixing a submarine that ran the risk of disaster whenever it decided to submerge!

Navantia admitted the existence of “devia- tions related to the balance of weight” in the vessel and estimated it would take up to two years more to correct the problem, pushing the new delivery date to late 2018. The firm’s engineers are trying to determine their best options at this point. It appears that two choices are most likely: Find a way to trim the design of the overall ship, which would be very difficult at this stage in construction, or lengthen the hull of the already 233-foot submarine to com- pensate for the extra weight. The problem with this option is that designers have estimated that for every meter the hull is lengthened, it will end up costing nearly 10 million additional euros (about $14 million dollars). Unfortunately for the Spaniards, indepen- dent agencies report that they have already sunk the equivalent of $680 million into the Isaac Peral, and a total of $3 billion into the entire quartet of S-80 class submarines.

The buoyancy problem is not the only difficulty facing the program; an analyst said that that sub- marine’s air-independent propulsion (AIP) system

reactor is also underperforming. A Strategic Studies Group spokesperson said that the AIP system has been designed to enable the submarine to operate underway for 28 days but is currently able to man- age only one week. The Group’s memo suggests, “The buoyancy problem alone could cost up to half a billion euros to cover redesign and extra construc- tion, without considering the propulsion problem.”

The submarine setback couldn’t have come at a worse time for Prime Minister Mariano Rajoy, who was already caught up in a corruption scan- dal and saw his approval rating hit a record low in 2013. Because of the poor shape of Spain’s economy, Rajoy’s austerity cuts trimmed the Spanish military budget by 30 percent in 2012, leaving much less room for added ballast. With reports that the S-80 program will be delayed an estimated two years and another general election looming in 2015, Rajoy likely will not see the submarines through to suc- cessful launch.

How did such an expensive project get funded at a time when the Spanish military’s entire special weap- ons program received a 98% cut? Sheer pride seems to have been a factor: Spain hoped the S-80 class would be a new homegrown breakthrough achieved with- out foreign help. Now that Navantia has entered into a $15 million contract with the Electric Boat Division of America’s General Dynamics to help with the rede- sign, that dream seems dead in the water.17

Questions

1. Google “Spain’s S-80 class submarine” and read some of the articles posted. In your opinion, how does technical risk cause problems with major defense projects?

2. Why do you think it is common for defense con- tractors to add new features and modifications to current programs? In other words, why do defense agencies contract for one project, only to see it often evolve into something new by the time it is launched?

3. If you were an advisor brought in by the Spanish government, what advice would you offer them in managing their defense projects?

Case Study 7.3 249

The dramatic collapse of the Tacoma Narrows suspen- sion bridge in 1940, barely four months after comple- tion, was a severe blow to the design and construction of large span bridges. It serves as a landmark failure in engineering history and is, indeed, a featured lesson in most civil engineering programs. The story of the col- lapse serves as a fascinating account of one important aspect of project failure: engineering’s misunderstand- ing of the effect that a variety of natural forces can have on projects, particularly in the construction industry.

Opening in July 1941, the Tacoma Narrows Bridge was built at a cost of $6.4 million and was largely funded by the federal government’s Public Works Administration. The purpose of the bridge was essentially viewed as a defense measure to connect Seattle and Tacoma with the Puget Sound Navy Yard at Bremerton.18 As the third-largest single suspension bridge in the world, it had a center span of 2,800 feet and 1,000-foot approaches at each end.

Even before its inauguration and opening, the bridge began exhibiting strange characteristics that were immediately noticeable. For example, the slightest wind could cause the bridge to develop a pronounced longitudinal roll. The bridge would quite literally begin to lift at one end and, in a wave action, the lift would “roll” the length of the bridge. Depending upon the severity of the wind, cameras were able to detect any- where up to eight separate vertical nodes in its rolling action. Many motorists crossing the bridge complained of acute seasickness brought on by the bridge’s rising and falling. So well-known to the locals did the strange weaving motion of the bridge become that they nick- named the bridge “Galloping Gertie.”

That the bridge was experiencing increasing and unexpected difficulties was clear to all involved in the project. In fact, the weaving motion of Galloping Gertie became so bad as the summer moved into fall that heavy steel cables were installed externally to the span in an attempt to reduce the wind-induced motion. The first attempt resulted in cables that snapped as they were being put into place. The second attempt, later in the fall, seemed to calm the swaying and oscillating motion of the bridge initially. Unfortunately, the cables would prove to be incapable of forestalling the effects of the dynamic forces (wind) playing on the bridge; they snapped just before the final critical torsional oscillations that led to the bridge’s collapse.

On November 7, 1940, a bare four months after opening of the bridge, with winds of 42 miles per hour blowing steadily, the 280-foot main span that had already begun exhibiting a marked flex went into

a series of violent vertical and torsional oscillations. Alarmingly, the amplitudes steadily increased, suspen- sions came loose, the support structures buckled, and the span began to break up. In effect, the bridge seemed to have come alive, struggling like a bound animal, and was literally shaking itself apart. Motorists caught on the bridge had to abandon their cars and crawl off the bridge, as the side-to-side roll had become so pro- nounced (by now, the roll had reached 45 degrees in either direction, causing the sides of the bridge to rise and fall more than 30 feet) that it was impossible to tra- verse the bridge on foot.

After a fairly short period of time in which the wave oscillations became incredibly violent, the sus- pension bridge simply could not resist the pounding and broke apart. Observers stood in shock on either side of the bridge and watched as first large pieces of the roadway and then entire lengths of the span rained down into the Tacoma Narrows below. Fortunately, no human lives were lost, since traffic had been closed in the nick of time.

The slender 12-meter-wide main deck had been supported by massive 130-meter-high steel towers comprised of 335-foot-long spans. These spans man- aged to remain intact despite the collapse of the main span. The second bridge (TNB II) would end up mak- ing use of these spans when it was rebuilt shortly there- after, by a new span stiffened with a web truss.

Following the catastrophic failure, a three- person committee was immediately convened to determine the causes of the Tacoma Narrows Bridge collapse. The board consisted of some of the top scientists and engineers in the world at that time: Othmar Ammann, Theodore von Karman, and Glenn Woodruff. While satisfied that the basic design was sound and the suspension bridge had been con- structed competently, these experts nevertheless were able to quickly uncover the underlying contributing causes to the bridge collapse:

• design features—The physical construction of the bridge contributed directly to its failure and was a source of continual concern from the time of its completion. Unlike other suspension bridges, one distinguishing feature of the Tacoma Narrows Bridge was its small width-to-length ratio—smaller than any other suspension bridge of its type in the world (although almost one mile in length, the bridge was only constructed to carry a single traffic lane in each direction). That ratio means quite simply that the bridge was

CaSE STuDy 7.3 Classic Case: Tacoma Narrows Suspension Bridge

(continued)

250 Chapter 7 • Risk Management

incredibly narrow for its long length, a fact that was to contribute hugely to its distinctive oscil- lating behavior.

• Building materials—Another feature of the con- struction that was to play an important role in its collapse was the substitution of key structural components. The original plans called for the use of open girders in the construction of the bridge’s sides. Unfortunately, at some point, a local con- struction engineer substituted flat, solid girders that deflected the wind rather than allowing for its passage. The result was to cause the bridge to catch the wind “like a kite” and adopt a perma- nent sway. In engineering terms, the flat sides simply would not allow wind to pass through the sides of the bridge, reducing its wind drag. Instead, the solid, flat sides caught the wind that pushed the bridge sideways until it had swayed enough to “spill” the wind from the vertical plane, much as a sailboat catches and spills wind in its sails.

• Bridge location—A final problem with the ini- tial plan lay in the actual location selected for the bridge’s construction. Although the investigat- ing committee did not view the physical location of the bridge as contributing to its collapse, the location did play an important secondary role through its effect on wind currents. The topog- raphy of the Tacoma Narrows over which the bridge was constructed was particularly prone to high winds due to the narrowing down of the land on either side of the river. The unique char- acteristics of the land on which the bridge was built virtually doubled the wind velocity and acted as a sort of wind tunnel.

Before this collapse, not much was known about the effects of dynamic loads on structures. Until then, it had always been taken for granted in bridge build- ing that static load (downward forces) and the sheer bulk and mass of large trussed steel structures were enough to protect them against possible wind effects. It took this disaster to firmly establish in the minds of design engineers that dynamic, and not static, loads are really the critical factor in designing such structures.

The engineering profession took these lessons to heart and set about a radical rethinking of their conventional design practices. The stunning part of this failure was not so much the oscillations, but the spectacular way in which the wave motions along the main span turned into a destructive tossing and turn- ing and led finally to the climax in which the deck was wrenched out of position. The support cables snapped

one at a time, and the bridge began to shed its pieces in larger and larger chunks until the integrity was com- pletely compromised.

Tacoma Narrows Bridge: The Postmortem

Immediately following the bridge’s collapse, the inves- tigating board’s final report laid the blame squarely on the inadequacy of a design that did not anticipate the dynamic properties of the wind on what had been thought a purely static design problem. Although lon- gitudinal oscillations were well understood and had been experienced early in the bridge’s construction, it was not until the bridge experienced added torsional rolling movements that the bridge’s failure became inevitable.

One member of the board investigating the acci- dent, Dr. Theodore von Karman, faced the disbelief of the engineering profession as he pushed for the application of aerodynamics to the science of bridge building. It is in this context that he later wrote his memoirs in which he proclaimed his dilemma in this regard: “Bridge engineers, excellent though they were, couldn’t see how a science applied to a small unstable thing like an airplane wing could also be applied to a huge, solid, nonflying structure like a bridge.”

The lessons from the Tacoma Narrows Bridge collapse are primarily those of ensuring a general awareness of technical limitations in project design. Advances in technology often lead to a willingness to continually push out the edges of design enve- lopes, to try and achieve maximum efficiency in terms of design. The problem with radical designs or even with well-known designs used in unfa- miliar ways is that their effect cannot be predicted using familiar formulae. In essence, a willingness to experiment requires that designers and engineers begin to work to simultaneously develop a new cal- culus for testing these designs. It is dangerous to assume that a technology, having worked well in one setting, will work equally well in another, par- ticularly when other variables in the equation are subject to change.

The Tacoma Narrows Bridge collapse began in  high drama and ended in farce. Following the bridge’s destruction, the state of Washington discov- ered, when it attempted to collect the $6 million insur- ance refund on the bridge, that the insurance agent had simply pocketed the state’s premium and never both- ered obtaining a policy. After all, who ever heard of a bridge the size of the Tacoma Narrows span collaps- ing? As von Karman wryly noted, “He [the insurance agent] ended up in jail, one of the unluckiest men in the world.”19

Internet Exercises 251

Questions

1. In what ways were the project’s planning and scope management appropriate? When did the planners begin taking unknowing or unneces- sary risks? Discuss the issue of project constraints and other unique aspects of the bridge in the risk management process. Were these issues taken into consideration? Why or why not?

Internet Exercises

7.1 Go to www.informationweek.com/whitepaper/ Management/ROI-TCO/managing-risk-an-integrated- approac-wp1229549889607?articleID=54000027 and access the article on “Managing Risk: An Integrated Approach.” Consider the importance of proactive risk management in light of one of the cases at the end of this chapter. How were these guidelines violated by de Havilland or the Tacoma Narrows construction project organization? Support your arguments with information either from the case or from other Web sites.

7.2 FEMA, the Federal Emergency Management Agency, is re- sponsible for mitigating or responding to natural disasters within the United States. Go to www.fema.gov/about/di- visions/mitigation.shtm. Look around the site and scroll down to see examples of projects in which the agency is involved. How does FEMA apply the various mitigation strategies (e.g., accept, minimize, share, and transfer) in its approach to risk management?

7.3 Go to www.mindtools.com/pages/article/newTMC_07. htm and read the article on managing risks. What does the article say about creating a systematic methodology for managing project risks? How does this methodology compare with the qualitative risk assessment approach taken in this chapter? How does it diverge from our approach?

7.4 Using the keyword phrase “cases on project risk man- agement,” search the Internet to identify and report on a recent example of a project facing significant risks. What steps did the project organization take to first identify and then mitigate the risk factors in this case?

7.5 Go to www.project-management-podcast.com/index.php/ podcast-episodes/episode-details/109-episode-063-how- do-risk-attitudes-affect-your-project to access the pod- cast on risk attitudes on projects. What does the speaker, Cornelius Fichtner, PMP, suggest about the causes of project failures as they relate to issues of risk management?

PMP certificAtion sAMPle QUestions

1. The project manager has just met with her team to brainstorm some of the problems that could occur on the upcoming project. Today’s session was intended to generate possible issues that could arise and get everyone to start thinking in terms of what they should

be looking for once the project kicks off. This meeting would be an example of what element in the risk man- agement process?

a. Risk mitigation b. Control and documentation c. Risk identification d. Analysis of probability and consequences

2. Todd is working on resource scheduling in preparation for the start of a project. There is a potential problem in the works, however, as the new collective bargain- ing agreement with the company’s union has not been concluded. Todd decides to continue working on the resource schedule in anticipation of a satisfactory settle- ment. Todd’s approach would be an example of which method for dealing with risk?

a. Accept it b. Minimize it c. Transfer it d. Share it

3. A small manufacturer has won a major contract with the U.S. Army to develop a new generation of satellite phone for battlefield applications. Because of the sig- nificant technological challenges involved in this proj- ect and the company’s own size limitations and lack of experience in dealing with the Army on these kinds of contracts, the company has decided to partner with another firm in order to collaborate on developing the technology. This decision would be an example of what kind of response to the risk?

a. Accept it b. Minimize it c. Transfer it d. Share it

4. All of the following would be considered examples of significant project risks except:

a. Financial risks b. Technical risks c. Commercial risks d. Legal risks e. All are examples of significant potential project risks

5. Suppose your organization used a qualitative risk assessment matrix with three levels each of prob- ability and consequences (high, medium, and low).

2. Conduct either a qualitative or quantitative risk assessment on this project. Identify the risk fac- tors that you consider most important for the suspension bridge construction. How would you assess the riskiness of this project? Why?

3. What forms of risk mitigation would you con- sider appropriate for this project?

252 Chapter 7 • Risk Management

In evaluating a project’s risks, you determine that com- mercial risks pose a low probability of occurrence but high consequences. On the other hand, legal risks are evaluated as having a high probability of occurrence and medium consequences. If you are interested in pri- oritizing your risks, which of these should be consid- ered first?

a. Commercial risk b. Legal risk c. Both should be considered equally significant d. Neither is really much of a threat to this project, so

it doesn’t matter what order you assign them

Answers: 1. c—Brainstorming meetings are usually cre- ated as an effective means to get project team members to begin identifying potential risks; 2. a—Todd is choosing to accept the risk of potential future problems by continuing to work on his resource schedule in anticipation of positive contract talks; 3. d—The firm has decided to share the risk of the new project by partnering with another company; 4. e—All are examples of significant potential project risks; 5. b—Legal risks would be of higher overall significance (high probability, medium consequence) and so should probably be considered first in a prioritization scheme.

Integrated Project 253

iNteGrAteD Project

Project risk Assessment Conduct a preliminary risk analysis of your project. Use two techniques, one qualitative and one quantita- tive, in supporting your evaluation of project risk. In order to do this, you will need to:

• Generate a set of likely risk factors. • Discuss them in terms of probability and consequences. • Develop preliminary strategies for risk mitigation.

An effective risk analysis will demonstrate clear understanding of relevant project risks, their potential impact (probability and consequences), and preliminary plans for minimizing the negative effects.

saMPle risk analysis—aBc u p s, inc. Among the potential threats or uncertainties contained in this project, the following have been identified:

1. Plant reorganization could take longer than anticipated. Process engineering may be more complicated or unexpected difficulties could arise while the process alterations are underway.

2. A key project team member could be reassigned or no longer able to work on the project. Due to other requirements or top management reshuffling of resources, the project could lose one of its key core team members.

3. The project budget could be cut because of budget cutbacks in other parts of the company. The project budget could be trimmed in the middle of the development cycle.

4. Suppliers might be unable to fulfill contracts. After qualifying vendors and entering into contracts with them, it might be discovered that they cannot fulfill their contractual obligations, requiring the project team and organization to rebid contracts or accept lower-quality supplies.

5. New process designs could be found not to be technically feasible. The process engineers might deter- mine midproject that the project’s technical objectives cannot be achieved in the manner planned.

6. New products might not pass QA assessment testing. The project team might discover that the equip- ment purchased and/or the training that plant personnel received are insufficient to allow for proper quality levels of the output.

7. Vendors could discover our intentions and cut deliveries. Current vendors might determine our intent of eliminating their work and slow down or stop deliveries in anticipation of our company canceling contracts.

8. Marketing might not approve the prototype cups produced. The sales and marketing department might determine that the quality or “presence” of the products we produce are inferior and unlikely to sell in the market.

9. The new factory design might not be approved during government safety inspections. The factory might not meet OSHA requirements.

Qualitative risk assessMent

Probability

C o n se

q u en

ce s

low Med High

H ig

h

5 8

M e d

3, 9 2 1

lo w 4 6, 7

254 Chapter 7 • Risk Management

Risk Mitigation Strategies

High risk Mitigation Strategy

1. Plant reorganization takes longer than anticipated. 1. Develop a comprehensive project tracking program to maintain schedule.

2. Marketing does not approve the prototype cups produced.

2. Maintain close ties to sales department—keep them in the loop throughout project development and quality control cycles.

Moderate risk

3. New process designs are found to not be techni- cally feasible.

3. Assign sufficient time for quality assessment during prototype stage.

4. A key project team member could be reassigned or no longer able to work on the project.

4. Develop a strategy for cross-training personnel on elements of one another’s job or identify suitable replacement resources within the organization.

low risk

5. The project budget could be cut. 5. Maintain close contact with top management re- garding project status, including earned value and other control documentation.

6. Factory does not pass OSHA inspections. 6. Schedule preliminary inspection midway through project to defuse any concerns.

7. Suppliers are unable to fulfill contracts. 7. Qualify multiple suppliers at prototyping stage.

8. New products do not pass QA assessment testing.

8. Assign team member to work with QA department on interim inspection schedule.

9. Vendors discover our intentions and cut deliveries.

9. Maintain secrecy surrounding project development!

Quantitative risk assessMent

Probability of failure

• Maturity (Moderate) = .50

• Complexity (Minor) = .30

• Dependency (Moderate) = .50

consequences of failure

• Cost (Significant) = .70

• Schedule (Moderate) = .50

• Reliability (Minor) = .30

• Performance (Moderate) = .50

Pm Pc Pd Pf

.50 .30 .50 .43

Cc Cs Cr Cp Cf

.70 .50 .30 .50 .50

Risk Factor = (.43) + (.50) - (.43)(.50) = .715 (High Risk)

Notes 255

Notes 1. Lallanilla, M. (2013, September 3). “This London skyscraper

can melt cars and set buildings on fire.” www.nbcnews. com/science/science-news/london-skyscraper-can- melt- cars-set-buildings-fire-f8C11069092; Smith-Spark, L. (2013, September 3). “Reflected light from London skyscraper melts car,” CNN. www.cnn.com/2013/09/03/world/europe/uk- london-building-melts-car/; Gower, P. (2014, February 12). “London walkie talkie owners to shield car-melting beam,” Bloomberg. www.bloomberg.com/news/2014-02-12/london- walkie-talkie-owners-to-shield-tower-s-car-melting-beam. html; BBC News Magazine. (2014, September 3). Chris Shepherd, BBC News Magazine, (2014, Sept. 3). “Who, what, why: How does a skyscraper melt a car?” http://www.bbc. com/news/magazine-23944679. Reprinted by permission from BBC Worldwide Americas Inc.

2. Wideman, M. (1998). “Project risk management,” in Pinto, J. K. (Ed.), The Project Management Institute’s Project Management Handbook. San Francisco, CA: Jossey-Bass, pp. 138–58.

3. Chapman, C. B., and Ward, S. C. (1997). Project Risk Management: Process, Techniques, and Insights. Chichester, UK: John Wiley; Kahkonen, K., and Artto, K. A. (1997). Managing Risks in Projects. London: E & FN Spon.

4. Chapman, R. J. (1998). “The effectiveness of working group risk identification and assessment techniques,” International Journal of Project Management, 16(6): 333–44.

5. Martin, P., and Tate, K. (1998). “Team-based risk assess- ment: Turning naysayers and saboteurs into supporters,” PMNetwork, 12(2): 35–38.

6. Scheid, J. (2011, December 5). “Risk management melt- downs: A look at some real-world examples.” www. brighthubpm.com/risk-management/126793-risk- management-meltdowns-a-look-at-some-real-world- examples/; Bernard, T. (2011, November 1). “In retreat, Bank of America cancels debit card fee,” New York Times. www.nytimes.com/2011/11/02/business/bank-of- america-drops-plan-for-debit-card-fee.html?_r=0

7. Hillson, D. (2002a, June). “The risk breakdown struc- ture (RBS) as an aid to effective risk management.” Proceedings of the 5th European Project Management Conference (PMI Europe 2002), Cannes, France.

8. Viswanathan, B. (2012, June 14). “Understanding the risk breakdown structure (RBS),” Project Management.com. http://project-management.com/understanding-the-risk- breakdown-structure-rbs/; Hillson, D. (2002b, October). “Use a risk breakdown structure (RBS) to understand your risks,” Proceedings of the 33rd Project Management Institute Annual Seminars & Symposium, San Antonio, TX.

9. Graves, R. (2000). “Qualitative risk assessment,” PMNetwork, 14(10): 61–66; Pascale, S., Troilo, L., and Lorenz, C. (1998). “Risk analysis: How good are your decisions?” PMNetwork, 12(2): 25–28.

10. “MCA spent millions on Carly Hennessy—Haven’t heard of her?” (2002, February 26). Wall Street Journal, pp. A1, A10.

11. Hamburger, D. H. (1990). “The project manager: Risk taker and contingency planner,” Project Management Journal, 21(4): 11–16; Levine, H. A. (1995). “Risk management for dummies: Managing schedule, cost and technical risk, and contingency,” PMNetwork, 9(10): 31–33.

12. http://blogs.wsj.com/chinarealtime/2009/06/29/shang- hai-building-collapses-nearly-intact/; http://news.bbc.co. uk/2/hi/8123559.stm; Peter Foster (2009, 29 Jun) Nine held over Shanghai building collapse www.telegraph.co.uk/ news/worldnews/asia/china/5685963/Nine-held-over- Shanghai-building-collapse.html.© Telegraph Media Group Limited 2009.

13. Chapman, C. B. (1997). “Project risk analysis and manage- ment—The PRAM generic process,” International Journal of Project Management, 15(5): 273–81; Chapman, C. B., and Ward, S. (2003). Project Risk Management: Processes, Techniques and Insights, 2nd ed. Chichester, UK: John Wiley.

14. Artto, K. A. (1997). “Fifteen years of project risk manage- ment applications—Where are we going?” in Kahkonen, K., and Artto, K. A. (Eds.), Managing Risks in Projects. London: E & FN Spon, pp. 3–14; Williams, T. M. (1995). “A classified bibliography of recent research relating to project risk management,” European Journal of Operations Research, 85: 18–38.

15. The Tragedy of Macbeth: Act I Scene VII: The same. A room in Macbeth’s castle. by William Shakespeare.

16. “Fatigue blamed in Comet crashes.” (1954, October 25). Aviation Week, 61: 17–18; “Comet verdict upholds RAE findings.” (1955, February 21). Aviation Week, 62: 16–17; Hull, S. (1954, November 1). “Comet findings may upset design concepts,” Aviation Week, 61: 16–18; “Fall of a Comet.” (1953, May 11). Newsweek, 41: 49; “A column of smoke.” (1954, January 18). Time, 63: 35–36; “Death of the Comet I.” (1954, April 19). Time, 63: 31–32.

17. Govan, F. (2013, May 22). “£2 billion Spanish navy submarine will sink to bottom of sea,” The Telegraph, www.telegraph. co.uk/news/worldnews/europe/spain/10073951/ 2-billion-Spanish-navy-submarine-will-sink-to-bottom- of-sea.html; El Periodico (2013, May 30). “The most modern Spanish submarine sinks for excess weight,” www.elperiodico.com/es/noticias/politica/problemas- peso-construccion-submarino-ejercito-espanol-2404561; Davis, C. (2013, May 24). “Spain’s S-81 Isaac Peral sub- marine cost $680 million to build . . . and can’t float,” Huffington Post. www.huffingtonpost.com/2013/05/24/ spain-submarine-s-81-isaac-peral-cant-float_n_3328683. html; “GD to help fix Spanish Navy’s overweight issue of S-80 submarine.” (2013, June 7). Naval-Technology.com www.naval-technology.com/news/newsgd-to-help-fix- spanish-navy-overweight-issue-s80-submarine

18. “Big Tacoma Bridge crashes 190 feet into Puget Sound.” (1940, November 8). New York Times, pp. 1, 3.

19. Kharbanda, O. P., and Pinto, J. K. (1996). What Made Gertie Gallup? New York: Van Nostrand Reinhold.

256

8 ■ ■ ■

Cost Estimation and Budgeting

Chapter Outline Project Profile

Sochi Olympics—What’s the Cost of National Prestige?

8.1 cost ManageMent Direct Versus Indirect Costs Recurring Versus Nonrecurring Costs Fixed Versus Variable Costs Normal Versus Expedited Costs

8.2 cost estiMation Learning Curves in Cost Estimation Software Project Estimation—Function Points Problems with Cost Estimation

Project ManageMent research in Brief Software Cost Estimation

Project ManageMent research in Brief “Delusion and Deception” Taking Place in Large Infrastructure Projects

8.3 creating a Project Budget Top-Down Budgeting Bottom-Up Budgeting Activity-Based Costing

8.4 develoPing Budget contingencies Summary Key Terms Solved Problems Discussion Questions Problems Case Study 8.1 The Hidden Costs of Infrastructure

Projects—The Case of Building Dams Case Study 8.2 Boston’s Central Artery/Tunnel Project Internet Exercises PMP Certification Sample Questions Integrated Project—Developing the Cost Estimates

and Budget Notes

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

1. Understand the various types of common project costs. 2. Recognize the difference between various forms of project costs. 3. Apply common forms of cost estimation for project work, including ballpark estimates and

definitive estimates. 4. Understand the advantages of parametric cost estimation and the application of learning curve

models in cost estimation. 5. Discern the various reasons why project cost estimation is often done poorly. 6. Apply both top-down and bottom-up budgeting procedures for cost management. 7. Understand the uses of activity-based budgeting and time-phased budgets for cost estimation

and control. 8. Recognize the appropriateness of applying contingency funds for cost estimation.

Project Profile 257

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Plan Cost Management (PMBoK sec. 7.1) 2. Estimate Costs (PMBoK sec. 7.2) 3. Determine Budget (PMBoK sec. 7.3) 4. Control Costs (PMBoK sec. 7.4)

Project Profile

Sochi olympics—What’s the cost of National Prestige?

The Olympics happen every two years and the focus is usually centered mostly on the athletes, but 2012 proved to be different. Instead, topics of overspending, terroristic threats, graft and corruption in high places, and criminal activities took center stage during these winter games. With an initial budget set at $12 billion, the final price tag on the Sochi Olympics is estimated to have surpassed $51 billion, leaving many people scratching their heads. How could the Winter Games become so expensive and where did all the money go?

Previously, the most expensive games were the 2008 Beijing Summer Olympics. However, at an estimated price tag of $40 billion, that total was still far less than the Sochi Olympics. Summer Olympics are also generally more expensive than the Winter Games due to more events being conducted, the need for venue construction, and the higher housing costs for larger teams. When it comes to hosting the Olympics, it seems that preliminary budgets are quickly abandoned, with higher and higher price tags accruing. Countries view hosting the Olympics as an opportunity to showcase their national achievements, so little effort is made to spare expenses. Even by these standards, the Sochi Olympics set a new standard for profligate spending. Historically, the average budget overspending for Olympics between 1960 and 2012 is 179% in real terms and 324% in nominal terms. The final bill for the Sochi games is far worse than these historical averages.

In 2007, when Russia won the bid to host the Winter Olympics against fellow finalists from South Korea and Austria, it promised to spend $12 billion. Although this figure was reasonable (and perhaps even excessive) at the time, it was quickly overtaken by events involved in developing the Sochi site. The key question: How did the original budget of $12 billion become a final price tag of $51 billion? There are several reasons for the escalating cost of the Sochi Games, including:

1. Although host to the Winter Games, Sochi is actually a subtropical climate. Temperatures average 52 degrees in the winter and 75 degrees in the summer. There are even palm trees in this location. So the majority of the skiing events had to be held in the mountains of Krasnaya Polyana, a distance of about 25 miles from Sochi. The cost of constructing the roadway and infrastructure used to transport athletes and spectators back and forth came to a mind-boggling $9.4 billion. At a price of $220 million per kilometer, the roadway was more expensive than the entire budget of the 2010 Vancouver Winter Olympics.

2. Vladimir Putin, President of Russia, had the goal of developing Sochi as a world-class ski resort in an effort to attract winter tourism to the country. As a result, he was a highly visible spectator throughout the project’s development, offering suggestions and criticisms of the work being done. Rework on several of the venues and facilities added to the final bill.

3. Fears of terrorism and other disruptions led to an unprecedented level of security around the Sochi site. For example, troops from Russia’s Interior Ministry cordoned off the Olympic area to a depth of nearly 20 kilometers to enforce a safe-zone around the Games. The costs of heightened security added significantly to Sochi’s costs.

4. Projects needed to be rebuilt several times due to difficulties with terrain or resource management. For example, state planners did not account for streams that ran beneath the location of the venues. This oversight caused an embankment near Olympic Park to collapse repeatedly due to constant flooding, each time having to be rebuilt. Likewise, construction of the ski jump was budgeted for $40 million. However, because of the complex terrain, the placement had to be adjusted many times. It was also alleged that the necessary geological tests were not conducted before construction started. Trees were removed as needed, leaving several structures constructed on fragile soil that was prone to reoccurring landslides, which caused more rebuilding. In the end, the ski jump was completed, but for $265 million, rather than the initial $40 million estimate.

5. Kickbacks and graft were rumored to be rampant during the years of development, with insiders getting “sweet- heart” deals from the government, and cronyism running rampant.

How bad was the corruption? As journalist Brett Forrest noted: “The Sochi Internal Affairs department has conducted numerous investigations into Olympstroy [the Russian Olympic organizing commission] and filed criminal complaints, alleging that the Olympic agency and its contractors operated a kickback scheme related to the construc- tion of the Olympic stadium, the main hockey rink, and various other properties. The total in stolen funds, according to prosecutors, approaches $800 million.”

(continued)

258 Chapter 8 • Cost Estimation and Budgeting

This may have been only the tip of the iceberg. Besides the speculated kickbacks, a green light was given to all de- velopment schemes around Sochi. Contractors sought to have their projects labeled “Olympic,” knowing that way they would receive generous funding, including easements in zoning and building code regulations. There were also wide- spread allegations of cronyism, as friends and business associates of high-ranking Kremlin officials, including Vladimir Putin, received the choicest contracts. One opposition politician, Boris Nemtsov, criticized the substantial overspending, stating that the total amount embezzled or acquired by Putin’s friends was in the range of $25–$30 billion, or more than half of the total budget for the Olympic Games. Construction companies that won contracts would have to inflate their projected costs in order to make the kickback payments to Russian State managers who had originally awarded the contracts. According to Nemtsov, it did not matter if the construction company had sufficient resources and skills for the project. What mattered was the company’s willingness to return a percentage to the corrupt officials.

Many issues contribute to the reasons why these Olympics became so expensive. Russia had a concept that was budgeted at $12 billion when it started its preparations. History shows most nations exceed their budgets, though not to the excessive degree experienced by Russia in 2014. Ultimately, though, time is a relentless enemy of Olympic venue preparation; there is no possibility of extensions to the schedule. As a result, with the time moving closer to the open- ing of the Games, no expense could be (or was) spared in getting Sochi ready. Without question, enormous (and prob- ably unknowable) sums disappeared to corruption and mismanagement. Nevertheless, the Sochi Games came on time and delivered a smoothly running experience to all who participated or came to watch. And yet, at a final price tag of $51 billion, one can still wonder about the costs of maintaining and enhancing national prestige.1

The price of modern Olympic games

Price per event

Beijing 2008 Sochi 2014

If indirect costs of Beijing Olympics are included,

the event cost the Chinese $43 billion. However,

Beijing hosted 302 events, whereas Sochi will host 98.

Analysis of sports-related costs for games between 1960 and 2014

Initial budget Budget overrun

Sochi1 2014 London 2012

Vancouver 2010

Beijing 2008

Torino 2006

Athens 2004

Salt Lake City 2002

Sydney 2000

$142 million

$520 million

Nagano 1998

Atlanta 1996

Lillehammer 1994

Barcelona 1992

Albertville 1992

Calgary 1988

Lake Placid 1980

Montreal 1976

Grenoble 1968

0 10

Billions ($)2 1Estimate includes indirect costs. 2Cost adjusted to USD2009, except for Sochi.

20

Data: International Olympic Committee, Time Inc.

Bent Flyvbjerg & Allison Stewart, University of OxfordAkshat Rathi | theconversation.com

30 40 50

Summer

Winter

Figure 8.1 Sochi Winter olympics costs

Source: B. Flyvbjerg and A Stewart. (2012). “Olympic proportions: Cost and cost overrun at the Olympics 1960–2012.” Said Business School Working Papers, Oxford: University of Oxford.

8.1 Cost Management 259

8.1 Cost ManageMent

Cost management is extremely important for running successful projects. The management of costs, in many ways, reflects the project organization’s strategic goals, mission statement, and business plan. Cost management has been defined to encompass data collection, cost accounting, and cost control,2 and it involves taking financial-report information and applying it to projects at finite levels of accountability in order to maintain a clear sense of money management for the project.3 Cost accounting and cost control serve as the chief mechanisms for identifying and main- taining control over project costs.

Cost estimation is a natural first step in determining whether or not a project is viable; that is, can the project be done profitably? cost estimation processes create a reasonable budget baseline for the project and identify project resources (human and material) as well, creating a time-phased budget for their involvement in the project. In this way, cost estimation and project budgeting are linked hand in hand: The estimates of costs for various components of the project are developed into a comprehensive project budgeting document that allows for ongoing project tracking and cost control.

During the development stage of the proposal, the project contractor begins cost estimation by identifying all possible costs associated with the project and building them into the initial pro- posal. While a simplified model of cost estimation might only require a bottom-line final figure, most customers will wish to see a higher level of detail in how the project has been priced out, that is, an itemization of all relevant costs. For example, a builder could simply submit to a potential home buyer a price sheet that lists only the total cost of building the house, but it is likely that the buyer will ask for some breakdown of the price to identify what costs will be incurred where. Some of the more common sources of project costs include:

1. Labor—Labor costs are those associated with hiring and paying the various personnel involved in developing the project. These costs can become complex, as a project requires the services of various classifications of workers (skilled, semiskilled, laborers) over time. At a minimum, a project cost estimation must consider the personnel to be employed, salary and hourly rates, and any overhead issues such as pension or health benefits. A preliminary estimate of workers’ exposure to the project in terms of hours committed is also needed for a reasonable initial estimate of personnel costs.

2. Materials—Materials costs apply to the specific equipment and supplies the project team will require in order to complete project tasks. For building projects, materials costs are quite large and run the gamut from wood, siding, insulation, and paint to shrubbery and paving. For many other projects, the actual materials costs may be relatively small, for example, the purchase of a software package that allows rapid compiling of computer code. Likewise, many projects in the service industries may involve little or no materials costs whatsoever. Some materials costs can be charged against general company overhead; for example, the use of the firm’s mainframe computer may be charged to the project on an “as used” basis.

3. Subcontractors—When subcontractors provide resources (and in the case of consultants, expertise) for the project, their costs must be factored into the preliminary cost estimate for the project and be reflected in its budget. One subcontractor cost, for example, could be a charge to hire a marketing communications professional to design the project’s promotional mate- rial; another might be costs for an industrial designer to create attractive product packaging.

4. Equipment and facilities—Projects may be developed away from the firm’s home office, requiring members of the project team to work “off site.” Firms commonly include rental of equipment or office facilities as a charge against the cost of the project. For example, oil com- panies routinely send four- or five-person site teams to work at the headquarters of major subcontractors for extended periods. The rental of any equipment or facility space becomes a cost against the project.

5. Travel—If necessary, expenses that are related to business travel (car rentals, airfare, hotels, and meals) can be applied to the project as an up-front charge.

Another way to examine project costs is to investigate the nature of the costs themselves. Among the various forms of project costs are those related to type (direct or indirect), frequency of occurrence (recurring or nonrecurring), opportunity to be adjusted (fixed or variable), and schedule (normal or expedited). We will examine each of these types of project costs in turn in this chapter.

260 Chapter 8 • Cost Estimation and Budgeting

Direct Versus indirect Costs

direct costs are those clearly assigned to the aspect of the project that generated the cost. Labor and materials may be the best examples. All labor costs associated with the workers who actually build a house are considered direct costs. Some labor costs, however, might not be viewed as direct costs for the project. For example, the costs of support personnel, such as the project’s cost accoun- tant or other project management resources, may not be allocated directly, particularly when their duties consist of servicing or overseeing multiple, simultaneous projects. In a nonproject setting such as manufacturing, it is common for workers to be assigned to specific machinery that oper- ates on certain aspects of the fabrication or production process. In this case, labor costs are directly charged against work orders for specific parts or activities.

The formula for determining total direct labor costs for a project is straightforward:

Total direct labor costs = (Direct labor rate) (Total labor hours)

The direct costs of materials are likewise relatively easy to calculate, as long as there is a clear understanding of what materials are necessary to complete the project. For example, the direct costs of building a bridge or hosting a conference dinner for 300 guests can be estimated with fair accuracy. These costs can be applied directly to the project in a systematic way; for example, all project purchase orders (POs) can be recorded upon receipt of bills of materials or sales and applied to the project as a direct cost.

indirect costs, on the other hand, generally are linked to two features: overhead, and sell- ing and general administration. Overhead costs are perhaps the most common form of indirect costs and can be one of the more complex forms in estimating. Overhead costs include all sources of indirect materials, utilities, taxes, insurance, property and repairs, depreciation on equipment, and health and retirement benefits for the labor force. Common costs that fall into the selling and general administration category include advertising, shipping, salaries, sales and secretarial sup- port, sales commissions, and similar costs. Tracing and linking these costs to projects is not nearly as straightforward as applying direct costs, and the procedures used vary by organization. Some organizations charge a flat rate for all overhead costs, relative to the direct costs of the project. For example, some universities that conduct research projects for the federal government use a percentage multiplier to add administrative and overhead indirect costs to the proposal. The most common range for such indirect multiplier rates is from 20% to over 50% on top of direct costs. Other firms allocate indirect costs project by project, based on individual analysis. Whichever approach is preferred, it is important to emphasize that all project cost estimates include both direct and indirect cost allocations.

exaMple 8.1 Developing Fully Loaded Labor Costs

Suppose that we are attempting to develop reasonable cost estimation for the use of a senior pro- grammer for a software project. The programmer is paid an annual salary of $75,000, which trans- lates to an hourly rate of approximately $37.50/hour. The programmer’s involvement in the new project is expected to be 80 hours over the project’s life. Remember, however, that we also need to consider overhead charges. For example, the company pays comprehensive health benefits and retirement, charges the use of plant and equipment against the project, and so forth. In order to cover these indirect costs, the firm uses an overhead multiplier of 65%. Employing an overhead multiplier is sometimes referred to as the fully loaded rate for direct labor costs. Thus, the most ac- curate calculation of the programmer’s charge against the project would look like this:

Hourly rate Hours needed Overhead charge Fully loaded labor cost ($37.50)

* (80)

* (1.65) = $4,950

Some have argued that a more realistic estimate of fully loaded labor costs for each person assigned to the project would reflect the fact that no one truly works a full 8-hour day as part of the job. An allowance for a reasonable degree of personal time during the workday is simply recogni- tion of the need to make personal calls, have coffee breaks, walk the hallways to the restroom, and so forth. Meredith and Mantel (2003) have argued that if such personal time is not included in the

8.1 Cost Management 261

original total labor cost estimate, a multiplier of 1.12 should be used to reflect this charge, increas- ing the fully loaded labor cost of our senior programmer to:4

Hours Overhead Personal Hourly rate * needed * charge * Time =

($37.50) (80) (1.65) (1.12)

Fully loaded labor cost

$5,544

One other point to consider regarding the use of overhead (indirect costs) involves the manner in which overhead may be differentially applied across job categories. In some firms, for example, a distinction is made between salaried and nonsalaried employees. Thus, two or more levels of overhead percentage may be used, depending upon the category of personnel to which they are applied. Suppose that a company applied a lower overhead rate (35%) to hourly workers, reflect- ing the lesser need for contributions to retirement or health insurance. The calculated fully loaded labor cost for these personnel (even assuming a charge for personal time) would resemble the following:

Hours Overhead Personal Hourly rate * needed * charge * Times =

($12.00) (80) (1.35) (1.12)

Fully loaded labor cost $1,451.52

The decision to include personal time requires input from the project’s client. Whichever approach is taken, a preliminary total labor cost budget table can be constructed when the process is completed, as shown in Table 8.1. This table assumes a small project with only five project team personnel, whose direct labor costs are to be charged against the project without a personal time charge included.

recurring Versus nonrecurring Costs

Costs can also be examined in terms of the frequency with which they occur; they can be recurring or nonrecurring. nonrecurring costs might be those associated with charges applied once at the beginning or end of the project, such as preliminary marketing analysis, personnel training, or out- placement services. recurring costs are those that typically continue to operate over the project’s life cycle. Most labor, material, logistics, and sales costs are considered recurring because some budgetary charge is applied against them throughout significant portions of the project devel- opment cycle. In budget management and cost estimation, it is necessary to highlight recurring versus nonrecurring charges. As we will see, this becomes particularly important as we begin to develop time-phased budgets—those budgets that apply the project’s baseline schedule to pro- jected project expenditures.

Fixed Versus Variable Costs

An alternative designation for applying project costs is to identify fixed and variable costs in the project budget. fixed costs, as their title suggests, do not vary with respect to their usage.5 For example, when leasing capital equipment or other project hardware, the leasing price is likely not

table 8.1 Preliminary cost estimation for fully loaded labor

Personnel title Salary (Hourly) Hours Needed overhead rate Applied

fully loaded labor cost

Linda Lead Architect $35/hr 250 1.60 $14,000.00 Alex Drafter—Junior $20/hr 100 1.60 3,200.00 Jessica Designer—Intern $8.50/hr 80 1.30 884.00 Todd Engineer—Senior $27.50/hr 160 1.60 7,040.00 Thomas Foreman $18.50/hr 150 1.30 3,607.50 Total $28,731.50

262 Chapter 8 • Cost Estimation and Budgeting

to go up or down with the amount of usage the equipment receives. Whether a machine is used for 5 hours or 50, the cost of its rental is the same. When entering fixed-rate contracts for equip- ment, a common decision point for managers is whether the equipment will be used sufficiently to justify its cost. variable costs are those that accelerate or increase through usage; that is, the cost is in direct proportion to the usage level. Suppose, for example, we used an expensive piece of drill- ing equipment for a mining operation. The equipment degrades significantly as a result of use in a particularly difficult geographical location. In this case, the variable costs of the machinery are in direct proportion to its use. It is common, in many cases, for projects to have a number of costs that are based on fixed rates and others that are variable and subject to significant fluctuations either upward or downward.

normal Versus expedited Costs

normal costs refer to those incurred in the routine process of working to complete the project according to the original, planned schedule agreed to by all project stakeholders at the beginning of the project. Certainly, this planned schedule may be very aggressive, involving extensive over- time charges in order to meet the accelerated schedule; nevertheless, these costs are based on the baseline project plan. expedited costs are unplanned costs incurred when steps are taken to speed up the project’s completion. For example, suppose the project has fallen behind schedule and the decision is made to “crash” certain project activities in the hopes of regaining lost time. Among the crashing costs could be expanded use of overtime, hiring additional temporary workers, contract- ing with external resources or organizations for support, and incurring higher costs for transporta- tion or logistics in speeding up materials deliveries.

All of the above methods for classifying costs are linked together in Table 8.2.6 Across the top rows are the various classification schemes, based on cost type, frequency, adjustment, and schedule. The left-side column indicates some examples of costs incurred in develop- ing a project. Here we see how costs typically relate to multiple classification schemes; for example, direct labor is seen as a direct cost, which is also recurring, fixed, and normal. A building lease, on the other hand, may be classified as an indirect (or overhead) cost, which is recurring, fixed, and normal. In this way, it is possible to apply most project costs to multiple classifications.

8.2 Cost estiMation

Estimating project costs is a challenging process that can resemble an art form as much as a science. Two important project principles that can almost be called laws are at work in cost estimation. First, the more clearly you define the project’s various costs in the beginning, the less chance there is of making estimating errors. Second, the more accurate your initial cost estimations, the greater the likelihood of preparing a project budget that accurately reflects reality for the project and the greater your chances of completing the project within budget estimates.

One key for developing project cost estimates is to first recognize the need to cost out the project on a disaggregated basis; that is, to break the project down by deliverable and work pack- age as a method for estimating task-level costs. For example, rather than attempt to create a cost estimate for completing a deliverable of four work packages, it is typically more accurate to first identify the costs for completing each work package individually and then create a deliverable cost estimate, as Table 8.3 illustrates.

table 8.2 cost classifications

type frequency Adjustment Schedule

costs Direct indirect recurring Nonrecurring fixed Variable Normal expedited

Direct Labor X X X X Building Lease X X X X Expediting Costs X X X X Material X X X X

8.2 Cost Estimation 263

Companies use a number of methods to estimate project costs, ranging from the highly tech- nical and quantitative to the more qualitative approaches. Among the more common cost estima- tion methods are the following:7

1. Ballpark estimates—Sometimes referred to as order of magnitude estimates, ballpark esti- mates are typically used when either information or time is scarce. Companies often use them as preliminary estimates for resource requirements or to determine if a competitive bid can be attempted for a project contract. For example, a client may file an RFQ (request for quote) for competitive bids on a project, stating a very short deadline. Managers would have little time to make a completely accurate assessment of the firm’s qualifications or requirements, but they could still request ballpark estimates from their personnel to deter- mine if they should even attempt to bid the proposal through a more detailed analysis. The unofficial rule of thumb for ballpark estimates is to aim for an accuracy of ±30%. With such a wide variance plus or minus, it should be clear that ballpark estimates are not intended to substitute for more informed and detailed cost estimation.

2. comparative estimates—Comparative estimates are based on the assumption that histori- cal data can be used as a frame of reference for current estimates on similar projects. For example, Boeing Corporation routinely employs a process known as parametric estimation, in which managers develop detailed estimates of current projects by taking older work and inserting a multiplier to account for the impact of inflation, labor and materials increases, and other reasonable direct costs. This parametric estimate, when carefully performed, allows Boeing to create highly accurate estimates when costing out the work and preparing detailed budgets for new aircraft development projects. Even in cases where the technology is new or represents a significant upgrade over old technologies, it is often possible to gain valuable insight into the probable costs of development, based on historical examples.

Boeing is not the only firm that has successfully employed parametric cost estimation. Figure 8.2 shows a data graph of the parametric estimation relating to development of the Concorde aircraft in the 1960s. The Concorde represented such a unique and innovative air- frame design that it was difficult to estimate the amount of design time required to complete the schematics for the airplane. However, using parametric estimation and based on experi- ences with other recently developed aircraft, a linear relationship was discovered between the number of fully staffed weeks (Concorde referred to this time as “manweeks”) needed to design the aircraft and its projected cruising speed. That is, the figure demonstrated a direct relationship between the cruising speed of the aircraft and the amount of design time neces- sary to complete the schematics. Using these values, it was possible to make a reasonably accurate cost projection of the expected budget for design, demonstrating that in spite of sig- nificant changes in airplane design over the past decades, the relationship between cruising speed and design effort had held remarkably steady.

Effective comparative estimates depend upon some important supplementary sources including a history of similar projects and a detailed archive of project data that includes the technical, budgetary, and other cost information. Adjusting costs to account for inflation simply becomes a necessary step in the process. The key to making com- parative estimates meaningful lies in the comparability to previous project work. It makes little sense to compare direct labor costs for two projects when the original was done in a foreign country with different wage rates, overhead requirements, and so forth. Although some argue that comparative cost estimation cannot achieve a degree of accuracy closer

table 8.3 Disaggregating Project Activities to create reasonable cost estimates

Project Activities estimated cost

Deliverable 1040—Site Preparation Work Package 1041—Surveying $ 3,000 Work Package 1042—Utility line installation 15,000 Work Package 1043—Site clearing 8,000 Work Package 1044—Debris removal 3,500 Total cost for Deliverable 1040 $29,500

264 Chapter 8 • Cost Estimation and Budgeting

than ;15%, in some circumstances the estimate may be much more accurate and useful than that figure indicates.

3. feasibility estimates—These estimates are based as a guideline on real numbers, or figures derived after the completion of the preliminary project design work. Following initial scope development, it is possible to request quotes from suppliers and other subcontractors with a greater degree of confidence, particularly as it is common to engage in some general sched- uling processes to begin to determine the working project baseline. Feasibility estimates are routinely used for construction projects, where there are published materials cost tables that can give reasonably accurate cost estimates for a wide range of project activities based on an estimate of the quantities involved. Because they are developed farther down the life cycle, feasibility estimates are often expressed in terms of a degree of accuracy of ;10%.

4. definitive estimates—These estimates can be given only upon the completion of most design work, at a point when the scope and capabilities of the project are quite well understood. At this point all major purchase orders have been submitted based on known prices and availabilities, there is little or no wiggle room in the project’s specifications, and the steps to project completion have been identified and a comprehensive project plan is in place. Because it is understood that cost estimation should naturally improve with time, as more information becomes available and fewer project unknowns remain unresolved, definitive estimates should accurately reflect the expected cost of the proj- ect, barring unforeseen circumstances, at completion. Hence, definitive estimates can be expected to have an accuracy of ;5%. We saw in previous chapters that some projects may offer very thin profit margins; for example, in the case of fixed-cost contracts, the project organization assumes almost all risk for completing the project according to origi- nally agreed-on contract terms. As a result, the better the job we do in estimating costs, the more likely we will be to maintain the profit margin contracted.

Design manweeks to first service (thousands) per passenger

20

10 8

6

4

2

1 0.8

0.6

0.4

0.2

0.1 0.08 0.06

0.04

0.02

0.01

10 20

Cruising speed (kts)

40 60 80 100 200 400

de Havilland DH 4

Junkers Ju 52/3m

Douglas DC-3

Douglas DC-6

Boeing 707

Boeing 747

BAC-SNIAS Concorde

Fokker VII

600 1000 2000

Figure 8.2 Parametric estimate for Design costs for concorde

Note: Plot of design effort versus cruising speed for significant commercial aircraft types.

8.2 Cost Estimation 265

Which cost estimation approach should a project organization employ? The answer to this question presupposes knowledge of the firm’s industry (e.g., software development vs. construc- tion), ability to account for and manage most project cost variables, the firm’s history of success- ful project management, the number of similar projects the firm has completed in the past, the knowledge and resourcefulness of project managers, and the company’s budgeting requirements. In some instances (e.g., extremely innovative research and development projects), it may be impos- sible to create cost estimates with more than a ±20% degree of accuracy. On the other hand, in some projects such as events management (e.g., managing a conference and banquet), it may be reasonable to prepare definitive budgets quite early in the project. For example, while cost estima- tion can involve significant calculations and some amount of guesswork for certain types of proj- ects, in other cases, project managers and cost estimators are able to calculate project costs with a much greater degree of accuracy. Many construction projects, particularly in standard residential and commercial building, employ estimates based on relatively stable historical data that makes it much easier to determine costs with good accuracy. To illustrate, Internet sites such as RSMeans. com, developed by Reed Construction Data, or CostDataOnLine.com include building cost cal- culators that are able to predict construction costs (including assumptions about labor rates, cost of living adjustments for location, square footage, type of building) with a reasonable degree of accuracy (see Figure 8.3).

RSMeans QuickCost Estimator

Project Title:

Model:

Construction:

Location:

Stories:

Story Height (I.f.):

Floor Area (s.f.):

Data Release:

Wage Rate:

Basement:

Do You Need a More Comprehensive Estimate With Current Cost Data and Your Own Detailed Project Specifications?

[click here to view a sample report]

Access the Custom Cost Estimator, a paid subscription service, to reference a comprehensive library of square foot models updated

and localized for the United States to create a customized online estimate specific to your individual project! - All from RSMeans,

These costs are not exact and are intended only as a preliminary guide to possible project cost. Actual project cost may vary greatly

depending on many factors. RSMeans uses diligence in preparing the information contained here. RSMeans does not make any warranty or guarantee as to the

accuracy, correctness, value, sufficiency or completeness of the data or resulting project cost estimates. RSMeans shall have no liability for any loss, expense or damage arising out of or in connection with the information contained herein.

Costs are derived from a building model with basic components. Scope differences and market conditions can cause costs to vary significantly.

Sample Project

Apartment, 1-3 Story

Face Brick with Concrete Block Back-up/Wood Joists

VANCOUVER, BC

3

10

2,500

Year 2012 Quarter 3

Union

Not included

Cost Ranges

Total:

Contractor’s Overhead & Profit:

Architectural Fees:

Total Building Cost:

$826,650

$206,550

$82,800

$1,116,000

$918,500

$229,500

$92,000

$1,240,000

$1,148,125

$286,875

$115,000

$1,550,000

Low Med High

Figure 8.3 Sample cost estimator Using rSMeans.com Web Site

Source: Copyright RSMeans 2014- RSMeans Square Foot Models www.rsmeans.com/ estimator/qce/qce_result.asp

266 Chapter 8 • Cost Estimation and Budgeting

The key to cost estimation lies in a realistic appraisal of the type of project one is undertaking, the speed with which various cost estimates must be created, and the comfort level top manage- ment has with cost estimation error. If the information is available, it is reasonable to expect the project team to provide as accurate a cost estimate as possible, as early in the project as possible. Figure 8.4 shows a sample project cost estimation form.

learning Curves in Cost estimation

Cost estimation, particularly for labor hours, often takes as its assumption a steady or uniform rate at which work is done. In the case of having to perform multiple activities, the amount of time necessary to complete the first activity is not significantly different from the time necessary

ESTIMATE AND QUOTATION SHEET

Project No. Description: Type No.

Work Package No. Task No. Estimate No.

Work Package Description:

Task Description:

Internal Labor

Skill Category Rate Hours Cost

Senior Test Engineer TE4 18.50 40 $ 740.00

Test Engineer TE3 14.00 80 1,120.00

Fitter PF4 13.30 30 399.00

Drafter DR2 15.00 15 225.00

Drawing Checker DR3 16.50 3 49.50

Subtotal, Hours and Costs 168 $2,533.50

Labor Contingency (10%) 17 254.00

Total Labor, Hours and Costs 185 $2,787.50

Overhead (80%) 2,230.00

Gross Labor Cost $5,017.50

Bought-Out Costs

Materials (Specify): Bolts plus cleating material $ 20.00

Finished Goods (Specify): N/A

Services and Facilities: Hire test house; instrumentation plus report

12,300.00

Subcontract Manufacture (Specify): Fixture and bolt modification 250.00

Subtotal $12,570.00

Contingency (15%) 1,885.50

Total Bought-Out Costs $14,455.50

Expenses

Specify: On-site accommodation plus traveling $ 340.00

Total Bought-Out Costs and Expenses $14,795.50

Profit %: N/A

Total Quoted Sum: Gross Labor plus Bought-Out Costs and Expenses $19,813.00

Compiled by:

Approved: Date

Figure 8.4 Sample Project Activity cost estimating Sheet

8.2 Cost Estimation 267

to complete the nth activity. For example, in software development, it may be considered standard practice to estimate each activity cost independently of other, related activities with which the programmer is involved. Therefore, in the case of a programmer required to complete four work assignments, each involving similar but different coding activities, many cost estimators will sim- ply apply a direct, multiplicative rule-of-thumb estimate:

Number of times Cost of activity * activity is repeated =

($8,000) (4) Total cost estimate

$32,000

When we calculate that each actual coding sequence is likely to take approximately 40 hours of work, we can create the more formal direct cost budget line for this resource. Assuming an over- head rate of .60 and a cost per hour for the programmer’s services of $35/hour, we can come up with a direct billing charge of:

Wage Unit Overhead Rate Hours/Unit ($35/hr)

* (4 iterations)

* (1.60)

* (40 hours) =

$8,960

Although this rule of thumb is simple, it may also be simplistic. For example, is it reasonable to suppose that in performing similar activities, the time necessary to do a coding routine the fourth time will take as long as it took to do it the first time? Or is it more reasonable to suppose that the time needed (and hence, cost) of the fourth iteration should be somewhat shorter than the earlier times?

These questions go to the heart of a discussion of how learning curves affect project cost estimation.8 In short, experience and common sense teach us that repetition of activities often leads to reduction in the time necessary to complete the activity over time. Some research, in fact, supports the idea that performance improves by a fixed percentage each time produc- tion doubles.9

Let us assume, for example, that the time necessary to code a particular software routine is estimated at 20 hours of work for the first iteration. Doing the coding work a second time requires only 15 hours. The difference between the first and second iteration suggests a learning rate of .75 (15/20). We can now apply that figure to estimates of cost for additional coding iterations. When output is doubled from the first two routines to the required four, the time needed to complete the fourth unit is now estimated to take:

15 hrs. (.75) = 11.25 hours

These time and cost estimates follow a well-defined formula,10 which is the time required to produce the steady state unit of output, and is represented as:

Yx = aX b

where Yx = the time required for the steady state, x, unit of output

a = the time required for the initial unit of output X = the number of units to be produced to reach the steady state b = the slope of the learning curve, represented as: log decimal learning rate/log 2

Assume the need to conduct a project cost estimation in the case of construction, where one resource will be tasked to perform multiple iterations of a similar nature (e.g., fitting, riveting, and squaring). The worker must do a total of 15 of these activities to reach the steady state. Also assume that the time estimated to perform the last iteration (the steady state) is 1 hour, and we know from past experience the learning rate for this highly repetitive activ- ity is .60. In calculating the time necessary to complete the first activity, we would apply

268 Chapter 8 • Cost Estimation and Budgeting

these  values to the formula to determine the value of a, the time needed to complete the task the first time:

b = log 0.60/log 2 = - 0.2219/0.31 = - 0.737

1 hr. = a(15)-0.737

a = 7.358 hours

Note that the difference between the first and fifteenth iteration of this activity represents a change in duration estimation (and therefore, cost) from over 7 hours for the first time the task is per- formed to 1 hour for the steady state. The difference this learning curve factor makes in project cost estimates can be significant, particularly when a project involves many instances of repetitive work or large “production runs” of similar activities.

exaMple 8.2 Learning Curve Estimates

Let’s return to the earlier example where we are trying to determine the true cost for the senior programmer’s time. Recall that the first, linear estimate, in which no allowance was made for the learning curve effect, was found to be:

($35/hr) (4 iterations) (1.60) (40 hours) = $8,960

Now we can apply some additional information to this cost estimate in the form of better knowl- edge of learning-rate effects. Suppose, for example, that the programmer’s learning rate for coding is found to be .90. The steady state time to code the sequence is 40 hours. Our estimate of the time needed for the first coding iteration is:

b = log 0.90/log 2 = - 0.0458/0.301 = - 0.1521

40 hrs. = a(4)-0.1521

a = 49.39 hours

Thus, the first unit would take 9.39 hours longer than the steady state 40 hours. For this programming example, we can determine the appropriate unit and total time multipliers for the calculated initial unit time by consulting tables of learning curve coefficients (multipliers) derived from the formula with a = 1. We can also calculate unit and total time multipliers by identifying the unit time multipli- ers from 1 to 3 units of production (coding sequences) with a learning rate of .90. We use the units 1 to 3 because we assume that by the fourth iteration, the programmer has reached the steady state time of 40 hours. Based on a = 1, the unit time learning curve coefficients are 1-0.5121 = 1, 2-0.1521 = 0.90, and 3-0.1521 = .846, for a total time multiplier of 2.746. Therefore, the time needed to code the first three sequences is:

Total time Time required Total time to program multiplier * for initial unit = first three sequences

(2.746) (49.39) 135.62 hours

8.2 Cost Estimation 269

Because the steady state time of 40 hours occurs for the final coding iteration, total coding time required for all four sequences is given as:

135.62 + 40 = 175.62

The more accurate direct labor cost for the coding activities is:

Wage *

Overhead Rate *

Total Hours ($35/hr) (1.60) (175.62 hours) =

$9,834.72

Compare this figure to the original value of $8,960 we had calculated the first time, which understated the programming cost by $874.72. The second figure, which includes an allowance for learning curve effects, represents a more realistic estimate of the time and cost required for the programmer to complete the project activities.

In some industries it is actually possible to chart the cost of repetitive activities to accurately adjust cost estimation for learning curves. Note the curve relating time (or cost) against activity rep- etition shown in Figure 8.5.11 The learning curve effect here shows savings in time as a function of the sheer repetition of activities found in many projects. Some operations management books offer tables that show the total time multiplier, based on the learning rate values multiplied by the number of repetitive iterations of an activity.12 Using these multipliers, the savings in revising cost estimates downward to account for learning curve effects can be significant. However, there is one important caveat: Learning curve effects may occur differentially across projects; projects with redundant work may allow for the use of learning curve multipliers while other projects with more varied work will not. Likewise, it may be more likely to see learning curve effects apply in greater proportion to proj- ects in some industries (say, for example, construction) than in others (such as research and develop- ment). Ultimately, project budgets must be adjusted for activities in which learning curve effects are likely to occur, and these effects must be factored into activity cost estimates.

Increasingly, project contracts are coming to reflect the impact of learning curves for repetitive operations. For example, in the automotive industry, the manufacturer of hydraulic cylinders may be given a contract for the first year to provide cylinders at a price of $24 each. Each year after, the cost of the cylinder sold to the automobile maker is priced at $1 less per year, under the assumption that learning curves will allow the cylinder manufacturer to produce the product at a steadily lower cost. Thus, learning curves are factored into the value of long-term contracts.13

50

40

30

20

10

0 0 20 40

Repetition

T im

e (

C o

s t)

60 80 100

Figure 8.5 Unit learning curve log-linear Model

Source: J. P. Amor and C. J. Teplitz. (1998). “An efficient approximation for project composite learning curves,” Project Management Journal, 29(3), pp. 28–42, figure on page 36. Copyright © 1998 by Project Management Institute Publications. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

Note: Graph on arithmetic coordinates.

270 Chapter 8 • Cost Estimation and Budgeting

software project estimation—Function points

Evidence from Chapter 1 and Box 8.1 (Software Cost Estimation) highlights the difficulties in developing realistic estimates for large-scale software projects. The track record is not encourag- ing: More and more software projects are overshooting their schedule and cost estimates, often by significant amounts. One of the reasons is simply due to the nature of uncertainty in these projects. We can make estimates of cost, but without a clear sense of the nature of the software,

Box 8.1

Project Management research in Brief

Software Cost Estimation

The software project industry has developed a notorious reputation when it comes to project performance. Past research by the Standish Group14 found that for large companies, less than 9% of IT projects are com- pleted on schedule and at budget. Over 50% of these projects will cost 189% of their original budget, while the average schedule overrun is 202%. A recent study of 5,400 IT projects conducted by McKinsey and Company and Oxford University found that on average, large IT projects run 45% over budget and 7% over time while delivering 56% less value than predicted. In fact, 17% of IT projects are such a disaster that they can threaten the very existence of the company.15 Clearly, from both cost and schedule estimation per- spectives, the industry is frustrated by unrealistic expectations. In spite of recent improvements in software development cost, schedule, and effort estimation, using Constructive Cost Estimating models (COCOMO II), required by several branches of the federal government when bidding software contracts, our lack of ability to accurately predict software project costs remains a serious concern.16

A book by Steven McConnell, president of Construx Software,17 sheds light on some of the key reasons why software projects suffer from such a poor track record. Among his findings is the common failure to bud- get adequate time and funding for project activities that are likely to vary dramatically, depending upon the size of the project. He distinguished among six software project activities: (1) architecture, (2) detailed design, (3) coding and debugging, (4) developer testing, (5) integration, and (6) system testing. McConnell deter- mined that for small IT projects of 2,000 lines of code or less, 80% of the project work consisted of just three activities: detailed design, coding and debugging, and unit testing (see Figure 8.6). However, as the complexity of the software projects increased, the proportion of these activities to the overall project cost dropped dra- matically. Projects of over 128,000 lines of code required significantly more attention to be paid to the other three activities: architecture, integration, and system testing (about 60% of total effort).

The implications of this research suggest that IT project budgets must consider the size of the project as they calculate the costs of each component (work package). Larger projects resulting in hundreds of thou- sands of lines of code require that a higher proportion of the budget be allocated to software architecture and testing, relative to the actual cost of construction (design, coding, and unit testing).

System testing

Unit testing

Coding and debugging

Detailed design

100%

0% 2K 8K 32K 128K 512K

Integration

Construction

Project Size in Lines of Code

Percentage of Development

Time

Architecture

Figure 8.6 Software Project Development Activities as a function of Size

Source: From Code Complete, 2d ed. (Microsoft Press, 2004), by Steve McConnell. Used with permission of the author.

8.2 Cost Estimation 271

the size of the program, and its functionality, these are often just best guesses and are quickly found to be inadequate.

function point analysis is a system for estimating the size of software projects based on what the software does. To build any system, you need time to create files that hold informa- tion and interfaces to other screens (files and interfaces). You also need to create input screens (inputs), enquiry screens (queries), and reports (outputs). If you count all the files, interfaces, inputs, queries, and outputs, you can begin estimating the amount of work to be undertaken. The measure then relates directly to the business requirements that the software is intended to address. It can therefore be readily applied across a wide range of development environments and throughout the life of a development project, from early requirements definition to full operational use.

Simply stated, function points are a standard unit of measure that represents the functional size of a software application. In the same way that a house is measured by the square feet it pro- vides, the size of an application can be measured by the number of function points it delivers to the users of the application. As part of that explanation, it is critically important to recognize that the size of the application being measured is based on the user’s view of the system. It is based on what the user asked for, not what is delivered. Further, it is based on the way the user interacts with the system, including the screens that the user accesses to enter input, and the reports the user receives as output.

We know that it takes different amounts of time to build different functions; for example, it  may take twice as long to build an interface table as an input table. Once we have a general sense of the relative times for each of the functions of the system, we have to consider additional factors to weight these estimates. These factor weightings are based on “technical complexity” and “environmental complexity.” Technical complexity assesses the sophistication of the application to be built. Are we developing a complex model to determine the multiple paths of geosynchro- nous orbiting satellites or are we simply creating a database of customer names and addresses? Environmental complexity considers the nature of the setting in which the system is designed to work. Will it support a single user on one PC or a wide-area network? What computer language will the application be written in? A relatively streamlined and commonplace language such as Visual Basic requires less work than a more complex language and, consequently, we would assume that programmers could be more productive (generate more function points). These func- tion points are adjusted for such complexity factors and then summed to determine a reasonable cost estimate for developing the software system.

Let’s take a simple example: Suppose a local restaurant commissioned our firm to develop a replenishment and ordering system to ensure that minimum levels of foods and beverages are maintained at all times. The restaurant wants the application to have a reasonable number of input screens, output screens, a small number of query options and interfaces, but large and detailed report generation capabilities. Further, we know from past experience that one program- mer working for one month (a “person-month”) at our firm can generate an average of 10 function points. Finally, based on our company’s past history, we have a set of average system technical and environmental complexity weightings that we can apply across all functions (see Table 8.4). For example, we know that in building an input function for the application, a system with high complexity is approximately three times more complicated (and requires more effort) than one with low complexity.

table 8.4 complexity Weighting table for function Point Analysis

complexity Weighting

function low Medium High total

Number of Inputs 2 : ____ = 4 : ____ = 6 : ____ = Number of Outputs 4 : ____ = 6 : ____ = 10 : ____ = Number of Interfaces 3 : ____ = 7 : ____ = 12 : ____ = Number of Queries 5 : ____ = 10 : ____ = 15 : ____ = Number of Files 2 : ____ = 4 : ____ = 8 : ____ =

272 Chapter 8 • Cost Estimation and Budgeting

With this information, we can apply the specific system requirements from the client to construct a function point estimate for the project. Suppose we determined (from our interviews with the restaurant owners) that the estimate for relative complexity was inputs (medium), out- puts (high), interfaces (low), queries (medium), and files (low). Further, we know that the clients require the following number of each function: input screens (15), output screens (20), interfaces (3), queries (6), and report files (40). We can combine this information with our historic weightings for complexity to create Table 8.5.

Table 8.5 shows the results of combining our estimates for complexity of various programming functions with the requirements of the client for system features, including numbers of screens and other elements for each function. The result is our estimate that the project will require approximately 409 function points. We know that our organization estimates that each resource can perform 10 func- tion points each “person-month.” Therefore, we calculate the expected number of person-months to complete this job as 409/10 = 40.1. If we assigned only four programmers to this job, it would take approximately 10 months to complete. On the other hand, by assigning our entire staff of 10 program- mers, we would expect to complete the job in just over four months. Cost estimation using this infor- mation is straightforward: If our average resource cost per programmer is $5,000/month, we multiply this figure by 40.1 to determine that our estimated cost for completing the job is $200,500.

Function point analysis is not an exact science. Complexity determinations are based on his- torical estimates that can change over time and so must be continuously updated. Further, they may not be comparable across organizations with differing estimation procedures and standards for technical complexity. Nevertheless, function point analysis does give organizations a useful system for developing cost estimates for software projects, a historically difficult class of projects to estimate with any accuracy.18

problems with Cost estimation

In spite of project management’s best efforts, a variety of issues affect the ability to conduct reason- able and accurate project cost estimates. Highly innovative projects can be notoriously difficult to estimate in terms of costs. Surprisingly, however, even projects that are traditionally viewed as highly structured, such as construction projects, can be susceptible to ruinously expensive cost overruns. Among the more common reasons for cost overruns are:19

1. Low initial estimates—Caused by misperception of the scope of the project to be under- taken, low initial estimates are a double-edged sword. In proposing the low estimates at the start of a project, management is often setting themselves up to fail to live up to the budget constraints they have imposed. Hence, low estimates, which may be created either willingly (in the belief that top management will not fund a project that is too expensive) or unwill- ingly (through simple error or neglect), almost always guarantee the result of cost overrun. Part of the reason why initial estimates may be low can be the failure to consider the project in relation to other organizational activities. If we simply cost-out various project activities without considering the other surrounding organizational activities, we can be led to assume the project team member is capable of performing the activity in an unrealistic amount of time. (See Chapter 11 on critical chain project scheduling.)

table 8.5 function Point calculations for restaurant reorder System

complexity Weighting

function low Medium High total

Number of Inputs 4 : 15 = 60 Number of Outputs 10 : 20 = 200 Number of Interfaces 3 : 3 = 9 Number of Queries 10 : 6 = 60 Number of Files 2 : 40 = 80 Total 409

8.2 Cost Estimation 273

Low estimates may also be the result of a corporate culture that rewards underestima- tion. For example, in some organizations, it is widely understood that cost overruns will not derail a project manager’s career nearly as quickly as technical flaws. Therefore, it is common for project managers to drastically underestimate project costs in order to get their project funded, continually apply for supplemental funding as the project continues, and eventually turn in a product with huge cost overruns. Political considerations also can cause project teams or top management to view a project through rose-colored glasses, minimiz- ing initial cost estimates, particularly if they run contrary to hoped-for results. The Denver International Airport represents a good example of a community ignoring warning signs of overly optimistic cost estimates in the interest of completing the project. The resulting cost overruns have been enormous.

2. Unexpected technical difficulties—A common problem with estimating the costs associated with many project activities is to assume that technical problems will be minimal; that is, the cost estimate is often the case of seeming to suggest that “All other things being equal, this task should cost $XX.” Of course, all other things are rarely equal. An estimate, in order to be meaningful, must take a hard look at the potential for technical problems, start-up delays, and other technical risks. It is a fact that new technologies, innovative procedures, and engi- neering advances are routinely accompanied by failures of design, testing, and application. Sometimes the impact of these difficulties is the loss of significant money; other times the losses are more tragic, resulting in the loss of life. The Boeing V-22 Osprey transport aircraft, for example, employs a radical “tilt-rotor” technology that was developed for use by the U.S. Marines and Navy. Prototype testing identified design flaws, contributing to the deaths of test pilots in early models of these aircraft.

3. Lack of definition—The result of poor initial scope development is often the creation of proj- ects with poorly defined features, goals, or even purpose (see Chapter 5 on scope manage- ment). This lack of a clear view of the project can quickly spill over into poorly realized cost estimates and inevitable cost overruns. It is important to recognize that the process of cost estimation and project budgeting must follow a comprehensive scope statement and work breakdown structure. When the first steps are done poorly, they effectively render futile any attempt at reasonable estimation of project costs.

4. Specification changes—One of the banes of project management cost estimation and control is the midcourse specifications changes (sometimes referred to as “scope creep”) that many projects are so prone to. Information technology projects, for example, are often riddled with requests for additional features, serious modifications, and updated processes—all while the project’s activities are still in development. In the face of serious changes to project scope or specification, it is no wonder that many projects routinely overrun their initial cost estimates. In fact, with many firms, initial cost estimates may be essentially meaningless, particularly when the company has a well-earned reputation for making midcourse adjust- ments to scope.

5. External factors—Inflation and other economic impacts can cause a project to overrun its  estimates, many times seriously. For example, in the face of a financial crisis or an unexpected worldwide shortage of a raw material, cost estimates that were made with- out taking such concerns into account are quickly moot. To cite one example, in the early part of this decade, China and India’s aggressive modernization and industrialization efforts, coupled with a weak American dollar, had been driving the price of crude oil to near-record highs. Because crude oil is benchmarked against the U.S. dollar, which is currently being kept weak by the Federal Reserve, it was taking more dollars to purchase oil. Further, Chinese and Indian demand for oil had led to higher international prices. A project that requires significant supplies of crude oil would have had to be recalculated upward due to the significant increase in the cost of this critical resource. Other common external effects can occur in  the case of political considerations shaping the course that a project is expected to follow. This phenomenon is often found in government projects, particularly military acquisition contracts, which have a history of cost overruns, gov- ernmental intervention in the form of oversight committees, multiple constituents, and numerous midcourse change requests.

274 Chapter 8 • Cost Estimation and Budgeting

Box 8.2

Project Management research in Brief

“Delusion and Deception” Taking Place in Large Infrastructure Projects

This should be the golden age of infrastructure projects. A recent issue of The Economist reported that an estimated $22 trillion is to be invested in these projects over the next 10 years, making spending on infrastruc- ture “the biggest investment boom in history.” Because of this long-term commitment to large infrastructure improvements, coupled with the enormous costs of successfully completing these projects, it is critical that the governments and their agents responsible for designing and managing them get things right. In other words, too much is at stake to mismanage these projects.

Unfortunately, as previous examples in this chapter make clear, private organizations as well as the public sector have terrible performance records when it comes to successfully managing and delivering on their large infrastructure cost and performance targets. Examples such as the Sydney Opera House (original projected cost of 7 million Australian dollars; final cost of 102 million), the Eurotunnel (final costs more than double the original projections), and the Boston “Big Dig” (original estimated cost of $2.5 billion; final cost of nearly $15 billion) continue to be the rule rather than the exception when it comes to infrastructure project performance. The long list of incredibly overrun projects begs some simple questions: What is going on here? Why are we routinely so bad at cost estimation? What factors are causing us to continually miss our targets when it comes to estimating project costs?

Professor Bent Flyvbjerg, a project management researcher at Oxford University, and several colleagues have studied the track records of large infrastructure projects over the years and have arrived at some star- tling conclusions about the causes of their runaway costs: In most cases, the causes come from one of three sources—over-optimism bias, deliberate deception, or simple bad luck.

1. Optimism bias—Flyvbjerg’s work showed that executives commonly fall victim to delusions when it comes to projects, something he refers to as the “planning fallacy.” Under the planning fallacy, managers routinely minimize problems and make their decisions on the basis of delusional optimism—underestimating costs and obstacles, involuntarily spinning scenarios for success, and assuming best-case options and outcomes. Optimism bias leads project managers and top executives to err on the side of underestimation of costs and time for project activities even in the face of previous evidence or past experiences. In short, we tend to develop overly positive scenarios of schedule and cost for projects and make forecasts that reflect these delusions.

2. Deliberate deception—Large capital investment projects often require complex layers of decision making in order to get them approved. For example, governments have to work with private contractors and other agents who are responsible for making initial cost projections. Flyvbjerg found that some opportunities to inappropriately bias the project (deception) occur when a project’s stakeholders all hold different incen- tives for the project. For example, the construction consortium wants the project, the government wants to provide for taxpayers and voters, bankers want to secure long-term investments, and so on. Under this situation, contractors may feel an incentive to provide estimates that are deliberately undervalued in order to secure the contract. They know that “true” cost estimates could scare off the public partners so they adopt a policy of deliberate deception to first win the contract, knowing that once the government is com- mitted, it is extremely difficult for them to change their minds, even in the face of a series of expanding cost estimates. In short, the goal here is to get the project contracts signed; once the project is “on the books,” it tends to stay there.

Government representatives themselves can play a role in deception when it comes to “green- lighting” expensive projects. They may do this from a variety of motives, including altruism, reasoning that full disclosure of a project’s costs will alienate the public, regardless of how much societal good may come from it, or their motives may be more self-serving. For example, the Willy Brandt International Airport in Berlin was scheduled to open in 2010. With a cost that has ballooned to over $7 billion and no fixed open- ing date in sight, critics have argued that the airport was a politicians’ vanity project from the beginning. As one writer noted: “Many politicians want prestigious large-scale projects to be inseparably connected with their names. To get these expensive projects started, they artificially calculate down the real costs to get permission from parliament or other committees in charge.”20

3. Bad luck—A final reason for escalating project costs is simple bad luck. Bad luck implies that in spite of sound estimates, due diligence from all parties involved in the project, and the best intentions of both the contractors and project clients, there are always going to be cases where circumstances, environmental impacts, and sheer misfortune can conspire to derail a project or severely cripple its delivery. Though there is no doubt that bad luck does sometimes occur, Flyvbjerg warns that it is usually a handy excuse to attribute project problems to “bad luck,” when the reality is that overruns and schedule slippage are typically caused by much more foreseeable reasons, as suggested above.

8.3 Creating a Project Budget 275

8.3 Creating a projeCt buDget

The process of developing a project budget is an interesting mix of estimation, analysis, intuition, and repetitive work. The central goal of a budget is the need to support rather than conflict with the project’s and the organization’s goals. The project budget is a plan that identifies the allocated resources, the project’s goals, and the schedule that allows an organization to achieve those goals. Effective budgeting always seeks to integrate corporate-level goals with department-specific objec- tives; short-term requirements with long-term plans; and broader, strategic missions with concise, needs-based issues. Useful budgets evolve through intensive communication with all concerned parties and are compiled from multiple data sources. Perhaps most importantly, the project budget and project schedule must be created in tandem; the budget effectively determines whether or not project milestones can be achieved.

As one of the cornerstones of project planning, the project budget must be coordinated with project activities defined in the Work Breakdown Structure (see Chapter 5). As Figure 8.7 suggests, the WBS sets the stage for creating the project schedule; the project budget subsequently assigns the necessary resources to support that schedule.

A number of important issues go into the creation of the project budget, including the process by which the project team and the organization gather data for cost estimates, budget projections, cash flow income and expenses, and expected revenue streams. The methods for data gathering and alloca- tion can vary widely across organizations; some project firms rely on the straight, linear allocation of income and expenses, without allowing for time, while others use more sophisticated systems. The ways in which cost data are collected and interpreted mainly depend upon whether the firm employs a top-down or a bottom-up budgeting procedure. These approaches involve radically different meth- ods for collecting relevant project budget information and can potentially lead to very different results.

top-Down budgeting

top-down budgeting requires the direct input from the organization’s top management; in essence, this approach seeks to first ascertain the opinions and experiences of top management regarding estimated project costs. The assumption is that senior management is experienced with past projects and is in a position to provide accurate feedback and estimates of costs for future project ventures. They take the first stab at estimating both the overall costs of a project and its major work packages. These projections are then passed down the hierarchy to the next functional department levels where additional, more specific information is collected. At each step down the hierarchy, the project is broken into more detailed pieces, until project personnel who actually will be performing the work ultimately provide input on specific costs on a task-by-task basis.

This approach can create a certain amount of friction within the organization, both between top and lower levels and also between lower-level managers competing for budget money. When

The research on serious project overruns and their causes offers some important insight into reasons why we keep missing our targets for critical projects. It also suggests additional effects that are equally important: Underestimating costs and overestimating benefits from any project leads to two problems. First, we opt to begin many projects that are not (and never were) economically viable. Second, starting these projects means we are effectively ignoring alternatives that actually could have yielded higher returns had we made a better initial analysis. Ultimately, the common complaint about large infrastructure projects (“Over budget, over time, over and over again”) is one for which most organizations have no one to blame but themselves.21

WBS

Project Plan

Scheduling Budgeting

Figure 8.7 the relationship Among WBS, Scheduling, and Budgeting

276 Chapter 8 • Cost Estimation and Budgeting

top management establishes an overall budget at the start, they are, in essence, driving a stake into the ground and saying, “This is all we are willing to spend.” As a result, all successive levels of the budgeting process must make their estimates fit within the context of the overall budget that was established at the outset. This process naturally leads to jockeying among different functions as they seek to divide up the budget pie in what has become a zero-sum game—the more budget money engineering receives, the less there is for procurement to use.

On the positive side, research suggests that top management estimates of project costs are often quite accurate, at least in the aggregate.22 Using this figure as a basis for drilling down to assign costs to work packages and individual tasks brings an important sense of budgetary disci- pline and cost control. For example, a building contractor about to enter into a contract to develop a convention center is often knowledgeable enough to judge the construction costs with reasonable accuracy, given sufficient information about the building’s features, its location, and any known building impediments or worksite constraints. All subcontractors and project team members must then develop their own budgets based on the overall, top-down contract.

bottom-up budgeting

Bottom-up budgeting takes a completely different approach than that pursued by top-down meth- ods. The bottom-up budgeting approach begins inductively from the work breakdown structure to apply direct and indirect costs to project activities. The sum of the total costs associated with each activity are then aggregated, first to the work package level, then at the deliverable level, at which point all task budgets are combined, and then higher up the chain where the sum of the work package budgets are aggregated to create the overall project budget.

In this budgeting approach, each project manager is required to prepare a project budget that identifies project activities and specifies funds requested to support these tasks. Using these first-level budget requests, functional managers develop their own carefully documented budgets, taking into consideration both the requirements of the firms’ projects and their own departmental needs. This information is finally passed along to top managers, who merge and streamline to eliminate overlap or double counting. They are then responsible for creating the final master bud- get for the organization.

Bottom-up budgeting emphasizes the need to create detailed project plans, particularly Work Breakdown Structures, as a first step for budget allocations. It also facilitates coordination between the project managers and functional department heads and, because it emphasizes the unique cre- ation of budgets for each project, it allows top managers a clear view for prioritization among projects competing for resources. On the other hand, a disadvantage of bottom-up budgeting is that it reduces top management’s control of the budget process to one of oversight, rather than direct initiation, which may lead to significant differences between their strategic concerns and the operational-level activities in the organization. Also, the fine-tuning that often accompanies bottom-up budgeting can be time-consuming as top managers make adjustments and lower-level managers resubmit their numbers until an acceptable budget is achieved.

activity-based Costing

Most project budgets use some form of activity-based costing. Activity-based costing (ABc) is a budgeting method that assigns costs first to activities and then to the projects based on each proj- ect’s use of resources. Remember that project activities are any discrete task that the project team undertakes to make or deliver the project. Activity-based costing, therefore, is based on the notion that projects consume activities and activities consume resources.23

Activity-based costing consists of four steps:

1. Identify the activities that consume resources and assign costs to them, as is done in a bottom- up budgeting process.

2. Identify the cost drivers associated with the activity. Resources, in the form of project person- nel, and materials are key cost drivers.

3. Compute a cost rate per cost driver unit or transaction. Labor, for example, is commonly simply the cost of labor per hour, given as:

Cost rate/unit  333333T $Cost/hour

8.3 Creating a Project Budget 277

4. Assign costs to projects by multiplying the cost driver rate times the volume of cost driver units consumed by the project. For example, assume the cost of a senior software program- mer is $40/hour and that she is to work on the project for a total of 80 hours. The cost to the project would be:

($40/hr) (80 hours) = $3,200.00

As we discussed earlier in this chapter, numerous sources of project costs (cost drivers) apply to both the direct and the indirect costs of a project. Activity-based costing, a technique employed within most project budgets, requires the early identification of these variables in order to create a meaningful control document.

Table 8.6 demonstrates part of a project budget. The purpose of the preliminary budget is to identify the direct costs and those that apply to overhead expenses. It is sometimes necessary to fur- ther break down overhead costs to account for separate budget lines. The overhead figure of $500 for Survey, for example, may include expenses covering health insurance, retirement contributions, and other forms of overhead, which would be broken out in a more detailed project budget.

Table 8.7 shows a budget in which the total planned expenses given in Table 8.6 are com- pared against actual accrued project expenses. With periodic updating, this budget can be used for variance reporting to show differences, both positive and negative, between the baseline budget assigned to each activity and the actual cost of completing those tasks. This method offers a central location for the tabulation of all relevant project cost data and allows for the preliminary develop- ment of variance reports. On the other hand, this type of budget is a static budget document that does not reflect the project schedule and the fact that activities are phased in following the net- work’s sequencing.

Table 8.8 shows a sample from a time-phased budget, in which the total budget for each project activity is disaggregated across the schedule when its work is planned. The time-phased budget allocates costs across both project activities and the anticipated time in which the budget is to be expended. It allows the project team to match its schedule baseline with a budget base- line, identifying milestones for both schedule performance and project expense. As we will see in Chapter 13, the creation of a time-phased budget works in tandem with more sophisticated project control techniques, such as earned value management.

table 8.6 Sample Project Budget

Activity Direct costs Budget overhead total cost

Survey 3,500 500 4,000

Design 7,000 1,000 8,000

Clear Site 3,500 500 4,000

Foundation 6,750 750 7,500

Framing 8,000 2,000 10,000

Plumb and Wire 3,750 1,250 5,000

table 8.7 Sample Budget tracking Planned and Actual Activity costs

Activity Planned Budget Actual Variance

Survey 4,000 4,250 250

Design 8,000 8,000 - 0 -

Clear Site 4,000 3,500 (500)

Foundation 7,500 8,500 1,000

Framing 10,000 11,250 1,250

Plumb and Wire 5,000 5,150 150

Total 38,500 40,650 2,150

278 Chapter 8 • Cost Estimation and Budgeting

We can produce a tracking chart that illustrates the expected budget expenditures for this project by plotting the cumulative budgeted cost of the project against the baseline schedule. Figure 8.8 is a simple graphic of the plot and is another method for identifying the project baseline for schedule and budget over the anticipated life of the project.

8.4 DeVeloping buDget ContingenCies

Budget contingencies symbolize the recognition that project cost estimates are just that: estimates. Unforeseen events often conspire to render initial project budgets inaccurate, or even useless. (Suppose a construction project that had budgeted a fixed amount for digging a building’s founda- tion accidentally discovered serious subsidence problems or groundwater.) Even in circumstances in which project unknowns are kept to a minimum, there is simply no such thing as a project developed with the luxury of full knowledge of events. A budget contingency is the allocation of extra funds to cover these uncertainties and improve the chances that the project can be completed within the time frame originally specified. Contingency money is typically added to the project’s budget following the identification of all project costs; that is, the project budget does not include contingency as part of the activity-based costing process. Rather, the contingency is calculated as an extra cushion on top of the calculated cost of the project.

Cumulative Budgeted Cost (in thousands)

40

35

30

25

20

15

10

5

Jan. Feb. Mar. Apr. May

Figure 8.8 cumulative Budgeted cost of the Project

table 8.8 example of a time-Phased Budget

Months

Activity january february March April May total by Activity

Survey 4,000 4,000

Design 5,000 3,000 8,000

Clear Site 4,000 4,000

Foundation 7,500 7,500

Framing 8,000 2,000 10,000

Plumb and Wire 1,000 4,000 5,000

Monthly Planned 4,000 9,000 10,500 9,000 6,000

Cumulative 4,000 13,000 23,500 32,500 38,500 38,500

8.4 Developing Budget Contingencies 279

There are several reasons why it may make good sense to include contingency funding in project cost estimates. Many of these reasons point to the underlying uncertainty that accompanies most project cost estimation:24

1. Project scope is subject to change. Many projects aim at moving targets; that is, the project scope may seem well articulated and locked in. However, as the project moves through its devel- opment cycle, external events or environmental changes can often force us to modify or upgrade a project’s goals. For example, suppose that our organization set out to develop an electronics product for the commercial music market only to discover, halfway through the development, that technological advances had rendered our original product obsolete. One option, other than abandoning the project, might be to engineer a product design upgrade midstream in the proj- ect’s development. Those scope changes will cause potentially expensive cost readjustments.

2. Murphy’s Law is always present. Murphy’s Law suggests that if something can go wrong, it often will. Budget contingency represents one important method for anticipating the like- lihood of problems occurring during the project life cycle. Thus, contingency planning just makes prudent sense.

3. Cost estimation must anticipate interaction costs. It is common to budget project activi- ties as independent operations. Thus, in a product development project, we develop a dis- crete budget for each work package under product design, engineering, machining, and so forth. However, this approach fails to recognize the often “interactive” nature of these activi- ties. For example, suppose that the engineering phase requires a series of iterative cycles to occur between the designers and the engineers. As a series of designs are created, they are forwarded to the engineering section for proofing and quality assessment. When problems are encountered, they must be shipped back to design to be corrected. Coordinating the sev- eral cycles of design and rework as a product moves through these two phases is often not accounted for in a standard project budget. Hence, contingency budgets allow for the likely rework cycles that link project activities interactively.

4. Normal conditions are rarely encountered. Project cost estimates usually anticipate “nor- mal conditions.” However, many projects are conducted under anything but normal work- ing conditions. Some of the ways in which the normal conditions assumption is routinely violated include the availability of resources and the nature of environmental effects. Cost estimators assume that resources required for the project will be available when needed; however, personnel may be missing, raw materials may be of poor quality, promised funding may not materialize, and so forth. When resources are missing or limited, the activities that depend upon their availability are often delayed, leading to extra costs. Likewise, the geog- raphy and environmental effects on some projects demonstrate the difficulty in creating a “normal” project situation. For example, a project manager was assigned to develop a power plant in the West Bengal province of India only to discover, upon arrival, that the project was set to begin at the same time that the annual torrential monsoon rains were due to arrive! His first project activity, after reaching the construction site, was to spend three weeks erect- ing a five-foot retaining wall and coffer dam around the site to ensure it would not flood. Of course, the cost of this necessary construction had not been factored into his initial budget.

While project teams naturally favor contingencies as a buffer for project cost control, their acceptance by project stakeholders, particularly clients, is less assured. Some clients may feel that they are being asked to cover poor budget control on the part of the project firm. Other clients object to what seems an arbitrary process for calculating contingency. For example, it is common in the building industry to apply a contingency rate of 10%–15% to any structure prior to architec- tural design. As a result, a building budgeted for $10 million would be designed to cost $9 million. The additional million dollars is held in escrow as contingency against unforeseen difficulties dur- ing the construction and is not applied to the operating budget. Finally, does the contingency fund apply equally across all project work packages or should it be held in reserve to support critical activities as needed? Where or across what project activities contingency funds should be applied is the final point of contention. Despite these drawbacks, there are several benefits to the use of contingency funding for projects, including:

1. It recognizes that the future contains unknowns, and the problems that do arise are likely to have a direct effect on the project budget. In providing contingency, the project allows for the negative effects of both time and money variance.

280 Chapter 8 • Cost Estimation and Budgeting

2. Provision is made in the company plans for an increase in project cost. Contingency has some- times been called the first project fire alarm. Allowing contingency funds to be applied to a proj- ect is a preliminary step in gaining approval for budget increases, should they become necessary.

3. Application to the contingency fund gives an early warning signal of a potential overdrawn budget. In the event of such signals, the organization’s top management needs to take a seri- ous look at the project and the reasons for its budget variance, and begin formulating fall- back plans should the contingency prove to be insufficient to cover the project overspend. In large defense-industry contracts, for example, project organizations facing budget overruns often first apply any contingency money they possess to the project before approaching the governmental agency for additional funding. An Army project contract manager will under- standably demand full accounting of project expenditures, including contingency funds, before considering additional funding.

Project cost estimation and budgeting are two important components of project control. Because a significant constraint on any project is its budget, the manner in which we estimate project costs and create realistic budgets is critical to effective project planning. Further, the best defense against overrunning our budgets is to prepare project cost estimates as carefully as possible. Although we cannot possibly anticipate every eventuality, the more care that is used in initial estimation, the greater the likelihood that we can create a budget that is a reasonably accurate reflection of the true project cost. Cost estimation challenges us to develop reasonable assumptions and expecta- tions for project costs through clearly articulating the manner in which we arrive at our estimates. Budgeting is the best method for applying project expenditures systematically, with an eye toward keeping project costs in line with initial estimates. Taken together, cost estimation and budgeting require every project manager to become comfortable with not only the technical challenges of the project, but its monetary constraints as well.

Summary

1. Understand the various types of common project costs. Project budgeting comprises two distinct elements: cost estimation and the budgeting pro- cess itself. Among the well-known expenses in most projects are: a. Cost of labor—the charge against the human re-

sources needed to complete the project. b. Cost of materials—costs relating to any specific

equipment or supplies needed for project de- velopment.

c. Subcontractors—charges against the project budget for the use of consultants or other sub- contracted work.

d. Cost of equipment and facilities—the costs of any plant and equipment, either at the project’s location or off-site.

e. Travel—a sometimes necessary charge for the expense of having project team members in the field or at other sites.

2. recognize the difference between various forms of project costs. The types of costs that a project can incur can be identified in a number of ways. Among the more common types of costs are: • Direct versus indirect—Direct costs are those that

can be directly assigned to specific project activi- ties performed to create the project. Indirect costs relate to general company overhead expenses or administration. For example, overhead expenses

charged to a project may include health benefits or retirement contributions. General administra- tion includes shipping costs, secretarial or com- puter support, sales commissions, and so on.

• Recurring versus nonrecurring—Recurring costs are ongoing expenses, such as labor or mate- rial costs. They appear across the project’s life cycle. Nonrecurring costs are typically one-time expenses related to some special expense or pur- chase, such as training or purchase of a building.

• Fixed versus variable—Fixed costs do not vary with respect to their usage. Variable costs generally increase in proportion to the degree they are used.

• Normal versus expedited—Normal costs are the normally scheduled costs of the project, set in re- lation to the schedule baseline. Expedited costs are sometimes referred to as “crashing costs” and increase due to the extra resources assigned to speed the completion of a specific project activity.

3. Apply common forms of cost estimation for proj- ect work, including ballpark estimates and defini- tive estimates. Cost estimating may follow one of several approaches, usually increasing in accu- racy as estimates coincide more closely with the completion of project design work. Preliminary estimates for task completion, sometimes called “ballpark estimates,” may be accurate only to ;30%. On the other hand, as the project gets closer to the

Key Terms 281

completion of the design phase, it is more realistic to expect more accurate, definitive estimates (± 5%). One method for cost estimation is through the use of parametric techniques, which compare current project activities to the cost of past, similar activities and then assign a multiplier that considers inflation or other additional cost increases.

4. Understand the advantages of parametric cost esti- mation and the application of learning curve mod- els in cost estimation. Parametric cost estimation allows project managers to develop detailed esti- mates of current project costs by taking older work and inserting a multiplier to account for the impact of inflation, labor and materials increases, and other reasonable direct costs. Parametric estimation allows project managers to begin formulating cost estimates from a position of past historical record, which can be very helpful in complex projects for which it is difficult to formulate reasonable estimates.

One element in project cost estimation that can- not be ignored is the effect of learning rates on an individual’s ability to perform a project task. Learn- ing curve effects typically are relevant only in cases where a project team member is required to perform multiple iterations of a task. When these situations occur, it is usually easier and faster to complete the nth iteration than it was to complete the first, due to the effect of learning on repetitive activities. Using available formulas, we can readjust cost estimates for some project activities to reflect the effect of the learning curve on the cost of an activity.

5. discern the various reasons why project cost esti- mation is often done poorly. Cost estimation may be poorly done for several reasons, including: a. Low initial estimates—These are caused by poor

knowledge of the project’s scope or due to an or- ganizational atmosphere that rewards low initial estimates and does not sanction subsequent cost or schedule overruns.

b. Unexpected technical difficulties—This is a com- mon problem for many projects when techni- cal performance is cutting-edge and unexpected problems emerge.

c. Lack of definition—Poorly specified projects usually lead to poorly budgeted and controlled projects.

d. Specification changes—The continuing distrac- tion of specification change requests can quickly lead to cost overruns.

e. External factors—The uncontrollable effects of inflation or economic or political interference in a project can render initial cost estimates invalid.

6. Apply both top-down and bottom-up budgeting procedures for cost management. Project bud- geting involves the process of taking the individ- ual activity cost estimates and creating a working document for planned project expenditures. Two approaches to budgeting involve the use of top- down and bottom-up efforts to better identify costs and allocate project budget money. Using activity- based budgeting techniques, project teams typically identify the activities that consume resources and assign costs to them. Second, they determine the cost drivers associated with the activities (usually human resources and materials costs), and third, a cost rate per cost driver is then computed. Activity- based budgeting allows for the creation of project budgets with specific budget lines for each task nec- essary to complete the project.

7. Understand the uses of activity-based budgeting and time-phased budgets for cost estimation and control. Taking activity-based budgeting one step further, we can create time-phased budgets when the specific activity costs are then allocated across the project schedule baseline to reflect the points on the project time line when the budget will be consumed. Using a time-phased budget approach allows the project team to link time and cost into a unified baseline that can be set to serve as the project plan. Project cost control, as the project moves forward, is predicated on creating the time- phased budget.

8. recognize the appropriateness of applying con- tingency funds for cost estimation. In some projects, it is necessary, for a variety of reasons, to set aside a certain amount of the project bud- get into an account to handle any uncertainties or unexpected events that could not have been antici- pated in the initial cost estimation and budgeting sequence. This account is referred to as a project contingency fund. In many types of projects, par- ticularly construction projects, a contingency fund is a normal part of the project budget. Contingency is not assigned to any specific project activities; rather, it is used as a general project-level emer- gency fund to handle the costs associated with problems, should any arise.

Key Terms

Activity-based costing (ABC) (p. 276)

Ballpark estimates (p. 263)

Bottom-up budgeting (p. 276)

Budget contingency (p. 278)

Comparative estimates (p. 263)

Cost estimation (p. 259) Crashing (p. 262)

Definitive estimates (p. 264)

Direct costs (p. 260) Expedited costs (p. 262)

282 Chapter 8 • Cost Estimation and Budgeting

Feasibility estimates (p. 264)

Fixed costs (p. 261) Function point analysis

(p. 271)

Function points (p. 271) Indirect costs (p. 260) Learning curves (p. 267) Nonrecurring costs

(p. 261)

Normal costs (p. 262) Parametric estimation

(p. 263) Project budget (p. 275) Recurring costs (p. 261)

Time-phased budget (p. 277)

Top-down budgeting (p. 275)

Variable costs (p. 262)

Solved Problems

8.1 cAlcUlAtiNg fUlly loADeD lABor coStS

Calculate the fully loaded cost of labor for the project team using the following data. What are the costs for the individ- ual project team members? What is the fully loaded cost of labor?

Name Hours

Needed overhead

charge

Personal time rate

Hourly rate

fully loaded labor cost

John 40 1.80 1.12 $21/hr

Bill 40 1.80 1.12 $40/hr

J.P. 60 1.35 1.05 $10/hr

Sonny 25 1.80 1.12 $32/hr

Total Fully Loaded Labor Cost =

SoLuTion

We use the formula for calculating fully loaded costs, given as:

Hourly rate * Hours needed * Overhead charge * Personal time = Total fully loaded labor cost

Applying each rate given above in turn, we fill in the fully loaded cost table as follows:

Name Hours

Needed overhead

charge

Personal time rate

Hourly rate

fully loaded labor cost

John 40 1.80 1.12 $21/hr $1,693.44

Bill 40 1.80 1.12 $40/hr 3,225.60

J.P. 60 1.35 1.05 $10/hr 850.50

Sonny 25 1.80 1.12 $32/hr 1,612.80

Total Fully Loaded Labor Cost = $7,382.34

8.2 eStiMAtiNg SoftWAre coStS WitH fUNctioN PoiNtS

Suppose you were required to create a reasonably detailed esti- mate for developing a new student information and admissions system at a local college. Your firm’s programmers average 6 func- tion points on a person-month basis. After speaking with repre- sentatives from the college, you know that their request is based on the following screen requirements: inputs (4), outputs (7), inter- faces (12), queries (20), and files (16). Further, we have determined that the relative complexity of each of these functions is as follows: inputs (low), outputs (medium), interfaces (high), queries (medi- um), and files (medium). Using this information and the following table, calculate the number of function points for this project.

complexity Weighting

function low Medium High total

Number of Inputs 3 * ____ = 6 * ____ = 9 * ____ = Number of Outputs 2 * ____ = 6 * ____ = 10 * ____ = Number of Interfaces 1 * ____ = 3 * ____ = 5 * ____ = Number of Queries 4 * ____ = 8 * ____ = 12 * ____ = Number of Files 4 * ____ = 6 * ____ = 8 * ____ =

SoLuTion

Once we know the number of requirements for each of the five programmer functions and the complexity weighting for the activities, the calculation of total function points requires that

we create a table as shown below, in which the relative com- plexity of the five programming functions is multiplied by the number of screen requirements. The table shows that the total number of function points for this project is 370.

Discussion Questions 283

complexity Weighting

function low Medium High total

Number of Inputs 3 × 4 = 12

Number of Outputs 6 × 7 = 42

Number of Interfaces 5 × 12 = 60

Number of Queries 8 × 20 = 160

Number of Files 6 × 16 = 96

8.3 cAlcUlAtiNg BUDget eStiMAteS USiNg tHe leArNiNg cUrVe

Assume you have a software project that will require the coding services of a senior programmer to complete 14 coding sequenc- es that are relatively similar. We know that the programmer’s learning rate is .90 and that the first coding sequence is likely to take her 15 hours to complete. Using the learning curve formula, calculate the steady state time to code these sequences.

SoLuTion

Recall that the learning curve formula for calculating the time required to produce the steady state unit of output is repre- sented as:

Yx = aX b

where

Yx = the time required for the steady state, x, unit of output

a = the time required for the initial unit of output X = the number of units to be produced to reach

the steady state

b = the slope of the learning curve, represented as: log decimal learning rate/log 2

b = log 0.90/log 2 = - 0.4576/0.301 = - 0.1521

Yx = 15(14) -0.1521

Yx = 10.04 hours

Discussion Questions

8.1 Describe an environment in which it would be common to bid for contracts with low profit margins. What does this environment suggest about the competition levels?

8.2 How has the global economy affected the importance of cost estimation and cost control for many project organizations?

8.3 Why is cost estimation such an important component of project planning? Discuss how it links together with the Work Breakdown Structure and the project schedule.

8.4 Imagine you are developing a software package for your company’s intranet. Give examples of the various types of costs (labor, materials, equipment and facili- ties, subcontractors, etc.) and how they would apply to your project.

8.5 Give reasons both in favor of and against the use of a per- sonal time charge as a cost estimate for a project activity.

8.6 Think of an example of parametric estimating in your per- sonal experience, such as the use of a cost multiplier based on a similar, past cost. Did parametric estimating work or not? Discuss the reasons why.

8.7 Suppose your organization used function point analy- sis to estimate costs for software projects. How would

the expertise level of a recently hired programmer affect your calculation of their function points on a monthly basis when compared to an older, more experienced programmer?

8.8 Put yourself in the position of a project customer. Would you insist on the cost adjustments associated with learn- ing curve effects or not? Under what circumstances would learning curve costs be appropriately budgeted into a project?

8.9 Consider the common problems with project cost estima- tion and recall a project with which you have been involved. Which of these common problems did you encounter most often? Why?

8.10 Would you prefer the use of bottom-up or top-down bud- geting for project cost control? What are the advantages and disadvantages associated with each approach?

8.11 Why do project teams create time-phased budgets? What are their principal strengths?

8.12 Project contingency can be applied to projects for a vari- ety of reasons. List three of the key reasons why a project organization should consider the application of budget contingency.

284 Chapter 8 • Cost Estimation and Budgeting

Problems

8.1 Calculate the fully loaded cost of labor for a project team member using the following data:

Hourly rate: $35/hr Hours needed: 150 Overhead rate: 55%

8.2 Calculate the fully loaded cost of labor for your Project Engineer using the following data:

Hourly rate: $40/hr Estimated hours of work: 120 Overhead rate: 65% Personal time: 15%

8.3 Calculate the fully loaded cost of labor for the project team using the following data. What are the costs for the indi- vidual project team members? What is the fully loaded cost of labor?

Name Hours

Needed overhead

charge Personal

time rate Hourly rate

fully loaded labor cost

Sandy 60 1.35 1.12 $18/hr

Chuck 80 1.75 1.12 $31/hr

Bob 80 1.35 - 0 - $9/hr

Penny 40 1.75 1.12 $30/hr

Total Fully Loaded Labor Cost =

8.4 Assume that overhead is charged on a flat-rate basis. Each member of the project is assigned an overhead charge of $150/week. What would the fully loaded cost of labor be for an employee, given that she is assigned to the project for 200 hours at $10.50/hour?

8.5 Calculate the fully loaded labor costs for members of your project team using the following data. Who is the most expensive member of your team? What proportion of the overall fully loaded cost of labor is taken up by this individual?

Name Hours

Needed overhead

charge Personal

time rate Hourly rate

fully loaded labor cost

Todd 150 1.45 1.15 $36/hr

Stan 150 1.70 - 0 - $12/hr

Mary 120 1.45 - 0 - $21.5/hr

Alice 100 1.70 1.15 $24/hr

Total Fully Loaded Labor Cost =

8.6 Using the following information about work package bud- gets, complete the overall time-phased budget for your project. (All cost figures are in $000s). Which are the weeks with the greatest budget expense?

Table for Problem 8.6

task Budget Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8

A 5 3 2

B 8 1 4 3 1

C 12 2 7 3

D 7 3 3 1

E 14 5 5 2 2

F 6 1 2 3

Plan 52 4 8

Cumulative 4 12

8.7 Given the following information, complete a time-phased budget for your project. (All cost figures are in $000s).

What are weekly planned and cumulative costs for the project?

Table for Problem 8.7

Work Package cost per Week

Work Package Budget Week 1 Week 2 Week 3 Week 4 Week 5

Staffing 5 4 1

Blueprinting 8 1 6 1

Prototyping 12 2 8 2

Full Design 24 4 10 10

Plan

Cumulative

Problems 285

for Problems 8 through 10, refer to the chart of learning curve coefficients (unit and total time multipliers) shown at the bottom of this page.

The simplified formula for calculating learning rate time using the table coefficients is given as:

TN = T 1C

where

TN = Time needed to produce the nth unit

T1 = Time needed to produce the first unit

C = Learning curve coefficient

8.8 It took MegaTech, Inc., 100,000 labor-hours to produce the first of several oil-drilling rigs for Antarctic explora- tion. Your company, Natural Resources, Inc., has agreed to purchase the fifth (steady state) oil-drilling rig from MegaTech’s manufacturing yard. Assume that MegaTech

experiences a learning rate of 80%. At a labor rate of $35 per hour, what should you, as the purchasing agent, ex- pect to pay for the fifth unit?

8.9 Problem 8 identified how long it should take to complete the fifth oil-drilling platform that Natural Resources plans to purchase. How long should all five oil-drilling rigs take to complete?

8.10 Suppose that you are assigning costs to a major proj- ect to be undertaken this year by your firm, DynoSoft Applications. One particular coding process involves many labor-hours, but highly redundant work. You antici- pate a total of 200,000 labor-hours to complete the first it- eration of the coding and a learning curve rate of 70%. You are attempting to estimate the cost of the twentieth (steady state) iteration of this coding sequence. Based on this in- formation and a $60 per hour labor rate, what would you expect to budget as the cost of the twentieth iteration? The fortieth iteration?

learning curve coefficients (Unit time and total time Multipliers)

70% 75% 80% 85%

Steady State Unit Unit time total time Unit time total time Unit time total time Unit time total time

5 .437 3.195 .513 3.459 .596 3.738 .686 4.031

10 .306 4.932 .385 5.589 .477 6.315 .583 7.116

15 .248 6.274 .325 7.319 .418 8.511 .530 9.861

20 .214 7.407 .288 8.828 .381 10.485 .495 12.402

25 .191 8.404 .263 10.191 .355 12.309 .470 14.801

30 .174 9.305 .244 11.446 .335 14.020 .450 17.091

35 .160 10.133 .229 12.618 .318 15.643 .434 19.294

40 .150 10.902 .216 13.723 .305 17.193 .421 21.425

Based on a = 1.

8.11 Assume you are a project cost engineer calculating the cost of a repetitive activity for your project. There are a total of 20 iterations of this activity required for the project. The project activity takes 2.5 hours at its steady state rate and the learning rate is 75%. Calculate the initial output time for the first unit produced, using the learning curve formula:

Yx = aX b

where

Yx = the time required for the steady state, x, unit of output

a = the time required for the initial unit of output X = the number of units to be produced to reach the

steady state

b = the slope of the learning curve, represented as: log decimal learning rate/log 2

8.12 As the manager of the IT group at your insurance firm, you have been asked to develop a cost estimate for

upgrades to the computerized accident-reporting and claims adjustment system you have in place. Your system is basic, without many features, but it needs some gen- eral modifications, based on complaints from customers and claims adjusters at your firm. You know that your programmer is capable of handling 3 function points in a person-month and your programmer makes $60,000, so her cost is $5,000 per month. The costs for the project are based on the following requirements:

function Number of Screens complexity

Input 8 Low

Output 3 Low

Interfaces 8 Medium

Queries 6 Medium

Files 10 Low

286 Chapter 8 • Cost Estimation and Budgeting

The complexity weighting for these functions follows a standard formula:

8.13 You work at a regional health care center and have been asked to calculate the expected cost for a software project in your organization. You know that historically your pro- grammers can handle 5 function points each person-month

and that the cost per programmer in your company is $4,000 per month. The project whose costs you are estimat- ing is based on the following requirements:

complexity Weighting

function low Medium High total

Number of Inputs 2 * ____ = 4 * ____ = 6 * ____ = Number of Outputs 3 * ____ = 6 * ____ = 12 * ____ = Number of Interfaces 6 * ____ = 12 * ____ = 18 * ____ = Number of Queries 4 * ____ = 6 * ____ = 8 * ____ = Number of Files 2 * ____ = 4 * ____ = 8 * ____ =

a. Calculate the total estimated number of function points for this project.

b. What is the total expected cost of the project?

complexity Weighting

function low Medium High total

Number of Inputs 1 * ____ = 2 * ____ = 3 * ____ = Number of Outputs 2 * ____ = 6 * ____ = 10 * ____ = Number of Interfaces 10 * ____ = 15 * ____ = 20 * ____ = Number of Queries 3 * ____ = 6 * ____ = 9 * ____ = Number of Files 1 * ____ = 3 * ____ = 5 * ____ =

CaSE STuDy 8.1 The Hidden Costs of Infrastructure Projects—The Case of Building Dams

In recent years, there has been an upsurge in the development of large dams in both developing and developed countries, including Brazil, Ethiopia, Pakistan, and China. There are a number of reasons for this increased interest in dam building. Demand for electricity is expected to double worldwide be- tween 2010 and 2035. As a result hydroelectric power is seen as a cheap, available option for countries with river systems that allow for dams, particularly as it is a preferred option to dirtier coal-burning plants. Other arguments in favor of building these dams in- clude its use for flood control, crop irrigation, inland

transportation, urban water supplies, and as a job cre- ator. These are all powerful and tempting arguments in favor of building large dams; however, there is one important counter-argument to the push toward these hydropower megaprojects. They fail to offer the advantages they are assumed to provide.

There are a number of criticisms of large dam proj- ects. First, megadams take, on average, nearly nine years to complete. As a result, arguments that they will ease the burden of energy demands must be taken on faith; given their long lead times, they certainly are not an option for energy crisis situations. They also assume that all

function Number of Screens complexity

Input 8 Low

Output 6 Low

Interfaces 15 High

Queries 5 High

Files 25 Medium

Further, you know that the complexity weighting for these functions follows a standard internal formula, shown as: a. Calculate the total estimated number of function points for this project. b. Calculate the total expected cost of the project.

Case Study 8.1 287

Figure 8.9 Nigeria’s Kainji Dam Under construction

Source: AP Images

current circumstances (energy demand, population growth patterns, water availability, and energy prices) are likely to remain steady, or at least predictable, over the time period in which the dam is developed, which can lead to dangerous assumptions of future benefits. Nigeria’s Kainji Dam, for example, has fallen short of generating its expected hydroelectricity levels by as much as 70%. Second, cost and schedule projections to complete these dams are almost always grossly under- estimated. In fact, research suggests that cost overruns for large dam projects average 96% higher than esti- mated costs; that is, actual project costs were nearly double the original estimates. Schedules for these dams averaged overruns of 44%, or 2.3 years. Third, the cost in absolute terms for these large dam projects can nearly bankrupt the countries investing in them. For example, Ethiopia’s Grand Ethiopian Renaissance dam on the Nile River was projected to cost $4.8 billion when it was started in 2011. By the time it is completed (projected for 2017), it will end up costing more than $10 billion, or one-quarter of Ethiopia’s GDP. Instead of helping the economy and fostering growth, Ethiopia could be facing enormous problems paying off long- term debt from financing the dam. Nor is this a new phenomenon. Brazil’s Itaipu Dam was built in the 1970s at a cost of almost $20 billion, or 240% more than pro- jected. Since opening, it has been a drain on the country’s finances. Despite producing electricity that is needed to support development in Brazil, it is unlikely that the costs of the Itaipu Dam will ever allow it to break even.

What is the solution? Countries such as Norway, which produces some 99% of its energy from

hydropower, have adopted a smaller, more flexible solu- tion to the use of dams. The government encourages the development not of large megadams, but of smaller, more flexible plants designed to produce smaller vol- umes of electricity but located at more locations within the country. Thus Norway currently supports some 1,000 smaller energy-producing dams that do not dis- rupt the natural flow of rivers, cause no environmental impact, and produce cleaner energy.

Large megadams of the type that are being devel- oped around the planet are a tempting and expensive pursuit for the majority of countries undertaking them. With poor project development records historically, including huge cost and schedule overruns, these proj- ects are typically undertaken as much for the national prestige they offer. At the same time, countries that have invested precious budget money in creating the dams are frequently disappointed with the results, including underutilization, decades of financial squeeze and debt obligation, and a failure to realize the expected benefits. When it comes to large megadams, the energy they produce is usually neither abundant nor cheap.25

Questions

1. Given the history of large cost overruns associ- ated with megadam construction, why do you believe they are so popular, especially in the developing world?

2. Develop an argument in support of megadam construction. Develop an argument against these development projects.

288 Chapter 8 • Cost Estimation and Budgeting

CaSE STuDy 8.2 Boston’s Central Artery/Tunnel Project

Since the “Big Dig” project was first introduced in the previous edition of this textbook, a number of addi- tional events have occurred that make it important for us to revisit the original story and update the cur- rent status of this monumental project. When it was opened in 1959, Boston’s Central Artery highway was hailed as a marvel of engineering and forward- thinking urban planning. Designed as an elevated six-lane highway through the middle of the city, the highway was intended to carry a traffic volume of 75,000 vehicles a day. Unfortunately, by the early

1980s, the Central Artery was burdened by a daily volume of more than 200,000 vehicles, a nearly three- fold increase over the anticipated maximum traf- fic levels. The result was some of the worst urban congestion in the country, with traffic locked bum- per to bumper for more than 10 hours each day. At over four times the national average, the accident rate for the Central Artery added to commuters’ misery. Clearly, the Central Artery—a crumbling, overused, and increasingly dangerous stretch of highway—had outlived its usefulness.

M ic

h a e l

D w

ye r/

A la

m y

Figure 8.10 Boston’s Big Dig

The solution to the problem was the advent of the Central Artery/Tunnel (CA/T) project, commonly known to people from the Boston area as the “Big Dig.” Under the supervision of the Massachusetts Turnpike Authority and using federal and state fund- ing, the CA/T project comprises two main elements: (1) replacing the aging elevated roadway with an 8- to 10-lane underground expressway directly beneath the existing road, with a 14-lane, two-bridge crossing of the Charles River, and (2) extending Interstate 90 through a tunnel beneath South Boston and the har- bor to Logan Airport. Originally conceived and initi- ated in the early 1980s, the project was a continuous activity (some would say “headache”) in the city for more than 20 years.

The technical challenges in the Big Dig were enormous. Employing at its peak about 5,000 work- ers, the project included the construction of eight miles of highway, 161 lane miles in all, almost half below ground. It required the excavation of 16 million cubic yards of soil, enough to fill the New England Patriots’ football stadium 16 times, and used 3.8 million cubic yards of concrete. The second major challenge was to perform these activities with- out disrupting existing traffic patterns or having a deleterious effect on the current highway system and its traffic flows. Thus, while miles of tunnels were being excavated underneath the old Central Artery, traffic volume could not be slowed on the elevated highway.

Case Study 8.2 289

The project had been a source of controversy for several years, most notably due to its soaring costs and constantly revised budget. At the time of the project’s kickoff in 1983, the original projections for the project’s scope assumed a completion date of 1998 and one- time funding from the federal government to cover 60% of the project’s original $2.5 billion budget. In fact, the budget and schedule have been revised upward nearly constantly since the project kicked off. Consider the following budget levels:

year Budget (in billions)

1983 2.56

1989 4.44

1992 6.44

1996 10.84

2000 14.08

2003 14.63

Final cost projections soared to over $14.5 billion and the project officially wrapped up in late 2004, or seven years late. Cost estimates and subsequent expen- ditures were so bad that by 2000, a federal audit of the project concluded that the Big Dig was officially bank- rupt. One component of the federal audit concluded that a major cause for runaway project costs was due to poor project management oversight. Specifically, it was found that project management routinely failed to hold contractors to their bids or to penalize them for mistakes, resulting in huge cost increases for the Big Dig. Because of the intense public scrutiny and sensitive nature of the project, managers also stopped tracking or publicly acknowledging escalating costs, fearing that the political backlash could cripple the project. In fact, Taxpayers for Common Sense, a non- partisan watchdog group, charged that the project’s economics became so bad that managers delayed bud- geting for contracts worth $260 million to a consulting firm because they could not offset such a large cost in the short term. In response to public outcry over the delays and rising costs, the project manager submitted his resignation.

Not surprisingly, the citizens of Boston have viewed the opening of the Big Dig with a genuine sense of ambivalence. Though a technological marvel that will undoubtedly improve the lives of its users, while reducing carbon monoxide emissions and improving the “green” reputation of the city, the project proved to be such a financial morass that public officials qui- etly canceled a planned celebration of a major section’s opening. Finger pointing and a search for the causes of the Big Dig’s poor cost estimation and control were

vigorous. For its part, the Massachusetts Turnpike Authority planned a $150 million lawsuit against the firms that managed the project, arguing that many of the cost overruns could be attributed to poor project management and oversight.

Increasingly, the question being asked was: Were original cost estimates for the CA/T given in good faith or were they “tuned” to meet political realities? That is, did officials deliberately underestimate true project costs, fearing that the project would not have been approved in the beginning if the public was aware of its likely cost and scope? If so, the result has been to leave a sour taste in the mouths of the taxpay- ing public, convinced that the CA/T project repre- sents a combination of brilliant technical achievement coupled with poor estimation and lax control. Former Massachusetts House Speaker Thomas Finnerman put the matter directly: “You’d be much, much better off saying upfront, factually, ‘Hey, it’s going to take umpteen years likely and umpteen billions dollars,’ rather than selling it as a kind of smoke and mirrors thing about, ‘Oh, it’s two billion and a couple of years’ work.’”

aftermath: Reconsidering the Big Dig

Since the completion of the Big Dig, you would expect the commotion to have died down, the complaints to have been resolved, and the people of Boston to have become used to the advantages of this enormous proj- ect. Unfortunately, that has not been the case. Since its “completion” in early 2004, bad press, disasters, and accountability continue to dog the Central Tunnel/ Artery system.

In 2001, prior to the completion of the project, thousands of leaks began appearing in the ceiling of sections of the tunnel system. The cause? Records sug- gest that the primary contractor for the concrete pour- ing, Modern Continental, failed to remove debris prior to pouring concrete, resulting in flaws, cavities, and pockets of weakness in the ceiling and walls of the tun- nels. In May 2006, six employees of the main supplier of concrete were arrested for falsifying records.

In fact, 2006 was a very bad year for the Big Dig for a variety of reasons. On July 10, 2006, the bolt and epoxy system holding four sections (12 tons) of con- crete ceiling panels failed, causing a section to collapse onto the tunnel roadway and kill a passenger in a car passing beneath the section at the time. That month, a detailed inspection of the ceiling panels throughout the tunnel system identified an additional 242 bolts that were already showing signs of stress! The tun- nel system was shut down for the month of August for inspection and repairs. Also in August, the state assumed control of the Central Tunnel/Artery from

(continued)

290 Chapter 8 • Cost Estimation and Budgeting

the Turnpike Authority, citing the TA’s poor record of supervision and effective project control.

The tragedy became something close a to farce when the Turnpike Authority and Federal Highway Administration refused to release critical documents to the state, including:

• Deficiency reports flagging initial substandard work

• Construction change orders and contract revisions

• Inspection reports on workmanship and build- ing material quality Until the court system orders the release of all

project documents, we may never know the extent of mismanagement and poor decision making that dogged the development of the CT/A. From a public relations perspective, however, the fighting between state and federal authorities over oversight and con- trol of the troubled project is a continuing black eye for all parties involved.

In early 2008, the contractors for the Big Dig, including primary contractors Bechtel and Parson Brinckerhoff, were ordered to pay $450 million to settle the state’s lawsuit over the 2006 tunnel collapse.

Though this settlement does not absolve the contrac- tors from future lawsuits, it does settle some of the more egregious failures that occurred while they led the project. Michael Sullivan, the U.S. Attorney who led the lawsuit, noted that the contractors originally made a profit of about $150 million from the Big Dig; however, “They lost money as a result of the failures that occurred under their watch.”26

Questions

1. Consider the following statement: “Government- funded projects intended to serve as ‘prestige projects,’ such as the ‘Big Dig,’ should not be judged on the basis of cost.” Do you agree or dis- agree with this statement? Why?

2. Project success is defined as adherence to budget, schedule, functionality (performance), and client satisfaction. Under these criteria, cite evidence that suggests the “Big Dig” project was a success and/or failure.

3. What are the lessons to be learned from the “Big Dig” project? Was this a failure of project esti- mation or project control by the contractors and local government?

internet Exercises 8.1 Go to the Internet and search using the phrase “cost analy-

sis tools.” What are some of the links and examples of cost analysis as it applies to projects?

8.2 Go to http://pmworldlibrary.net/ and type “case studies” in the search window. Select a project and report on it from the perspective of its cost estimation, budgeting, and (if applicable) expediting perspectives. Was the project a suc- cess or failure? Why?

8.3 Go to www.cityofflint.com/DCED/CDBG2013_14/Budget Detail_sample.pdf and reproduce the summary project budget worksheet. After examining the various elements in the budget, what are the main cost drivers for projects of this sort?

8.4 Go to www.stickyminds.com/articles.asp and click on “Stickyminds.com Original Articles.” Search for and click on the article by Karl Wiegers, “Estimation Safety Tips.” In the article (found as a pdf link to the site), the author offers tips on making estimates that are accurate and de- fensible by avoiding common mistakes. Which of these points makes the most sense to you personally? Why does it seem a plausible suggestion?

PMP certificAtion sAMPle QUestions

1. The project administrator is preparing a preliminary budget for a project and adds in the cost of a new com- puter for the project team to use. What type of cost would this computer purchase represent?

a. Variable b. Direct c. Indirect d. Variable direct

2. The project manager for a large project being devel- oped in northern Ontario recognizes that it will be necessary for her to maintain a close presence at the construction site during its development and has negotiated the use of a building for her team near the construction project. The cost of the building must be factored into the project cost and will increase with use; that is, the cost of heating and other utilities is subject to change depending upon weather and team use. What type of cost would this building represent?

a. Variable direct b. Indirect c. Nonrecurring d. None of the above

3. A project budget identifies $5,000 budgeted for program- ming costs. The actual amount for programming costs is $5,450. Which of the following statements is correct?

a. The $450 represents a negative variance to the budget b. There is no variance to the budget c. The $450 represents a positive variance to the

budget d. The entire $5,450 represents a positive variance to

the budget

Internet Exercises 291

4. The project planning phase is moving forward. The project team has solicited the opinions of some senior project managers with experience in similar types of projects to try and develop a cost estimate for the proj- ect. This process is an example of:

a. Activity-based budgeting b. Contingency planning c. Top-down budgeting d. Cost estimation

5. John is putting together his budget for the project and as part of this process, he is actively discussing and so- liciting estimates from each member of the project team for the overall budget. He presents his budget to senior management and Susan rejects it, stating, “Team mem- bers are always going to pad their estimates. I will give

you the figure I want you to shoot for.” Susan is em- ploying what method for project cost budgeting?

a. Bottom-up b. Top-down c. Parametric d. Comparative

Answers: 1. b—A computer purchase would be an example of a direct cost for the project; 2. a—The cost of using a site building varies to the degree it is used and is charged as a direct cost to the project; 3. c—The overrun of $450 would be referred to as a positive variance to the budget; 4. d—The process of asking senior project managers for their best esti- mates of project costs is part of the cost estimation process; 5. b—Susan is using a top-down method in which she, as the senior manager, is providing the project budget estimate.

292 Chapter 8 • Cost Estimation and Budgeting

iNtegrAteD Project

Developing the cost estimates and Budget

Develop an in-depth cost estimate to support your initial project proposal narrative and scope statement, including the Work Breakdown Structure. Create a detailed justification of personnel costs, materials costs, overhead, and other forms of costs that are likely to accrue to your project. Be specific, particularly as regards personnel costs and commitment of time. For example, your cost table could look something like the following:

Personnel level rate loaded

rate labor-Weeks

Needed* total cost

Programmer Senior $35 $49/hr 20 $39,200 Sys. Analyst Junior $22 $31/hr 10 $12,400 *40-hour work week

Remember that the “loaded rate” assumes that you include the organization’s overhead expenses for each employee. A typical multiplier for this figure could run anywhere up to and over 100% of the employee’s wage rate. Make sure the course instructor indicates the overhead rate you should apply for your project. So, using the senior programmer example above with a fully loaded rate and assuming an overhead multiplier of 1.40, we get:

($49) (40 hrs) (20 weeks) (1.40) = $54,880

Sample Project Plan: ABcups, inc.

Name resource

type title

Salary (incl.

Benefits) ($)

Hour rate ($)

fully loaded

rate (overhead = .40)

time Needed (Hours/ week)

Duration (in weeks) total

Carol Johnson

Safety Safety Engineer

64,600 32.30 45.22 10 hrs/wk 15 $ 6,783

Bob Hoskins Engineering Industrial Engineer

35,000 17.50 24.50 20 hrs/wk 35 17,150

Sheila Thomas Management Project Manager

55,000 27.50 38.50 40 hrs/wk 50 77,000

Randy Egan Management Plant Manager

74,000 37.00 51.80 10 hrs/wk 6 3,108

Stu Hall Industrial Maintenance Supervisor

32,000 16.00 22.40 15 hrs/wk 8 2,688

Susan Berg Accounting Cost Accountant

45,000 22.50 31.50 10 hrs/wk 12 3,780

Marty Green Industrial Shop Supervisor

24,000 12.00 16.80 10 hrs/wk 3 504

John Pittman Quality Quality Engineer

33,000 16.50 23.10 20 hrs/wk 25 11,550

Sally Reid Quality Jr. Quality Engineer

27,000 13.50 18.90 20 hrs/wk 18 6,804

Lanny Adams Sales Marketing Manager

70,000 35.00 49.00 10 hrs/wk 16 7,840

Kristin Abele Purchasing Purchasing Agent

47,000 23.50 32.90 15 hrs/wk 20 9,870

Total $147,077

293

t im

e -P

h a se

d B

u d

g e t

fo r

A B

c u

p s,

i n

c. (

A ll v

a lu

e s

in d

o ll

a rs

( $ ))

W o

rk P

a ck

a g

e s

ju n

e ju

ly A

u g

. S e p

t. o

ct .

N o

v. D

e c.

ja n

. f

e b

. M

a r.

A p

ri l

M a

y to

ta ls

Fe as

ib ili

ty 2

,5 0 0

2

,5 0

0

V en

d o r

Se le

ct io

n 7

,6 7 8

3 ,9

3 4

1 ,9

6 0

3 ,9

3 4

1 7

,5 0

6

D es

ig n

1 2 ,5

6 3

8 ,4

0 0

5 ,3

0 0

2 6

,2 6

3

En g in

ee ri n g

9 ,9

9 2

1 4 ,7

9 0

1 5 ,6

0 0

4 0

,3 8

2

Pr o to

ty p e

Te st

in g

3 ,2

5 0

1 2 ,7

4 5

7 ,2

5 0

2 3

,2 4

5

Sa le

s an

d S

er vi

ce

1 ,4

6 7

4 ,4

6 7

1

,9 0

8

7 ,8

4 2

Pa ck

ag in

g

2 ,4

3 4

8

,1 0

1 6

5 0

1 1

,1 8

5

A ss

em b ly

1

,6 7

6

9 ,2

3 4

8 9

0 1

1 ,8

0 0

C lo

se -o

u t

1 ,1

9 8

5

,1 5

6

6 ,3

5 4

M o n th

ly P

la n n ed

1 0 ,1

7 8

3 ,9

3 4

1 4 ,5

2 3

1 2 ,3

3 4

1 5 ,2

9 2

1 8 ,0

4 0

2 9 ,8

1 2

1 4 ,1

5 1

1 1

,6 8

5

9 ,8

8 4

2 ,0

8 8

5

,1 5

6

M o n th

ly C

u m

u la

ti ve

1 0 ,1

7 8

1 4 ,1

1 2

2 8 ,6

3 5

4 0 ,9

6 9

5 6 ,2

6 1

7 4 ,3

0 1

1 0 4 ,1

1 3

1 1 8 ,2

6 4

1 2 9

,9 4

9 1

3 9

,8 3

3 1

4 1

,9 2

1 1

4 7

,0 7

7 1

4 7

,0 7

7

294 Chapter 8 • Cost Estimation and Budgeting

1. Flyvbjerg, B., and Stewart, A. (2012). “Olympic propor- tions: Cost and cost overrun at the Olympics 1960–2012. Said Business School Working Papers, Oxford: University of Oxford; Forrest, Brett. (2014, February 23). “Putin’s run for gold.” Vanity Fair. www.vanityfair.com/culture/ 2014/02/sochi-olympics-russia-corruption; Geere, D. (2014, February 4). “Freezing Sochi: How Russia turned a sub- tropical beach into a Winter Olympics wonderland.” The Verge. www.theverge.com/2014/2/4/5377356/sochi-win- ter-olympics-2014-subtropical-transformation; Rathi, A. (2014, January 30). “The Sochi Olympics are going to be the costliest ever.” Quartz. http://qz.com/172180/the-sochi- olympics-are-going-to-cost-more-than-the-last-13-olympics- combined/; “Sochi road an engineering marvel.” (2014, February 15). BostonGlobe.com. |www.bostonglobe.com/ sports/2014/02/15/sochi-road-engineering-marvel/ dpRwuHty4V35VHR1O5T6SL/story.html; Taylor, A. (2014, January 17). “Why Sochi is by far the most expensive Olympics ever.” Business Insider. www.businessinsider.com/ why-sochi-is-by-far-the-most-expensive-olympics- ever-2014-1; Waldron, T., (2014, February 3). “Sochi Olympics will cost more than every other Winter Olympics combined.” ThinkProgress RSS. http://thinkprogress.org/ sports/2014/02/03/3239131/sochi-olympics-cost-winter- olympics-combined/; Yaffa, J. (2014, January 2). “The waste and corruption of Vladimir Putin’s 2014 Winter Olympics.” Bloomberg Business Week. Bloomberg. www.businessweek. com/articles/2014-01-02/the-2014-winter-olympics-in-so- chi-cost-51-billion#p1; Young, J. (2014, February 3). “Money spent on Sochi games raises questions.” VOA. www. voanews.com/content/money-spent-on-sochi-games-rais- ing-questions/1843380.html.

2. Needy, K. S., and Petri, K. L. (1998). “Keeping the lid on project costs,” in Cleland, D. I. (Ed.), Field Guide to Project Management. New York: Van Nostrand Reinhold, pp. 106–20.

3. Miller, G. J., and Louk, P. (1988). “Strategic manufacturing cost management,” APICS 31st International Conference Proceedings, Falls Church, VA: APICS; Kerzner, H. (1988). “Pricing out the work,” in Cleland, D. I., and King, W. R. (Eds.), Project Management Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp. 394–410.

4. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Management, 5th ed. New York: Wiley.

5. Needy, K. S., and Petri, K. L. (1998). “Keeping the lid on project costs,” in Cleland, D. I. (Ed.), Field Guide to Project Management. New York: Van Nostrand Reinhold, pp. 106–20.

6. Source for Table 8.2: Needy, K. S., and Petri, K. L. (1998). “Keeping the lid on project costs,” in Cleland, D. I. (Ed.), Field Guide to Project Management. New York: Van Nostrand Reinhold, p. 110.

7. Lock, D. (2000). “Managing cost,” in Turner, J. R., and Simister, S. J. (Eds.), Gower Handbook of Project Management, 3rd ed. Aldershot, UK: Gower, pp. 293–322.

8. Amor, J. P., and Teplitz, C. J. (1998). “An efficient approxi- mation for project composite learning curves,” Project Management Journal, 29(3): 28–42; Badiru, A. B. (1995). “Incorporating learning curve effects into critical resource diagramming,” Project Management Journal, 26(2): 38–46;

Camm, J. D., Evans, J. R., and Womer, N. K. (1987). “The unit learning curve approximation of total cost,” Computers in Industrial Engineering, 12: 205–13; Fields, M. A. (1991). “Effect of the learning curve on the capital budgeting process,” Managerial Finance, 17(2–3): 29–41; Teplitz, C. J., and Amor, J. P. (1993). “Improving CPM’s accuracy using learning curves,” Project Management Journal, 24(4): 15–19.

9. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Management, 5th ed. New York: Wiley.

10. Amor, J. P., and Teplitz, C. J. (1998). “An efficient approxi- mation for project composite learning curves,” Project Management Journal, 29(3): 28–42.

11. Crawford, J. R. (n.d.), Learning curve, ship curve, rations, related data. Burbank, CA: Lockheed Aircraft Corp.

12. Heiser, J., and Render, B. (2001). Operation Management, 6th ed. Upper Saddle River, NJ: Prentice Hall.

13. Hackbarth, G. (2005), personal communication. 14. “Extreme chaos.” (2001). Standish Group International. 15. Bloch, M., Blumberg, S., and Laartz, J. (2012). “Delivering

large-scale IT projects on time, on budget, and on value,” McKinsey Reports. http://mckinsey.com/MOBT_27_ Delivering_large-scale_IT_projects_on_time_budget_ and_value%20(1).pdf; Flyvbjerg, B., Budzier, A. (2011). “Why your project may be riskier than you think,” Harvard Business Review, 89(9): 23–25.

16. For a discussion of COCOMO II standards, see http:// csse.usc.edu/csse/research/COCOMOII/cocomo2000.0/ CII_modelman2000.0.pdf

17. McConnell, S. (2004). Code Complete, 2nd ed. Redmond, WA: Microsoft Press; McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Redmond, WA: Microsoft Press.

18. Turbit, N. “Function points overview.” www.projectper- fect.com.au/downloads/Info/info_fp_overview.pdf; International Functional Points Users Group, www.ifpug. org; Dillibabu, R., and Krishnaiah, K. (2005). “Cost esti- mation of a software product using COCOMO II.2000 model—a case study,” International Journal of Project Management, 23(4): 297–307; Jeffery, R., Low, G. C., and Barnes, M. (1993). “A comparison of function point count- ing techniques,” IEEE Transactions on Software Engineering, 19(5): 529–32.

19. Hamburger, D. (1986). “Three perceptions of project cost—Cost is more than a four-letter word,” Project Management Journal, 17(3): 51–58; Sigurdsen, A. (1996). “Principal errors in capital cost estimating work, part 1: Appreciate the relevance of the quantity-dependent esti- mating norms,” Project Management Journal, 27(3): 27–34; Toney, F. (2001). “Accounting and financial manage- ment: Finding the project’s bottom line,” in J. Knutson (Ed.), Project Management for Business Professionals. New York: John Wiley, pp. 101–27; Shtub, A., Bard, J. F., and Globerson, S. (1994). Project Management: Engineering, Technology, and Implementation. Englewood Cliffs, NJ: Prentice-Hall; Smith, N. J. (Ed.). (1995). Project Cost Estimating. London: Thomas Telford; Sweeting, J. (1997). Project Cost Estimating: Principles and Practices. Rugby, UK: Institution of Chemical Engineers; Goyal, S. K. (1975). “A note of a simple CPM time-cost tradeoff algorithm,”

notes

Notes 295

Management Science, 21(6): 718–22; Venkataraman, R., and Pinto, J. K. (2008). Cost and Value Management in Projects. New York: Wiley.

20. Panknin, S., quoted in Grieshaber, K. (2013, April 8). “Berlin’s airport delays shame Germans.” http://news. yahoo.com/berlins-airport-project-delays-shame-ger- mans-093036692–finance.html

21. Flyvbjerg, B., Garbuio, M., and Lavallo, D. (2009). “Delusion and deception in large infrastructure projects: Two models for explaining and preventing executive disaster,” California Management Review, 51(2): 170–93; “Building BRICs of growth.” (2008, June 7). The Economist. www.economist.com/node/11488749; Lovallo, D., and Kahneman, D. (2003). “Delusions of success: How opti- mism undermines executives’ decisions,” Harvard Business Review, 81(7): 56–63; Flyvbjerg, B., Holm, M. S., and Buhl, S. (2002). “Underestimating costs in public works projects: Error or lie?” Journal of the American Planning Association, 68(3): 279–95.

22. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Management, 5th ed. New York: Wiley; see also Christensen, D. S.,

and Gordon, J. A. (1998). “Does a rubber baseline guaran- tee cost overruns on defense acquisition contracts?” Project Management Journal, 29(3): 43–51.

23. Maher, M. (1997). Cost Accounting: Creating Value for Management, 5th ed. Chicago: Irwin.

24. Gray, C. F., and Larson, E. W. (2003). Project Management, 2nd ed. Burr Ridge, IL: McGraw-Hill.

25. Flyvbjerg, B., and Ansar, A. (2014, March 19). “Ending the flood of megadams,” Wall Street Journal, p. A15; Ansar, A., Flyvbjerg, B., Budzier, A., and Lunn, D. (2014). “Should we build more large dams? The actual costs of hydro- power megaproject development.” Energy Policy. http:// dx.doi.org/10.1016/j.enpol.2013.10.069

26. “Boston’s Big Dig opens to public.” (2003, December 20). www.msnbc.com/id/3769829; “Big Dig billions over budget.” (2000, April 11). www.taxpayer.net/library/ weekly-wastebasket/article/big-dig-billions-over-bud- get; “Massachusetts to sue Big Dig companies.” (2006, November 27). www.msnbc.msn.com/id/15917776; “Big Dig contractors to pay $450 million.” (2008, January 23). www.msnbc.msn.com/id/22809747

296

9 ■ ■ ■

Project Scheduling Networks, Duration Estimation, and Critical Path

Chapter Outline Project Profile

After 20 Years and More than $50 Billion, Oil Is No Closer to the Surface: The Caspian Kashagan Project

introduction 9.1 Project Scheduling 9.2 Key Scheduling terminology 9.3 develoPing A networK

Labeling Nodes Serial Activities Concurrent Activities Merge Activities Burst Activities

9.4 durAtion eStimAtion 9.5 conStructing the criticAl PAth

Calculating the Network The Forward Pass

The Backward Pass Probability of Project Completion Laddering Activities Hammock Activities Options for Reducing the Critical Path

Project mAnAgement reSeArch in Brief Software Development Delays and Solutions

Summary Key Terms Solved Problems Discussion Questions Problems Internet Exercises MS Project Exercises PMP Certification Sample Questions Notes

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

1. Understand and apply key scheduling terminology. 2. Apply the logic used to create activity networks, including predecessor and successor tasks. 3. Develop an activity network using Activity-on-Node (AON) technique. 4. Perform activity duration estimation based on the use of probabilistic estimating techniques. 5. Construct the critical path for a project schedule network using forward and backward passes. 6. Identify activity float and the manner in which it is determined. 7. Calculate the probability of a project finishing on time under PERT estimates. 8. Understand the steps that can be employed to reduce the critical path.

Project MAnAgeMent Body of Knowledge core concePts covered in this chAPter

1. Plan Schedule Management (PMBoK sec. 6.1) 2. Define Activities (PMBoK sec. 6.2) 3. Sequence Activities (PMBoK sec. 6.3) 4. Estimate Activity Resources (PMBoK sec. 6.4) 5. Estimate Activity Durations (PMBoK sec. 6.5) 6. Develop Schedule (PMBoK sec. 6.6) 7. Control Schedule (PMBoK sec. 6.7)

Project Profile

After 20 Years and More than $50 Billion, oil is No closer to the Surface: the caspian Kashagan Project

Two decades ago, the world was in desperate need of new sources of oil, just as emerging economies were anxious to exploit their natural resources in exchange for improvements in the standard of living. It was against this backdrop that the Kashagan oil project was launched. A partnership between Kazakhstan and a consortium of oil exploration companies (including Shell, Exxon Mobil, Total, ConocoPhillips, and Eni, among others), the Kashagan project involved offshore drilling in the Caspian Sea. The oil field was discovered in 2000, and with oil reserve estimates that are said to be the largest in the world outside of the Middle East, the plan was for oil to begin flowing in 2005, with a projected daily output of 1.5 million barrels. One Shell driller labeled the field “an Elephant.”

Now, years behind schedule and with a budget that has grown from its original total estimate of $57 billion to $187 billion, the project is still far from completed. Phase 1 of the project was expected to cost $24 billion and the bill has already grown to $46 billion with little to show for it. In addition to its massive budget overruns, the project has been continuously plagued by a series of engineering missteps, management disputes, miles of leaky and corroded pipelines, and technical problems. So bad has the situation become that the project has now been halted indefinitely while all parties try to understand what went wrong and how to get things back on track.

The Kashagan project’s problems come at a time when relationships between Western oil companies and resource-owning governments are more important than ever. To replace what they pump, oil companies need to col- laborate with state-owned companies that control 90% of the globe’s remaining oil reserves, by a World Bank estimate.

Figure 9.1 Kashagan oil field

Source: Shamil Zhumatov/Reuters/Corbis

Project Profile 297

298 Chapter 9 • Project Scheduling

introduction

Project scheduling is a complex undertaking that involves a number of related steps. When we think about scheduling, it helps if we picture a giant jigsaw puzzle. At first, we lay out the border and start creating a mental picture in our heads of how the pieces are designed to fit together. As the border starts to take shape, we can add more and more pieces, gradually giving the puzzle shape and image. Each step in building the puzzle depends on having done the previous work correctly. In a similar way, the methodologies in project scheduling build upon each other. Project scheduling requires us to follow some carefully laid-out steps, in order, for the schedule to take shape. Just as a jigsaw puzzle will eventually yield a finished picture if we have followed the process correctly, the shape of the project’s schedule will also come into direct focus when we learn the steps needed to bring it about.

But governments often give foreign oil companies access only to the hardest-to-develop acreage. Kashagan’s disastrous overruns show how these “public/private” collaborations in difficult oil fields can quickly go bad for both sides.

Kashagan is a complicated project under the best of circumstances. The oil derricks sited offshore had to be redesigned atop “islands” that were built for them when it was discovered that the Caspian is shallow enough at this location that it freezes all the way to the bottom during the winter, making drilling with conventional rigs impossible. The companies had to build artificial islands of rock and rubble and drill through these. Further, the oil is under high pressure from corrosive natural gas high in toxic chemicals. That meant building a sulfur-removal system onshore, reached by a pipeline, for the portion of the gas to be recovered. It took operators nearly two years to factor this level of sour gas into infrastructure design. And heavy pipe-laying machines sometimes broke down in the cold.

A number of circumstances have contributed to the schedule delays and budget overruns, including:

• Administrative confusion as the major contractors could not decide who would be in charge of the development. When Exxon Mobil originally attempted to take charge, Shell executives threatened to pull out of the partnership. Ultimately, the much smaller Eni SpA was named lead contractor, although each company had veto power over all major planning decisions.

• Relationships with the Kazakhstan government have deteriorated as the project has experienced delay after delay. By 2008, the government began levying penalties for the extended delays, making the oil companies’ investment in the project all the more expensive. Eni Chief Executive Paolo Scaroni said his company’s relationship with the government “has been excellent” considering the years of trouble. A senior official of Kazakhstan’s state-owned oil company, KMG, disagreed. “It’s a marriage that is made in hell,” he said.

• Problems with human resources assigned to the project. As part of the agreement with the local government, oil companies had to employ large numbers of local workers, with a portion of them mandated to perform office func- tions. One former official recalled hiring hundreds of enthusiastic locals who had “never sat in front of a computer.”

• Leaking pipes. In 2013, the companies prepared for a milestone: starting commercial oil production and transfer- ring the role of operator to a Shell-led group. On September 11, the companies announced that oil was flowing. About two weeks after that, parts of the underground gas pipeline began leaking into the Caspian Sea. Oil pumping stopped while workers inspected and found a leak. Crews patched it, and oil pumping resumed. Two weeks later, the pipeline sprang new leaks. This time, the companies shut down the whole Kashagan operation. Workers spent the fall excavating parts of the 55-mile pipeline and sending section for tests at a UK lab.

• Technical errors. The oil companies used outdated Russian cruise line ships as floating barracks for oil workers. How- ever, besides these construction-worker barracks, offshore accommodations for the permanent staff were needed. Around 2005, Eni’s partners realized that plans for these put them too near a production site. Eni redesigned the accommodations, delaying construction by another year.

The series of missteps and technical challenges has left everyone feeling dissatisfied. Oil company and Kazakh officials sniped at one another. “Nobody’s happy with the governance, and I don’t think anybody’s happy with the operatorship,” Shell Chief Financial Officer Simon Henry said. Cracks were found in several places along the pipeline, according to people familiar with the inspection, who said it appeared the metal had lost some of its factory character- istics, possibly through a combination of poor welding practices and the natural gas’s hydrogen-sulfide content.

Finally, the combination of technical challenges, unexpected (and unresolved) pipeline leaks, finger-pointing by executives from Kazakhstan and the oil companies, and stiff financial penalties for delays became too much for some of the consortium. In 2013, longtime partner ConocoPhillips sold its stake in the project to KMG, which later resold it to China National Petroleum Corp. “We got our $5.5 billion in the bank and got out of Kashagan,” said Al Hirshberg, a Conoco executive, at a conference last fall. He added: “It feels good to be out of it.”1

9.1 Project Scheduling 299

9.1 Project Scheduling

Project scheduling techniques lie at the heart of project planning and subsequent monitoring and control. Previous chapters have examined the development of vision and goals for the project, project screening activities, risk management practices, and project scope (including the Work Breakdown Structure). Project scheduling represents the conversion of project goals into an achiev- able methodology for their completion; it creates a timetable and reveals the network logic that relates project activities to each other in a coherent fashion. Because project management is predi- cated on completing a finite set of goals under a specified time frame, exactly how we develop the project’s schedule is vitally important to success.

This chapter will examine a number of elements in project scheduling and demonstrate how to build the project plan from a simple set of identified project activities into a graphical set of sequential relationships between those tasks which, when performed, result in the comple- tion of the project goals. Project scheduling has been defined by the Project Management Body of Knowledge as “an output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.”2 The term linked activities is important because it illus- trates the scheduling goal. Project scheduling defines network logic for all activities; that is, tasks must either precede or follow other tasks from the beginning of the project to its completion.

Suppose you and your classroom team were given an assignment on leadership and were expected to turn in a paper and give a presentation at the end of the semester. It would first be nec- essary to break up the assignment into the discrete set of individual activities (Work Breakdown Structure) that would allow your team to finish the project. Perhaps you identified the following tasks needed to complete the assignment:

1. Identify topic 2. Research topic 3. Write first draft of paper 4. Edit and rewrite paper 5. Prepare class presentation 6. Complete final draft 7. Complete presentation 8. Hand in paper and present topic in class

Carefully defining all the steps necessary to complete the assignment is an important first step in project scheduling as it adds a sequential logic to the tasks and goes further in that it allows you to create a coherent project plan from start to finish. Suppose, to ensure the best use of your time and availability, you were to create a network of the activities listed above, that is, the most likely order in which they must occur to be done correctly. First, it would be necessary to determine a reason- able sequence. Preceding activities are those that must occur before others can be done. For example, it would be necessary to first identify the term paper topic before beginning to conduct research on it. Therefore, activity 1, Identify topic, is a preceding activity; and activity 2, Research topic, is referred to as a subsequent, or successor, activity.

Once you have identified a reasonable sequential logic for the network, you can construct a network diagram, which is a schematic display of the project’s sequential activities and the logical relationships between them. Figure 9.2 shows two examples of a network diagram for your proj- ect. Note that in Option A, the easiest method for constructing a network diagram is to simply lay out all activities in serial order, starting with the first task and concluding with the final activity. This option, however, is usually not the most efficient one. It could be argued, for example, that it is not necessary that the whole project team be involved in each of the activities, requiring you to delay the start of activity 6, Complete final draft (F in Figure 9.2), until after activity 5, Prepare class presentation. Another choice might be to use the time better by having some members of the team begin work on the presentation while others are still completing the paper. Any of these options mean that you are now constructing a project network with two paths, or parallel streams of activi- ties, some of which are going on simultaneously. This alternative network can be seen in Option B of Figure 9.2.

This simplified example illustrates the process of applying sequential logic to project tasks in order to construct an activity network. In creating a sense of timing for activities in addi- tion to their functions, the activity network allows project teams to use a method for planning

300 Chapter 9 • Project Scheduling

and scheduling. There are several reasons why it is so important that project networks and sched- uling be done well. Among the reasons are the following:3

• A network clearly illustrates the interdependence of all tasks and work packages. Doing something wrong earlier in the project has severe implications for downstream activities.

• Because a network illustrates this interrelationship among activities and project personnel, it facilitates communication flows. People are much more attuned to the work that went on before their involvement, and they develop a keener appreciation of the concerns of those who will take over at later points.

• A network helps with master scheduling of organizational resources because it shows times when various personnel must be fully committed to project activities. Without some sense of where the project fits into the overall organizational scheme, personnel may be assigned to multiple activities at a time when they are most needed on the project.

• A network identifies the critical activities and distinguishes them from the less critical. The network reveals the activities that absolutely must be completed on time to ensure that the overall project is delivered on time; in the process, activities that have some “wiggle room” are identified as well.

• Networks determine when you can expect projects to be completed. • Dates on which various project activities must start and end in order to keep to the overall

schedule are identified in a network. • A network demonstrates which activities are dependent on which other activities. You then

know the activities that need to be highly coordinated in order to ensure the smooth develop- ment of the project.

These are just some of the advantages of using activity networks for project scheduling.

9.2 Key Scheduling terminology

Every profession has its unique jargon and terminology. In project scheduling, a number of specific terms are commonly employed and so need specific definitions. In many cases, their definitions are taken from the Project Management Institute’s Body of Knowledge. Some concepts that you

Option B: Nonserial Sequential Logic

A Identify topic

B Research

C Paper draft

H Finish

D Edit paper

E Prepare

presentation

F Final draft

G Finish

presentation

Figure 9.2 Alternative Activity Networks for term Paper Assignment

Option A: Serial Sequential Logic

A Identify topic

B Research

C Paper draft

D Edit paper

E Prepare

presentation

F Final draft

G Finish

presentation

H Finish

9.2 Key Scheduling Terminology 301

will see again and again throughout this chapter (and subsequent chapters) are listed here. You have already run across some of these terms in previous chapters.

scope—The work content and products of a project or component of a project. Scope is fully described by naming all activities performed, the resources consumed, and the end products that result, including quality standards. work Breakdown structure (wBs)—A task-oriented “family tree” of activities that orga- nizes, defines, and graphically displays the total work to be accomplished in order to achieve the final objectives of a project. Each descending level represents an increasingly detailed definition of the project objective. work package—A deliverable at the lowest level of the Work Breakdown Structure; it is an ele- ment of work performed during the course of a project. A work package normally has an expected duration plus an expected cost. Other generic terms for project work include task or activity. Project network diagram (Pnd)—Any schematic display of the logical relationships of project activities. Path—A sequence of activities defined by the project network logic. event—A point when an activity is either started or completed. Often used in conjunction with AOA networks, events consume no resources and have no time to completion associ- ated with them. node—One of the defining points of a network; a junction point joined to some or all of the others by dependency lines (paths). Predecessors—Those activities that must be completed prior to initiation of a later activity in the network. successors—Activities that cannot be started until previous activities have been completed. These activities follow predecessor tasks. early start (es) date—The earliest possible date on which the uncompleted portions of an activity (or the project) can start, based on the network logic and any schedule constraints. Early start dates can change as the project progresses and changes are made to the project plan. late start (ls) date—The latest possible date that an activity may begin without delaying a specified milestone (usually the project finish date). forward pass—Network calculations that determine the earliest start/earliest finish time (date) for each activity. The earliest start and finish dates are determined by working forward through each activity in the network. Backward pass—Calculation of late finish times (dates) for all uncompleted network activi- ties. The latest finish dates are determined by working backward through each activity. Merge activity—An activity with two or more immediate predecessors (tasks flowing into it). Merge activities can be located by doing a forward pass through the network. The PMBoK refers to merge activities as “path convergence.” Burst activity—An activity with two or more immediate successor activities (tasks flowing out from it). Burst activities can be located by doing a backward pass through the network. The PMBoK refers to burst activities as “path divergence.” float—The amount of time an activity may be delayed from its early start without delaying the finish of the project. Float is a mathematical calculation and can change as the project pro- gresses and changes are made in the project plan. Also called slack, total float, and path float. In general, float is the difference between the late start date and the early start date (LS − ES) or between the late finish date and early finish date (LF − EF). critical path—The path through the project network with the longest duration. The critical path may change from time to time as activities are completed ahead of or behind schedule. Critical path activities are identified as having zero float in the project. critical Path Method (cPM)—A network analysis technique used to determine the amount of scheduling flexibility (the amount of float) on various logical network paths in the project sched- ule network, and to determine the minimum total project duration. It involves the calculation of early (forward scheduling) and late (backward scheduling) start and finish dates for each

302 Chapter 9 • Project Scheduling

activity. Implicit in this technique is the assumption that whatever resources are required in any given time period will be available. Activities times are assumed to be known, or deterministic. resource-limited schedule—A project schedule whose start and finish dates reflect expected resource availability. The final project schedule should always be resource-limited. Program evaluation and review technique (Pert)—An event- and probability-based net- work analysis system generally used in projects where activities and their durations are dif- ficult to define. PERT is often used in large programs where the projects involve numerous organizations at widely different locations.

The two most common methods for constructing activity networks involve Activity-on-Arrow (AoA) and Activity-on-node (Aon) logic. In the AOA method, the arrow represents the task, or activity, and the node signifies an event marker that suggests the completion of one activity and the potential to start the next. In AON methodology, the node represents an activity and the path arrows demonstrate the logical sequencing from node to node through the network. AOA approaches were most popular several decades ago and are still used to some extent in the con- struction industry, but with the rapid rise in computer-based scheduling programs, there is now a strong emphasis on AON methodology. Hence, in this chapter, we use AON examples and dia- grams exclusively. Chapter 10 will discuss the rudiments of AOA network modeling.

9.3 develoPing a networK

Network diagramming is a logical, sequential process that requires you to consider the order in which activities should occur to schedule projects as efficiently as possible. There are two primary methods for developing activity networks, PERT and CPM. PERT, which stands for Program Evaluation and Review Technique, was developed in the late 1950s in collaboration between the U.S. Navy, Booz- Allen Hamilton, and Lockheed Corporation for the creation of the Polaris missile program. PERT originally was used in research and development (R&D), a field in which activity duration estimates can be difficult to make, and resulted from probability analysis. CPM, or Critical Path Method, was developed independently at the same time as PERT by DuPont, Inc. CPM, used commonly in the con- struction industry, differs from PERT primarily in the assumptions it makes about estimating activity durations. CPM assumes that durations are more deterministic; that is, they are easier to ascertain and can be assigned to activities with greater confidence. Further, CPM was designed to better link (and therefore control) project activity time and costs, particularly the time/cost trade-offs that lead to crashing decisions (speeding up the project). Crashing the project will be explained in more detail in Chapter 10. In practice, however, over the years the differences between PERT and CPM have blurred to the point where it is now common to simply refer to these networking techniques as PERT/CPM.4

Prior to constructing an activity network, there are some simple rules of thumb you need to become familiar with as you develop the network diagram. These rules are helpful in understand- ing the logic of activity networks.5

1. Some determination of activity precedence ordering must be done prior to creating the net- work. That is, all activities must be logically linked to each other—those that precede others, as well as successor activities (those that must follow others).

2. Network diagrams usually flow from left to right. 3. An activity cannot begin until all preceding connected activities have been completed. 4. Arrows on networks indicate precedence and logical flow. Arrows can cross over each other,

although it is helpful for clarity’s sake to limit this effect when possible. 5. Each activity should have a unique identifier associated with it (number, letter, code, etc.).

For simplicity, these identifiers should occur in ascending order; each one should be larger than the identifiers of preceding activities.

6. Looping, or recycling through activities, is not permitted. 7. Although not required, it is common to start a project from a single beginning node, even in

the case when multiple start points are possible. A single node point also is typically used as a project end indicator.

With these simple rules of thumb firmly in mind, you can begin to uncover some of the basic prin- ciples of establishing a network diagram. Remember that AON methodology represents all activi- ties within the network as nodes. Arrows are used only to indicate the sequential flow of activities from the start of the project to its conclusion.

9.3 Developing a Network 303

labeling nodes

Nodes representing project activities should be clearly labeled with a number of different pieces of information. It is helpful if the nodes at least contain the following data: (1) identifier, (2) descrip- tive label, (3) activity duration, (4) early start time, (5) early finish time, (6) late start time, (7) late finish time, and (8) activity float. Figure 9.3 shows the labeling for a node with each piece of infor- mation assigned to a location within the activity box. The arrangement selected for this node was arbitrary; there is no accepted standard for labeling activity nodes. For example, the node shown in Figure 9.4 was derived from a standard Microsoft Project 2013 output file. Note that in this example, the activity start and finish dates are shown, as well as the resource person responsible for the activity’s completion.

Complete labels on activity nodes make it easier to use the network to perform additional calculations such as identifying critical path, activity float (or slack), total project duration, and so on. When constructing network diagrams during the early development of the project, all necessary information about the activity can be retrieved quickly as long as nodes are fully labeled.

Serial activities

serial activities are those that flow from one to the next, in sequence. Following the logic of Figure 9.5, we cannot begin work on activity B until activity A has been completed. Activity C cannot begin until both activities A and B are finished. Serial activity networks are the simplest in that they create only linkages of activity sequencing. In many cases, serial networks are appro- priate representations of the project activities. Figure 9.5 demonstrates how, in the earlier exam- ple of preparing for a term paper and presentation, several activities must necessarily be linked serially. Identifying the topic, conducting research, and writing the first draft are activities that must link in series, because subsequent activities cannot begin until the previous (predecessor) ones have been completed.

network logic suggests that:

Activity A can begin immediately. Activity B cannot begin until activity A is completed. Activity C cannot begin until both activities A and B are completed.

concurrent activities

In many circumstances, it is possible to begin work on more than one activity simultaneously, assuming that we have the resources available for both. Figure 9.6 provides an example of how

Early start

Identifier number Early finish

Activity float

Activity descriptor

Late start

Activity duration

Late finish

Figure 9.3 labels for Activity Node

2. Research Topic

Start: 6/13/14 ID: 2

Finish: 7/3/14 Dur:15 days

Res: John Smith

Figure 9.4 Activity Node labels Using MS Project 2013

Source: MS Project 2013, Microsoft Corporation.

A Identify topic

B Research

C Paper draftFigure 9.5 Project Activities linked

in Series