Jack R. Meredith, Samuel J. Mantel Jr. - Project Management A Managerial Approach (2011, Wiley) - PDFCOFFEE.COM (2024)

This page intentionally left blank

New books include these software packages: Microsoft Project® Trial Edition Crystal Ball® Trial Edition from Oracle

More Information For more information about Microsoft Project®, go to: http://www.microsoft.com/project For information about a FREE 3-year membership to the MSDN Academic Alliance, go to: http://msdn.microsoft.com/academic/ For more information about Crystal Ball®, go to: http://www.crystalball.com/

Technical Support Wiley technical support for Microsoft Project® http://www.wiley.com/techsupport Oracle tech support for Crystal Ball® http://www.crystalball.com/support_center.html

Online Resources for Students http://www.wiley.com/college/meredith •mWeb Quizzes, PowerPoint® Slides •mMicrosoft Project Manual •mAppendix A: Probability and Statistics •mAppendix B: Answers to Even-Numbered Problems •mCreativity and Idea Generation •mTechnological Forecasting

Location of Materials for the Project Management Body of Knowledge (PMBOK) Areas Area 1: Project Integration Management: Section 6.4 Area 2: Project Scope Management: Sections 4.3, 6.1, 11.3, 11.4 Area 3: Project Time Management: Chapters 6, 8, 10, 11 Area 4: Project Cost Management: Chapters 7, 9 Area 5: Project Quality Management: Chapters 6, 12 Area 6: Project Human Resource Management: Chapters 3, 4 Area 7: Project Communications Management: Sections 3.2, 3.4, 4.1, 4.2 Area 8: Project Risk Management: Sections 6.1, 6.5, 7.3, Chapters 10, 11 Area 9: Project Procurement Management: Sections 2.6, 6.4

This page intentionally left blank

Textbook Trialware

Free 140-day Trial of Crystal Ball Software Compliments of the Crystal Ball Education Alliance

KEEP THIS CARD!! See instructions below to download Oracle Crystal Ball software

1

Visit http://www.oracle.com/technology/products/bi/crystalball (REGISTER)

2

Click on the Downloads Tab, accept license agreement

3

Download and install Oracle Crystal Ball software

4

Enter the information below when prompted during installation

username: Meredith 8th Edition 9780470533024 serial number: 72133FCE-3FAA13F5-420192E0-EBE202F5 This is a time-limited version of Crystal Ball software. Trial software is permitted for one installation only. For installation instructions and troubleshooting tips please visit http://www.oracle.com/crystalball. Crystal Ball and Oracle are registered trademarks of Oracle Corporation.

This page intentionally left blank

EIGHTH EDITION

PROJECT MANAGEMENT A Managerial Approach

This page intentionally left blank

EIGHTH EDITION

PROJECT MANAGEMENT A Managerial Approach

Jack R. Meredith Broyhill Distinguished Scholar and Chair in Operations Wake Forest University

Samuel J. Mantel, Jr. Joseph S. Stern Professor Emeritus of Operations Management University of Cincinnati

John Wiley & Sons, Inc.

DEDICATION To Avery and Mitchell, from “papajack.” J. R. M.

To Maggie and Patty for their help, support, and affection. S. J. M.

VICE PRESIDENT AND PUBLISHER George Hoffman EXECUTIVE EDITOR Lise Johnson ASSISTANT EDITOR Sarah Vernon EDITORIAL ASSISTANT Melissa Solarz MARKETING MANAGER Kelly Simmons MARKETING ASSISTANT Ashley Tomeck EXECUTIVE MEDIA EDITOR Allison Morris ASSOCIATE MEDIA EDITOR Elena Santa Maria CREATIVE DIRECTOR Harold Nolan DESIGNER Maureen Eide SENIOR PHOTO EDITOR Lisa Gee PRODUCTION MANAGER Dorothy Sinclair SENIOR PRODUCTION EDITOR Trish McFadden PRODUCTION MANAGEMENT SERVICES Ingrao Associates COVER DESIGN Maureen Eide COVER PHOTO © Yauhen Susio/Fotolia This book was set in Times 10.5/12 pts by MPS Limited, a Macmillan Company, Chennai, India and printed and bound by RRD/Jefferson City. The cover was printed by RRD/Jefferson City. This book is printed on acid free paper. 7e: 11/24/08 6e: 11/17/05 5e: 12/6/02 4e: 11/17/99 3e: 12/16/94 Copyright © 2012 John Wiley & Sons, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978)750-8400, fax (978)750-4470 or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774, (201)748-6011, fax (201)748-6008, or online at http://www.wiley.com/go/permissions. Evaluation copies are provided to qualified academics and professionals for review purposes only, for use in their courses during the next academic year. These copies are licensed and may not be sold or transferred to a third party. Upon completion of the review period, please return the evaluation copy to Wiley. Return instructions and a free of charge return shipping label are available at www.wiley.com/go/returnlabel. Outside of the United States, please contact your local representative. ISBN-13 ISBN-10

9780470533024 0470533021

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

Preface

APPROACH The use of projects and project management continues to grow in our society and its organizations. We are able to achieve goals through project organization that could be achieved only with the greatest of difficulty if organized in traditional ways. Though project management has existed since before the days of the great pyramids, its use has virtually exploded since the mid-1990s. Businesses regularly use project management to accomplish unique outcomes with limited resources under critical time constraints. In the service sector of the economy, the use of project management to achieve an organization’s goals is even more common. Advertising campaigns, voter registration drives, political campaigns, a family’s annual summer vacation, and even management seminars on the subject of project management are organized as projects. A relatively new growth area in the use of project management is the use of projects as a way of accomplishing organizational change. Indeed, there is a rapid increase in the number of firms that use projects as the preferred way of accomplishing almost everything they undertake. As the field has grown, so has its literature. There are now professional books and booklets covering every imaginable aspect of project management: earned value calculations, team building, cost estimating, purchasing, project management software, scheduling, leadership, and so on. These are valuable for experienced project managers who can profit from advanced knowledge on specific topics. There are also handbooks—collections of articles written mainly by academics and consultants on selected topics of interest to project managers, somewhat akin to a summarized compilation of the books and booklets just noted. When we wrote the first edition of this textbook in 1983, there weren’t any textbooks for those interested in learning project management, only professional books. Now, however, there are a few, each using a different approach to learning the subject. One approach has been to take a behavioral orientation toward the subject, since teamwork is a key characteristic of projects. Another approach is to cover the basics, or tools, of project management in a straightforward and crisp manner. A third approach is to take a functional perspective, usually either engineering or information systems, since so many projects are engineering or IS endeavors. The approach we have used takes a managerial perspective. That is, it addresses project management from the perspective of what the project manager will encounter, both chronologically during the “life cycle” of the project as well as practically, in the sense of what the project manager needs to know and why. With this approach we hope that our educated future project managers understand not only the behaviors, tools, and topics of project

vii

viii

PREFACE

management but also the context so they can apply, or change, the behaviors and tools for each unique situation they face in their projects. This managerial perspective, we believe, addresses the basic nature of managing all types of projects—public, business, engineering, information systems, and so on—as well as the specific techniques and insights required to carry out this unique way of getting things done. It also deals with the problems of selecting projects, initiating and planning them, executing and controlling them, and finally evaluating and terminating them. It discusses the demands made on the project manager and the nature of the manager’s interaction with the rest of the parent organization. And the book covers the difficult problems associated with conducting a project using people and organizations that represent different cultures and may be separated by considerable distances. Finally, it even covers the issues arising when the decision is made to terminate a project. The book is primarily intended for use as a college textbook for teaching project management at the advanced undergraduate or master’s level. The book is also intended for current and prospective project managers who wish to share our insights and ideas about the field. We have drawn freely on our personal experiences working with project managers and on the experience of friends and colleagues who have spent much of their working lives serving as project managers in what they like to call the “real world.” Thus, in contrast to the books described earlier about project management, this book teaches students how to do project management. As well as being a text that is equally appropriate for classes on the management of service, product, or engineering projects, we have found that information systems (IS) students in our classes find the material particularly helpful for managing their IS projects. Thus, we have included some coverage of material concerning information systems and how IS projects differ from and are similar to regular business projects.

ORGANIZATION AND CONTENT Given this managerial perspective, we have arranged the book to use the project life cycle as the primary organizational guideline. In this eighth edition we have altered the organization slightly to demark more clearly the activities that occur before the launch of the project, setting up those activities that have to do with the context (or initiation) of the project in the first part of the book, and those that have to do with the planning for the project in the second part. Actually executing the project to completion constitutes the third part of the book. Each part consists of four chapters, which seems to be a comfortable and easy framework for the reader. Following an introductory chapter that comments on the role and importance of projects in our society and discusses project management as a potential career for aspiring managers, the book covers the context, events, and issues arising during the management of projects in the order in which they usually occur in the life of a project. Part I, Project Initiation concerns the context of the project, which is crucial for the project manager to understand if he or she is to be successful in executing the project. It begins with a description of how projects are selected for implementation, frequently based on their tie to the organization’s strategy and goals. Part I also covers the many roles and responsibilities of the project manager, the skills the project manager needs for handling conflict, and the various ways of setting up the project within the organization’s reporting structure (including how different ways of organizing projects tend to create different problems for project managers and their teams). Part II, Project Planning then moves into the planning processes starting with the major tools used in project activity and risk planning. This is followed by project budgeting,

PREFACE

ix

project scheduling, and finally, resource allocation among the activities. Part III, Project Execution finally gets into the action, beginning with monitoring the activities, largely through information systems, and then controlling them to assure that the results meet expectations. Evaluating and possibly auditing the project at its major milestones or phase-gates is another, though separate, control action that senior management often employs, and last, the project must be terminated. We have relegated the discussion of two important aspects of projects that usually occur very early in the project life cycle—creativity/idea generation and technological forecasting—to the book’s Web site. Although few project managers engage in either of these tasks (typically being appointed to project leadership after these activities have taken place), we believe that a knowledge of these subjects will make the project manager more effective. In writing this text we assume that all readers have taken an elementary course in management or have had equivalent experience, and are familiar with some basic principles of probability and statistics. (Appendix A on the Web site (http://www.wiley.com/college/ meredith) can serve as an initial tutorial on the subject or as a refresher for rusty knowledge.) Any approach chosen to organize knowledge carries with it an implication of neatness and order that rarely occurs in reality. We are quite aware that projects almost never proceed in an orderly, linear way through the stages and events we describe here. The need to deal with change and uncertainty is a constant task for the project manager. We have tried to reflect this in repeated references to the organizational, interpersonal, economic, and technical glitches that create crises in the life cycle of every project, and thus in the life of every project manager. Finally, although we use a life-cycle approach to organization, the chapters include material concerning the major areas of the Project Management Body of Knowledge (PMBOK®) as defined by the Project Management Institute. (See Bibliography for Chapter 1.) Anyone wishing to prepare for PMI certification (see Chapter 1) in some of these areas may have to go beyond the information covered in this text.

PEDAGOGY Because this book is primarily a textbook, we have included numerous pedagogical aids to foster this purpose. As in earlier editions, short summaries appear at the end of the text of each chapter, followed by glossaries defining key terms and concepts introduced in the chapter. End-of-chapter materials also include review questions and problems revisiting the materials covered in the chapter. The answers (though not the detailed solutions) to the even-numbered problems are on the book’s Web site. There are also sets of conceptual discussion questions intended to broaden the students’ perspectives and to force them to think beyond the chapter materials to its implications. To keep our attitude in perspective, we occasionally offer Dilbert® cartoons appropriate to the topic under discussion. Finally, there are questions covering the many Project Management in Practice application examples located throughout the chapters. As in the past, we include incidents for discussion, which are brief “caselettes” oriented primarily toward the specific subjects covered in the chapter, but sometimes materials and concepts covered in earlier chapters. We also offer a continuing integrative class project for those users who prefer a running case throughout the chapters that builds on the chapter materials as students progress through the book. And at the very end of each chapter we typically offer a reading and/or a case, with potential discussion questions at the end of each.

x

PREFACE

WHAT’S NEW In this edition, we have made many updates, additions, and changes.

• • •

Continuing our effort to simplify and shorten the writing, we have eliminated many of the historical explanations of the derivation of particular tools and subjects, as well as descriptions of equivalent topics in other fields, particularly systems engineering. One of the authors’ sons, an Intel Corp. engineer, upon reading this book, had vociferous complaints about obscure Latin words and historical references, so we eliminated most (though not quite all) of these. Equally irritating to him, and to some of the reviewers as well, was our habit of constantly referring to locations where a topic would be again discussed in upcoming chapters, most of which we also eliminated.

We have also put a major effort into aligning the book with the 4th edition (2008) of PMBOK® in multiple ways.

• • • • •

First, we combined most of the risk techniques and discussion throughout the book into Chapter 6, now called “Project Activity and Risk Planning,” although we still discuss risk when talking about project selection, budgeting, and control. In the risk discussion we now include examples of FMEA, cause-effect diagrams, risk matrices, and decision trees. We moved the risk technique of simulating costs with Crystal Ball® from Chapter 2 to Chapter 7: “Budgeting: Estimating Costs and Risks.” Reviewers were concerned that introducing simulation so early in Chapter 2 not only was tackling a difficult subject too early but also made the chapter too long—moving it to Chapter 7 not only gives the student more time to digest the subject but also puts it where it belongs in the costs chapter, which was short to begin with. We also followed PMBOK in dropping the concept of the Action Plan in Chapter 6 and instead use the work breakdown structure (WBS) to lay the foundation for project planning. We also dropped the concepts of a “master schedule” as well as that of a “project plan,” instead referring to the project “charter.” Last, we refer to the PMBOK more frequently in our discussions, and when we do, we identify where in PMBOK that topic is covered. Similar to our aggregating most of the risk topics in one chapter, we also aggregated most of the discussion of “scope creep” in Chapter 11: Project Control. We do mention scope creep in many places throughout the book but the major discussion, including how it arises and how to control it, now is aggregated in Chapter 11. Last, we have added a lot more Project Management in Practice examples (sidebars) from the very recent literature (mostly 2010), and deleted some older ones. As well, we have slimmed down some of the lengthy older ones to focus more directly on their message. New discussion questions have been added for the new PMIP examples also, of course.

As before, a student version of Crystal Ball®, an Excel® add-in, again comes with the book. This software makes simulation reasonably straightforward and not particularly complicated. The use of simulation as a technique for risk analysis is demonstrated in several ways in different chapters. (Because relatively few students are familiar with simulation software, step-by-step instruction is included in the text.)

PREFACE

xi

Microsoft Project® has become the dominant application software in the field, outselling its closest competitor about 4 to 1. Our coverage of software tends, therefore, to be centered ® ® on Microsoft Project (and on Crystal Ball ), but includes a brief discussion of the many ® “add-ons” that are now available to supplement Microsoft Project and its competitors. ® Because the various versions of Microsoft Project are quite similar in the way that they perform most of the basic tasks of project management, we generally do not differentiate between the versions, referring to any and all simply as Microsoft Project (MSP). We have also added some exercises to the end-of-chapter material that can utilize computer software. Similar materials are also available on the Web site. A new option now available to educational institutions adopting this Wiley textbook is a free 3-year membership to the MSDN Academic Alliance. The MSDN AA is designed to provide the easiest and most inexpensive way for academic departments to make the latest Microsoft software available in labs, classrooms, and on student PCs. Microsoft Project 2007 software is available through this Wiley and Microsoft publishing partnership, free of charge with the adoption of any qualified Wiley textbook. Each copy of Microsoft Project is the full version of the software, with no time limitations, and can be used indefinitely for educational purposes. Contact your Wiley sales rep for details. For more information about the MSDN AA program, go to http://msdn.microsoft .com/academic/. There is, of course, the danger that human nature, operating in its normal discreet mode, will shift the task of learning project management to that of learning project management software. Projects have often failed because the project manager started managing the software instead of the project. Instructors need to be aware of the problem and must caution students not to fall into this trap.

ONLINE SUPPLEMENTS The Instructor’s Resource Guide on the Web site www.wiley.com/college/meredith provides additional assistance to the project management instructor. In addition to the answers/ solutions to the problems, questions, readings, and cases, this edition includes teaching tips, a computerized test bank, additional cases, and PowerPoint slides. All of these valuable resources are available online (http://www.wiley.com/college/meredith). In addition, the student Web site contains Web quizzes, PowerPoint® slides, Appendix A: Probability and Statistics, Appendix B: Answers to the Even-Numbered Problems, Creativity and Idea Generation, Technological Forecasting, a Glossary, and a Microsoft Project Manual.

ACKNOWLEDGMENTS We owe a debt of gratitude to all those who have helped us with this book, especially the staff at Wiley. First, we thank the managers and students who helped us solidify our ideas about proper methods for managing projects and proper ways of teaching the subject. Second, we thank the project teams and leaders in all of our project management classes. We are especially grateful to Margaret Sutton and Scott Shafer whose creative ideas, extensive skills with software, and ability to sniff out inconsistencies saved us countless hours of fumbling and potential embarrassment. Last, but never least, we thank Suzanne Ingrao/Ingrao Associates, editor nonpareil, and Ramya Srinivasan/MPS Limited, a MacMillan Company for seemingly effortless production.

xii

PREFACE

Special thanks are due those who have significantly influenced our thinking about project management or supplied materials to help us write this book: Jeffrey Camm, James Evans, Martin Levy, John McKinney, and William Meyers, all of the Univ. of Cincinnati; S. J. Mantel III, PMP; Jeffrey Pinto, Pennsylvania State Univ. at Erie; Stephen Wearne, Univ. of Manchester; and the Staff of the Project Management Institute. We owe a massive debt of gratitude to the reviewers for previous editions: Nicholas Aquilano, Univ. of Arizona; Steve Allen, Truman State Univ.; Bob Ash, Indiana Univ., Southeast; Bud Baker, Wright State Univ.; Robert J. Berger, Univ. of Maryland; Robert Bergman, Univ. of Houston; William Brauer, Bemidji State Univ.; Maj. Mark D. Camdle, Air Force Inst. of Tech.; Howard Chamberlin, Texas A&M Univ.; Chin-Sheng Chen, Florida International Univ.; Susan Cholette, San Francisco Univ.; Denis Cioffi, George Washington Univ.; Desmond Cook, Ohio State Univ.; Edward Davis, Univ. of Virginia; Burton Dean, San Jose State Univ.; Michael H. Ensby, Clarkson Univ.; Abel Fernandez, Univ. of the Pacific; Richard E. Gunther, California State Univ., Northridge; William Hayden, Jr., SUNY, Buffalo; Jane E. Humble, Arizona State Univ.; Richard H. Irving, York Univ.; Roderick V. James, DeVry Univ.; Homayoun Kahmooshi, George Washington Univ.; David L. Keeney, Stevens Inst. of Tech.; Ted Klastorin, Univ. of Washington; David Kukulka, Buffalo State Univ.; Young Hoon Kway, George Washington Univ.; William Leban, DeVry Univ.; Ardeshir Lohrasbi, Univ. of Illinois, Springfield; Bil Matthews, William Patterson University; Sara McComb, Univ. of Massachusetts, Amherst; Abe Meilich, Walden Univ.; Mary Meixell, Quinnipiac Univ.; Jaindeep Motwani, Grand Valley State Univ.; Barin Nag, Towson Univ.; John E. Nicolay, Jr., Univ. of Minnesota; David L. Overbye, DeVry Univ.; Pat Penfield, Syracuse Univ.; Ed Pohl, Univ. of Arkansas; Michael Poli, Stevens Inst. of Tech.; Amit Raturi, Univ. of Cincinnati; David J. Robb, Univ. of Calgary; Arthur C. Rogers, City Univ., Washington; David Russo, Univ. of Texas, Dallas; Boong-Yeol Ryoo, Florida International Univ.; Thomas Schuppe, Milwaukee School of Engineering; Ruth Seiple, Univ. of Cincinnati; John Shanfi, DeVry Inst. of Tech., Irving, TX; Wade Shaw, Florida Inst. of Tech.; Richard V. Sheng, DeVry Inst. of Tech., San Marino, CA; Bill Sherrard, San Diego State Univ.; Joyce T. Shirazi, Univ. of Maryland, Univ. College; Chris Simber, Stevens Inst. of Tech.; Gene Simons, Rensselaer Polytech. Inst.; Herbert Spirer, Univ. of Connecticut; Eric Sprouls, Univ. of Southern Indiana; Peter Strunk, Univ. of Cincinnati; Samuel Taylor, Univ. of Wyoming; Tony Trippe, Rochester Inst. of Tech.; Jerome Weist, Univ. of Utah; William G. Wells, Jr., The George Washington Univ.; Susan Williams, Northern Arizona State Univ.; James Willman, Univ. of Bridgeport, and Charles I. Zigelman, San Diego State Univ. For this edition, we thank the following reviewers: Kwasi Amoako-Gyampah, Univ. of North Carolina at Greensboro; the late Larry Crowley, Auburn Univ.; Catherine Crummett, James Madison Univ.; Bertie M. Geer, Northern Kentucky Univ.; Kimberlee Snyder, Winona State Univ. Jack Meredith Broyhill Distinguished Scholar and Chair in Operations Wake Forest University, P.O. Box 7659 Winston-Salem, NC 27109 [emailprotected] www.mba.wfu.edu

Samuel J. Mantel, Jr., Joseph S. Stern Professor Emeritus of Operations Management University of Cincinnati 608 Flagstaff Drive Cincinnati, OH 45215 [emailprotected]

Contents

CHAPTER 1 Projects in Contemporary Organizations 1

1.1 The Definition of a “Project” 10 1.2 Why Project Management? 16 1.3 The Project Life Cycle 17 1.4 The Structure of This Text 23 PROJECT MANAGEMENT IN PRACTICE A Unique Method for Traveler-Tracking at Copenhagen Airport 12 The Smart-Grid Revolution Starts in Boulder, Colorado 13 The Olympic Torch Relay Project 15 Turning London’s Waste Dump into the 2012 Olympics Stadium 21 DIRECTED READING: Lessons for an Accidental Profession 30

PROJECT INITIATION 39 CHAPTER 2 Strategic Management and Project Selection 41

2.1 Project Management Maturity 43 2.2 Project Selection Criteria and Models 44 2.3 Types of Project Selection Models 47 2.4 Risk Considerations in Project Selection 64 2.5 The Project Portfolio Process (PPP) 65 2.6 Project Bids and RFPs (Requests for Proposals) 74 PROJECT MANAGEMENT IN PRACTICE Implementing Strategy through Projects at Blue Cross/Blue Shield Taipei 101: Refitted as World’s Tallest Sustainable Building 50 Project Selection for Spent Nuclear Fuel Cleanup 55 Using a Project Portfolio to Achieve 100% On-Time Delivery at Decor Cabinet Company 66 CASE: Pan-Europa Foods S.A. 82 DIRECTED READING: From Experience: Linking Projects to Strategy 90

43

xiii

xiv

CONTENTS

CHAPTER 3 The Project Manager 101

3.1 Project Management and the Project Manager 103 3.2 Special Demands on the Project Manager 108 3.3 Attributes of Effective Project Managers 118 3.4 Problems of Cultural Differences 124 PROJECT MANAGEMENT IN PRACTICE The Project Management Career Path at AT&T 107 A Surprise “Director of Storm Logistics” for Katrina 109 The Wreckmaster at a New York Subway Accident 115 Growing Stress at Twitter 123 Success at Energo by Integrating Two Diverse Cultures 126 CASE: The National Jazz Hall of Fame 134 DIRECTED READING: What It Takes to Be a Good Project Manager 140 CHAPTER 4 Managing Conflict and the Art of Negotiation

145

4.1 Conflict and the Project Life Cycle 148 4.2 The Nature of Negotiation 155 4.3 Partnering, Chartering, and Scope Change 156 4.4 Some Requirements and Principles of Negotiation 161 PROJECT MANAGEMENT IN PRACTICE Quickly Building a Kindergarten through Negotiation 147 A Consensus Feasibility Study for Montreal’s Archipel Dam 154 Habitat for Humanity Wins a Big One 157 Negotiation in Action—The Quad Sensor Project 163 DIRECTED READING: Methods of Resolving Interpersonal Conflict 168 CHAPTER 5 The Project in the Organizational Structure 175

5.1 Projects in a Functional Organization 177 5.2 Projects in a Projectized Organization 180 5.3 Projects in a Matrixed Organization 182 5.4 Projects in Composite Organizational Structures 188 5.5 Selecting a Project Form 189 5.6 The Project Management Office (PMO) 192 5.7 The Project Team 197 5.8 Human Factors and the Project Team 200 PROJECT MANAGEMENT IN PRACTICE Reorganizing for Project Management at Prevost Car 180 Software Firm Yunio Avoids Complex Technologies 187 Trinatronic, Inc. 191 A Project Management Office Success for the Transportation Security Administration 193 The Empire Uses Floating Multidisciplinary Teams 199 South African Repair Success through Teamwork 204

CONTENTS

CASE: Oilwell Cable Company, Inc. 210 DIRECTED READING: The Virtual Project: Managing Tomorrow’s Team Today 213

PROJECT PLANNING 219 CHAPTER 6 Project Activity and Risk Planning 221

6.1 Initial Project Coordination and the Project Charter 224 6.2 Starting the Project Plan: The WBS 232 6.3 Human Resources: The RACI Matrix and Agile Projects 240 6.4 Interface Coordination through Integration Management 245 6.5 Project Risk Management 250 PROJECT MANAGEMENT IN PRACTICE Beagle 2 Mars Probe a Planning Failure 222 Child Support Software a Victim of Scope Creep 225 Shanghai Unlucky with Passengers 227 Facebook Risks Interruption to Move a Terabyte 230 Using Agile to Integrate Two Gas Pipeline Systems 243 Trying to Install a Wind Farm in the Middle of the North Sea 246 An Acquisition Failure Questions Recommended Practice 248 Risk Analysis vs. Budget/Schedule Requirements in Australia 250 Ignoring Risk Contrasted with Recognizing Risk in Two Industries 255 CASE: Heublein: Project Management and Control System 268 DIRECTED READING: Planning for Crises in Project Management 277 CHAPTER 7 Budgeting: Estimating Costs and Risks

285

7.1 Estimating Project Budgets 286 7.2 Improving the Process of Cost Estimating 299 7.3 Risk Estimation 308 PROJECT MANAGEMENT IN PRACTICE Pathfinder Mission to Mars—on a Shoestring 287 Convention Security: Project Success through Budget Recovery 290 Managing Costs at Massachusetts’ Neighborhood Health Plan 293 Completing the Limerick Nuclear Facility Under Budget 299 The Emanon Aircraft Corporation 306 Simulating the Failure of California’s Levees 309 CASE: Automotive Builders, Inc.: The Stanhope Project 323 DIRECTED READING: Three Perceptions of Project Cost 328 CHAPTER 8 Scheduling

335

8.1 Background 335 8.2 Network Techniques: PERT (ADM) and CPM (PDM) 338 8.3 Risk Analysis Using Simulation with Crystal Ball® 367 8.4 Using These Tools 375

xv

xvi

CONTENTS

PROJECT MANAGEMENT IN PRACTICE Replacing the Atigun Section of the TransAlaska Pipeline 336 Election Returns within Three Hours 346 Hosting the Annual Project Management Institute Symposium 365 Designing and Delivering a Rush Vehicle for War 374 CASE: The Sharon Construction Corporation 384 CHAPTER 9 Resource Allocation 387

9.1 Critical Path Method—Crashing a Project 389 9.2 The Resource Allocation Problem 398 9.3 Resource Loading 400 9.4 Resource Leveling 403 9.5 Constrained Resource Scheduling 408 9.6 Multiproject Scheduling and Resource Allocation 414 9.7 Goldratt’s Critical Chain 418 PROJECT MANAGEMENT IN PRACTICE Expediting Los Angeles Freeway Repairs after the Earthquake 388 Architectural Associates, Inc. 391 Thirty Days to Rescue 397 Benefit/Cost Analysis Saves Chicago’s Deep Tunnel Project 399 Benefits of Resource Constraining at Pennsylvania Electric 413 CASE: D. U. Singer Hospital Products Corp. 430

PROJECT EXECUTION 435 CHAPTER 10 Monitoring and Information Systems

437

10.1 The Planning-Monitoring-Controlling Cycle 438 10.2 Information Needs and Reporting 445 10.3 Earned Value Analysis 450 10.4 Computerized PMIS (Project Management Information Systems) 461 PROJECT MANAGEMENT IN PRACTICE Using Project Management Software to Schedule the Olympic Games 438 Drug Counseling Program 445 Success through Earned Value at Texas Instruments 459 CASE: The Project Manager/Customer Interface 470 CHAPTER 11 Project Control 475

11.1 The Fundamental Purposes of Control 479 11.2 Three Types of Control Processes 480 11.3 The Design of Control Systems 489 11.4 Control of Change and Scope Creep 496 11.5 Control: A Primary Function of Management 500 PROJECT MANAGEMENT IN PRACTICE Regaining Control of Nuclear Fusion 477 Extensive Controls for San Francisco’s Metro Turnback Project

481

CONTENTS

xvii

Tracking Scope Creep: A Project Manager Responds 491 Major Scope Creep in Boston’s “Big Dig” 497 Better Control of Development Projects at Johnson Controls 499 CASE: Peerless Laser Processors 509 DIRECTED READING: Controlling Projects According to Plan 513 CHAPTER 12 Project Auditing 521

12.1 Purposes of Evaluation—Goals of the System 522 12.2 The Project Audit 525 12.3 The Project Audit Life Cycle 530 12.4 Some Essentials of an Audit/Evaluation 533 12.5 Measurement 536 PROJECT MANAGEMENT IN PRACTICE Lessons from Auditing 110 Client/Server and Open Systems Projects 525 Auditing a Troubled Project at Atlantic States Chemical Laboratories 531 CASE: Theater High Altitude Area Defense (THAAD): Five Failures and Counting (B) 541 DIRECTED READING: An Assessment of Postproject Reviews 544 CHAPTER 13 Project Termination 551

13.1 The Varieties of Project Termination 552 13.2 When to Terminate a Project 557 13.3 The Termination Process 562 13.4 The Final Report—A Project History 568 13.5 Afterword 570 PROJECT MANAGEMENT IN PRACTICE Nucor’s Approach to Termination by Addition 554 Twelve Hospital Handoff Projects 556 Terminating the Superconducting Super Collider Project When You Have to Kill a Project 568

561

Photo and Copyright Credits 575 Name Index Subject Index

577 582

Please visit http://www.wiley.com/college/meredith for Appendices. A: Probability and Statistics and Appendix B: Answers to the EvenNumbered Problems.

Available Software Crystal Ball® Trial Edition from Oracle: This software can be downloaded online by students by using the registration cards packaged with the text. Microsoft Project®: Professors may get their students access to the full version of through Wiley’s MSDN Academic Alliance

More Information For more information about Microsoft Project®, go to: http://www.microsoft.com/project For information about a FREE 3-year membership to the MSDN Academic Alliance, go to: http://msdn.microsoft.com/academic/ For more information about Crystal Ball®, go to: http://www.crystalball.com/

Technical Support Wiley technical support for Microsoft Project® http://www.wiley.com/techsupport Oracle tech support for Crystal Ball® http://www.crystalball.com/support_center.html

Online Resources for Students http://www.wiley.com/college/meredith •mWeb Quizzes, PowerPoint® Slides •mAppendix A: Probability and Statistics •mAppendix B: Answers to Even-Numbered Problems •mCreativity and Idea Generation •mTechnological Forecasting

Location of Materials for the Project Management Body of Knowledge (PMBOK) Areas Area 1: Project Integration Management: Section 6.4 Area 2: Project Scope Management: Sections 4.3, 6.1, 11.3, 11.4 Area 3: Project Time Management: Chapters 6, 8, 10, 11 Area 4: Project Cost Management: Chapters 7, 9 Area 5: Project Quality Management: Chapters 6, 12 Area 6: Project Human Resource Management: Chapters 3, 4 Area 7: Project Communications Management: Sections 3.2, 3.4, 4.1, 4.2 Area 8: Project Risk Management: Sections 6.1, 6.5, 7.3, Chapters 10, 11 Area 9: Project Procurement Management: Sections 2.6, 6.4

C

H

A

P

T

E

R

1 Projects in Contemporary Organizations

The past several decades have been marked by rapid growth in the use of project management as a means by which organizations achieve their objectives. In the past, most projects were external to the organization—building a new skyscraper, designing a commercial ad campaign, launching a rocket—but the growth in the use of projects lately has primarily been in the area of projects internal to organizations: developing a new product, opening a new branch, improving the services provided to customers, and achieving strategic objectives. As exhilarating as outside projects are, successfully executing internal projects is even more satisfying in that the organization has substantially improved its ability to execute more efficiently, effectively, or quickly, resulting in an agency or business that can even better contribute to society while simultaneously enhancing its own competitive strength. Project management provides an organization with powerful tools that improve its ability to plan, implement, and control its activities as well as the ways in which it utilizes its people and resources. It is popular to ask, “Why can’t they run government the way I run my business?” In the case of project management, however, business and other organizations learned from government, not the other way around. A lion’s share of the credit for the development of the techniques and practices of project management belongs to the military, which faced a series of major tasks that simply were not achievable by traditional organizations operating in traditional ways. The United States Navy’s Polaris program, NASA’s Apollo space program, and more recently, the space shuttle and the development of “smart” bombs and missiles are a few of the many instances of the application of these specially developed management approaches to extraordinarily complex projects. Following such examples, nonmilitary government sectors, private industry, public service agencies, and volunteer organizations have all used project management to increase their effectiveness. Most firms in the computer software business routinely develop their output as projects or groups of projects. Project management has emerged because the characteristics of our contemporary society demand the development of new methods of management. Of the many forces involved, three are paramount: (1) the exponential expansion of human knowledge; (2) the growing demand for a broad range of complex, sophisticated, customized goods and services; and (3) the evolution of worldwide competitive markets for the production and consumption of goods and services. All three forces combine to mandate the use of teams to solve problems that used

1

2

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

to be solvable by individuals. These three forces combine to increase greatly the complexity of goods and services produced plus the complexity of the processes used to produce them. This, in turn, leads to the need for more sophisticated systems to control both outcomes and processes.

Forces Fostering Project Management First, the expansion of knowledge allows an increasing number of academic disciplines to be used in solving problems associated with the development, production, and distribution of goods and services. Second, satisfying the continuing demand for more complex and customized products and services depends on our ability to make product design an integrated and inherent part of our production and distribution systems. Third, worldwide markets force us to include cultural and environmental differences in our managerial decisions about what, where, when, and how to produce and distribute output. The requisite knowledge does not reside in any one individual, no matter how well educated or knowledgeable. Thus, under these conditions, teams are used for making decisions and taking action. This calls for a high level of coordination and cooperation between groups of people not particularly used to such interaction. Largely geared to the mass production of simpler goods, traditional organizational structures and management systems are simply not adequate to the task. Project management is. The organizational response to the forces noted above cannot take the form of an instantaneous transformation from the old to the new. To be successful, the transition must be systematic, but it tends to be slow and tortuous for most enterprises. Accomplishing organizational change is a natural application of project management, and many firms have set up projects to implement their goals for strategic and tactical change. Another important societal force is the intense competition among institutions, both profit and not-for-profit, fostered by our economic system resulting in organizational “crusades” such as “total quality control,” “supply chain management,” and particularly prominent these days: “Six-sigma*.” The competition that all of these crusades engenders puts extreme pressure on organizations to make their complex, customized outputs available as quickly as possible. “Time-to-market” is critical. Responses must come faster, decisions must be made sooner, and results must occur more quickly. Imagine the communications problems alone. Information and knowledge are growing explosively, but the time permissible to locate and use the appropriate knowledge is decreasing. In addition, these forces operate in a society that assumes that technology can do anything. The fact is, this assumption is reasonably true, within the bounds of nature’s fundamental laws. The problem lies not in this assumption so much as in a concomitant assumption that allows society to ignore both the economic and noneconomic costs associated with technological progress until some dramatic event focuses our attention on the costs (e.g., the global financial crisis, the Gulf oil spill). At times, our faith in technology is disturbed by difficulties and threats arising from its careless implementation, as in the case of industrial waste, but on the whole we seem remarkably tolerant of technological change. For a case in point, consider California farm workers who waited more than 20 years to challenge a University of California research program devoted to the development of labor-saving farm machinery (Sun, 1984). The acceptance of technological advancement is so strong it took more than two decades to muster the legal attack. Consider also the easy acceptance of communication by e-mail and shopping on the Internet. *Six-sigma (see Pande et al., 2000; Pyzdek, 2003) itself involves projects, usually of a process improvement type that involves the use of many project management tools (Chapter 8), teamwork (Chapters 5 and 12), quality tools such as “benchmarking” (Chapter 11), and even audits (Chapter 12).

PROJECTS IN CONTEMPORARY ORGANIZATIONS

3

Finally, the projects we undertake are large and getting larger. The modern advertising company, for example, advances from blanket print ads to regionally focused television ads to personally focused Internet ads. As each new capability extends our grasp, it serves as the base for new demands that force us to extend our reach even farther. Projects increase in size and complexity because the more we can do, the more we try to do. The projects that command the most public attention tend to be large, complex, multidisciplinary endeavors. Often, such endeavors are both similar to and different from previous projects with which we may be more or less familiar. Similarities with the past provide a base from which to start, but the differences imbue every project with considerable risk. The complexities and multidisciplinary aspects of projects require that many parts be put together so that the project’s objectives—deliverables, time (or schedule), and cost—are met.

Three Project Objectives: The “Triple Constraint” While multimillion-dollar, five-year projects capture public attention, the overwhelming majority of all projects are comparatively small—though nonetheless important to doer and user alike. They involve outcomes, or deliverables, such as a new floor for a professional basketball team, a new insurance policy to protect against a specific casualty loss, a new Web site, a new casing for a four-wheel-drive minivan transmission, a new industrial floor cleanser, the installation of a new method for peer-review of patient care in a hospital, even the development of new software to help manage projects. The list could be extended almost without limit. These undertakings have much in common with their larger counterparts. They are complex, multidisciplinary, and have the same general objectives—specified deliverables (also commonly known as scope*), time, and cost. We refer to these as “direct” project objectives or goals. There is a tendency to think of a project solely in terms of its outcome—that is, its scope. But the time at which the outcome is available is itself a part of the outcome, as is the cost entailed in achieving the outcome. The completion of a building on time and on budget is quite a different outcome from the completion of the same physical structure a year late or 20 percent over budget, or both. Indeed, even the concept of scope is more complex than is apparent. Much has been written in recent years arguing that, in addition to time, cost, and specifications, there is a fourth dimension to be considered. This fourth dimension is the expectations of the client (see Darnell, 1997), which sometimes tend to increase as the project progresses, known as “scope creep” (see Chapter 11). However, it seems that the expectations of the client are not an additional target, but an inherent part of the project specifications. To consider the client’s desires as different from the project specifications is to court conflict between client and project team because client and team rarely act in concert. The client specifies a desired outcome. Then the project team designs and implements the project. Then the client views the result of the team’s ideas. Despite this logic, differences between the client’s expectations and the project team’s designs commonly develop as a project proceeds. As a result, meeting the client’s desires may not be well reflected by the initially specified scope of the project. The expectations of client and project team should therefore be realigned and integrated throughout the entire project,

PMBOK Guide Glossary

*The term “scope” is typically used when differentiating between what is included and what is excluded in something, but in project management the term has come to mean the specified deliverables. The Project Management Institute’s Project Management Body of Knowledge (“PMBOK®”) defines Scope as: “The sum of the products, services, and results to be provided as a project.” We will refer to the PMBOK guide frequently throughout this book and use the icon seen here in the margin to draw the student’s attention to this important reference (see the PMI reference in the chapter Bibliography). If particular PMBOK Figures, Tables, Sections, or Chapters are relevant to the discussion, we note this under the icon as, for example, 3.2 which means Chapter 3, Section 2.

4

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS Scope Required deliverables

Performance Target Cost Budget limit

Due date

Time (“schedule”)

Figure 1-1 time.

Direct project goals—scope, cost,

but they frequently are not. As a result, we believe the nebulous elements of the client’s evolving expectations and desires, along with the “specified” scope stated in the project proposal, in reality constitute the total “required deliverables” objective for the project. The three direct project objectives are shown in Figure 1-1, with the specified project objectives on the axes. This illustration implies that there is some “function” that relates them, one to another—and so there is! Although the functions vary from project to project, and from time to time for a given project, we will refer to these relationships, or trade-offs, throughout this book. The primary task of the project manager is to manage these trade-offs, along with a fourth trade-off that always exists: trading off between the direct project objectives/goals and a set of ancillary (frequently process, as noted below) objectives/goals. In a more basic sense, those with a stake in the project (the project manager, project team, senior management, the client, and other project stakeholders) have an interest in making the project a success. Shenhar et al. (1997) have concluded that project success has four dimensions: (1) project efficiency, (2) impact on the customer, (3) the business impact on the organization, and (4) opening new opportunities for the future. The first two are clearly part of what we have defined as the project’s direct objectives; the latter two are typical of what are frequently unspecified ancillary goals. Ancillary goals include improving the organization’s project management competency and methods, increasing individuals’ managerial experience through project management, gaining a foothold in a new market, and similar goals. One other crucial, but unstated, trade-off that a PM must consider is the health of the project team as well as the rest of the organization. The PM cannot burn out the team in an attempt to achieve the direct objectives, nor destroy the organization’s functional departments in an attempt to meet the project’s goals. Another factor in making project trade-offs is the project’s environment, that is, those things or persons outside the project, and often outside the sponsoring organization, that affect the project or are affected by it. Examples of this environment might be antipollution groups, trade unions, competitive firms, and the like. We will deal with these issues in more detail in Chapter 12. From the early days of project management, the direct project objectives of time, cost, and scope (as generally agreed to by the client and the organization actually doing the project)

PROJECTS IN CONTEMPORARY ORGANIZATIONS

5

have been accepted as the primary determinants of project success or failure. In the past 25 years or so, other direct and ancillary objectives have been suggested. These did not replace the traditional time, cost, and scope, but were added as also relevant. For the most part, however, Chapters 1–11 will focus mainly on the traditional direct objectives.

The Project Manager and Project Management Organizations While managing the trade-offs, the project manager (PM) is expected to integrate all aspects of the project, ensure that the proper knowledge and resources are available when and where needed, and above all, ensure that the expected results are produced in a timely, cost-effective manner. The complexity of the problems faced by the PM, taken together with the rapid growth in the number of project-oriented organizations, has contributed to the professionalization of project management. In the early days of projects, being a project manager was known as the “Accidental Profession.” As pointed out in the reading “Lessons for an Accidental Profession” at the end of this chapter, there was no training or career path in project management; you just became one by accident. That has now all changed and the role has become “professionalized.” One of the major international organizations dedicated to this professionalization is the Project Management Institute (PMI®, www.pmi.org), established in the United States of America in 1969. By 1990, the PMI had 7,500 members, and by 2010 it had exploded to over 320,000 members in more than 170 countries (see Figure 1-2). This exponential growth is indicative of the rapid growth in the use of projects, but also reflects the importance of the PMI as a force in the development of project management as a profession. Its mission is to foster the growth of project management as well as “building professionalism” in the field through its many worldwide chapters, its meetings and seminars around the globe, and its journals, books, and other publications. However, there are many other project management organizations as well, such as the Association for Project Management (APM; www.apm.org.uk) headquartered in the United Kingdom, which started in the early 1970s and serves all of Europe. As well, there

320

PMI membership (1000)

280 240 200 160 120 80 40 0

1970

1980

1990 Year

2000

2010

Figure 1-2 Project Management Institute growth history.

6

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

PMBOK Guide

Table 1-1

is the International Project Management Association (IPMA; www.ipma.ch) headquartered in Switzerland, which began in 1965 and serves a global constituency. Another major objective of these organizations is to codify the areas of knowledge required for competent project management. As a result, the APM has its APM Body of Knowledge, PMI has its project management body of knowledge, PMBOK® (Project Management Institute, 2008), and other groups have similar project management bodies of knowledge, as well as credentials (see below), such as PRINCE2 (PRojects IN Controlled Environments) used primarily in the information systems industry and employed extensively by the UK government. Table 1-1 illustrates the difference between the APM BOK and PMBOK®.

Comparison of APM’s BOK (5th ed., ©2006) and PMI’s PMBOK® (4th ed., ©2008)

APM’s BOK: This 179 page book consists of 1½ page introductions, definitions, and references for 52 major project management areas of knowledge divided among 7 sections.

PMI’s PMBOK®: This 479 page book tries to capture the basic knowledge of project management, consisting of 9 knowledge areas (Chapters 4–12) and 5 process groups: initiating, planning, executing, monitoring/controlling, and closing. It aims to describe the norms, methods, processes, and practices of PM.

Section 1: Project Mgt. in Context—projects, programs, portfolios, sponsors, PMO, project context

Chapter 1: Introduction—projects, programs, portfolios, role of the project manager, environment, PMBOK

Chapter 8: Project Quality Management—plan quality, perform quality assurance, control quality

Section 2: Planning the Strategy—success, stakeholders, value, risk, quality, environment, health, safety

Chapter 2: Project Life Cycle and Organization—life cycle, routine work, stakeholders, organization

Chapter 9: Project Human Resource Management—develop HRM plan, acquire & develop team

Section 3: Executing the Strategy—scope, schedule, resources, budgets/cost, changes, earned value, information

Chapter 3: Project Management Processes—interactions, process groups: initiating, planning, executing, monitor/controlling, closing

Chapter 10: Project Communications Management— identify stakeholders, plan communications, distribute information, manage expectations, report performance

Section 4: Techniques—Requirements, development, estimates, technology, value engr., modeling, testing, configuration management

Chapter 4: Project Integration Management—charter, plan, execution, monitor/control, change, close

Chapter 11: Project Risk Management—identify, qualitative risk analysis (RA), quantitative RA, plan response, monitor/control risks

Section 5: Business and Chapter 5: Project Scope Commercial—business case, marketing, Management—collect sales, financing, procurement, legal requirements, define scope, create WBS, verify scope, control scope Section 6: Organisation and Governance—life cycles, implementation, handover, closeout, reviews, org. structure, org. roles, methods, procedures, governance

Chapter 6: Project Time Management—define activities, sequence, resources, durations, schedule, control schedule

Section 7: People & the Chapter 7: Project Cost Profession—communication, teamwork, Management—estimate costs, leadership, conflicts, negotiation, determine budget, control costs HRM, behavior, learning, development, professionalism, ethics.

Chapter 12: Project Procurement Management—plan, conduct, administer, close procurements

PROJECTS IN CONTEMPORARY ORGANIZATIONS

7

All these compilations of knowledge are meant to serve as the fundamental basis for education for project managers. To certify that active project managers understand and can competently apply these bodies of knowledge, various associations offer credentials certifying to this proficiency. For example, PMI offers a certificate called the Project Management Professional (PMP®) that includes a group of education, experience, and testing requirements to obtain. More recently, PMI has added four more certificates, one for advanced program managers, called the Program Management Professional (PgMP®), another for developing project managers, the Certified Associate in Project Management (CAPM®), which has less educational and experience requirements, and two more specialized certificates: PMI Risk Management Professional and PMI Scheduling Professional. (More information on these certificates is contained in the Appendix to this chapter.) As a result of all this activity, the profession has flourished, with the result that many colleges and universities offer education and training in project management, and some offer specialized degree programs in the area. Although obtaining more education in the field is always desirable, and being certified or credentialed verifies that knowledge to a potential employer, the recipient of such proof must avoid preaching the “body of knowledge” bible excessively lest they find themselves again seeking employment. As one employer stated (Starkweather, 2011, p. 37): “It is useful background info, but fresh PMPs® want to ram that knowledge down clients’ throats and clients are not willing to pay for it.” Others added (pp. 36, 38, 39): “There is no correlation between a good project manager and certification based on my 15 years of experience,” and “Would like the PMP® program to more rigorously measure understanding of the methodology rather than memorization. I’ve seen very little correlation between having a PMP® and having a deep understanding of how to apply the methodology, how to tailor it for a specific situation.” Clearly, rapid growth in the number of project managers and the membership in these project management associations were the result, not the cause, of tremendous growth in the number of projects being carried out. The software industry alone has been responsible for a significant percentage of the growth. Another major source of growth has been the need to control project activity in large organizations. As the number of nonroutine activities increases in an organization, there is an increased need in senior management to understand and control the system. Project management, with its schedules, budgets, due dates, risk assessments, statements of expected outcomes, and people who take responsibility, is a way to meet this need. These forces have combined and led to the creation of a project-organized firm. Much more will be said about project-oriented organizations in Chapter 4. As we note in the coming chapters, the project manager’s job is not without problems. There is the ever-present frustration of being responsible for outcomes while lacking full authority to command the requisite resources or personnel. There are the constant problems of dealing with the parties involved in any project—senior management, client, project team, and public—all of whom seem to speak different languages and have different objectives. There are the ceaseless organizational and technical “fires to be fought.” There are vendors who cannot seem to keep “lightning-strike-me-dead” promises about delivery dates. This list of troubles only scratches the surface. Difficult as the job may be, most project managers take a considerable amount of pleasure and job satisfaction from their occupation. The challenges are many and the risks significant, but so are the rewards of success. Project managers usually enjoy organizational visibility, considerable variety in their day-to-day duties, and often have the prestige associated with work on the enterprise’s high-priority objectives. The profession, however, is not one for the timid. Risk and conflict avoiders do not make happy project managers. Those who can stomach the risks and enjoy practicing the arts of conflict resolution, however, can take substantial monetary and psychological rewards from their work.

8

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Trends in Project Management Many new developments and interests in project management are being driven by quickly changing global markets, technology, and education. Global competition is putting pressure on prices, response times, and product/service innovation. Computer and telecommunications technologies along with greater education are allowing companies to respond to these pressures, pushing the boundaries of project management into regions where new tools are being developed for types of projects that have never been considered before. In addition, the pressure for more and more products and services has led to initiating more projects, but with faster life cycles. We consider a variety of trends in turn. Achieving Strategic Goals (Chapter 2, especially Section 2.5). There has been a greater push to use projects to achieve more strategic goals, and filtering existing major projects to make sure that their objectives support the organization’s strategy and mission. Projects that do not have clear ties to the strategy and mission are terminated and their resources are redirected to those that do. An example of this is given in Section 2.5 where the Project Portfolio Process is described. Achieving Routine Goals (Section 1.1). On the other hand, there has also been a push to use project management to accomplish routine departmental tasks that would previously have been handled as a functional effort. This is because lower level management has become aware that projects accomplish their scope objectives within their budget and deadline, and hope to employ this new tool to improve management of their functions. As a result, artificial deadlines and budgets are created to accomplish specific, though routine, tasks within the functional departments, a process called “projectizing.” However, as reported by Jared Sandberg (Sandberg, 2007) in the Wall Street Journal, there is an important danger with this new tactic. If the deadline isn’t really important and the workers find out it is only artificial (e.g., either by meeting it but getting no appreciation or missing it but with no penalty), this will destroy the credibility of any future deadlines or budgets, much like “the boy who cried wolf.” Improving Project Effectiveness (Sections 2.1, 2.7, 5.6, 6.1, 6.5, 11.2, 11.3). A variety of efforts are being pursued to improve the results of project management, whether strategic or routine. One well-known effort is the creation of a formal Project Management Office (PMO, see Section 5.6) in many organizations, which is responsible for the successful initiation and completion of projects throughout the organization. Another effort is the evaluation of an organization’s project management “maturity,” or skill and experience in managing projects (discussed in Section 2.1). This is often one of the responsibilities of the PMO. Another responsibility of the PMO is to educate project managers about the ancillary goals of the organization (mentioned earlier in this chapter), which automatically become a part of the goals of every project whether the project manager knows it or not. Achieving better control over each project through the use of phase gates (Sections 6.1, 6.5, 11.2), earned value (Section 10.3), critical ratios (Section 11.3), and other such techniques is also a current trend. Virtual Projects (Sections 5.3, 10.2). With the rapid increase in globalization, many projects now involve global teams with team members operating in different countries and different time zones, each bringing a unique set of talents to the project. These are known as virtual projects because the team members may never physically meet before the team is disbanded and another team reconstituted. Advanced telecommunications and computer technologies allow such virtual projects to be created, conduct their work, and complete their project successfully. Dynamic and Quasi-Projects (Section 1.1). Led by the demands of the information technology/systems departments, project management is now being extended into areas where the final scope requirements may not be understood, the time deadline unknown, and/or the budget undetermined. When any one or all of the three project objectives are ill-defined, we call this a “quasi-project.” Such projects are extremely difficult to manage and are often

PROJECTS IN CONTEMPORARY ORGANIZATIONS

9

initiated by setting an artificial due date and budget, and then completed by “de-scoping” the required deliverables as the project progresses, to meet those limits. However, new tools for these kinds of quasi-projects are now being developed—prototyping, phase-gating, agile project management, and others—to help these teams achieve results that satisfy the customer in spite of all the unknowns. Similarly, when change happens so rapidly that the project is under constant variation, other approaches are developed such as “emergent planning” (also known as “rolling wave”), environmental manipulation, alternate controls, competing experiments, and collaborative leadership (Collyer et al., 2010).

Recent Changes in Managing Organizations In the two decades since the first edition of this book was published, the process of managing organizations has been impacted by three revolutionary changes. First, we have seen an accelerating replacement of traditional, hierarchical management by consensual management. Second, we are currently witnessing the adoption of the “systems approach” to deal with organizational or technological problems because it is abundantly clear that when we act on one part of an organization or system, we are certain to affect other parts. Third, we have seen organizations establishing projects as the preferred way to accomplish their goals. Examples vary from the hundreds of projects required to accomplish the “globalization” of a multibillion dollar household products firm to the incremental tailoring of products and services for individual customers. We elaborate on this tie between the organization’s goals and the projects it selects for implementation in the following chapter. And as we will note in Chapter 5 and elsewhere, there has been a rapid and sustained growth in the number of organizations that use projects to accomplish almost all of the nonroutine tasks they undertake. While all three of these phenomena have been known for many years, it is comparatively recent that they have been widely recognized and practiced. In his fascinating book, Rescuing Prometheus (Hughes, 1998), technology historian Thomas Hughes examines four large-scale projects that required the use of a nontraditional management style, a nontraditional organizational design, and a nontraditional approach to problem solving in order to achieve their objectives. These huge projects—the Semiautomatic Ground Environment (SAGE) air defense system, the Atlas Intercontinental Ballistic Missile, the Boston Central Artery/Tunnel, and the Department of Defense Advanced Research Projects Agency’s Internet (ARPANET)—are all characterized by extraordinarily diverse knowledge and information input requirements.* The size and technological complexity of these projects required input from a large number of autonomous organizations—governmental, industrial, and academic—that usually did not work cooperatively with other organizations, were sometimes competitors, and could be philosophical and/or political opponents. Further, any actions taken to deal with parts of the total project often had disturbing impacts on many other parts of the system. Obviously, these projects were not the first complex, large-scale projects carried out in this country or elsewhere. For example, the Manhattan Project—devoted to the development of the atomic bomb—was such a project. The Manhattan Project, however, was the sole and full-time work for a large majority of the individuals and organizations working on it. The organizations contributing to the projects Hughes describes were, for the most part, working on many other tasks. For example, Massachusetts Institute of Technology (MIT), the Pentagon, IBM, Bell Labs (now Lucent Technologies), RAND Corporation, the Massachusetts Department of Highways, and a great many other organizations were all highly involved in one or more of these projects while still carrying on their usual work. The use of multiple

*Hughes’s term for this is “transdisciplinary” (across disciplines), which is rather more accurate than the usual “interdisciplinary” (between disciplines).

10

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

organizations (both within and outside of the sponsoring firm) as contributors to a project is no longer remarkable. Transdisciplinary projects are more the rule than the exception. These revolutions and modifications in the style of management and organization of projects will be reflected throughout this book. For example, we have come to believe that the use of a traditional, hierarchical management style rather than a consensual style to manage multiorganizational projects is a major generator of conflict between members of the project team. We have long felt, and are now certain, that staffing multidisciplinary projects with individuals whose primary focus is on a specific discipline rather than on the problem(s) embodied in the project will also lead to high levels of interpersonal conflict between project team members. In Chapter 5 we will discuss some issues involved in the widespread use of projects to accomplish organizational change. As in earlier editions, we adopt a systems approach to dealing with the problems of managing projects. This book identifies the specific tasks facing PMs. We investigate the nature of the projects for which the PM is responsible, the skills that must be used to manage projects, and the means by which the manager can bring the project to a successful conclusion in terms of the three primary criteria: scope, time, and cost. Before delving into the details of this analysis, however, we clarify the nature of a project and determine how it differs from the other activities that are conducted in organizations. We also note a few of the major advantages, disadvantages, strengths, and limitations of project management. At this end of this chapter, we describe the approach followed throughout the rest of the book.

1.1

THE DEFINITION OF A “PROJECT”

PMBOK Guide Glossary

The PMBOK® has defined a project as “A temporary endeavor undertaken to create a unique product, service, or result” (Project Management Institute, 2008, p. 442). There is a rich variety of projects to be found in our society. Although some may argue that the construction of the Tower of Babel or the Egyptian pyramids were some of the first “projects,” it is probable that cavemen formed a project to gather the raw material for mammoth stew. It is certainly true that the construction of Boulder Dam and Edison’s invention of the light bulb were projects by any sensible definition. Modern project management, however, is usually said to have begun with the Manhattan Project. In its early days, project management was used mainly for very large, complex research and development (R & D) projects like the development of the Atlas Intercontinental Ballistic Missile and similar military weapon systems. Massive construction programs were also organized as projects—the construction of dams, ships, refineries, and freeways, among others. As the techniques of project management were developed, mostly by the military, the use of project organization began to spread. Private construction firms found that project organization was helpful on smaller projects, such as the building of a warehouse or an apartment complex. Automotive companies used project organization to develop new automobile models. Both General Electric and Pratt & Whitney used project organization to develop new jet aircraft engines for airlines, as well as the Air Force. Project management has even been used to develop new models of shoes and ships (though possibly not sealing wax). More recently, the use of project management by international organizations, and especially organizations producing services rather than products, has grown rapidly. Advertising campaigns, global mergers, and capital acquisitions are often handled as projects, and the methods have spread to the nonprofit sector. Weddings, scout-o-ramas, fund drives, election campaigns, parties, and recitals have all made use of project management. Most striking has been the widespread adoption of project management techniques for the development of computer software. In discussions of project management, it is sometimes useful to make a distinction between terms such as project, program, task, and work packages. The military, source

1.1

THE DEFINITION OF A “PROJECT”

11

of most of these terms, generally uses the term program to refer to an exceptionally large, long-range objective that is broken down into a set of projects. These projects are divided further into tasks, which are, in turn, split into work packages that are themselves composed of work units. But exceptions to this hierarchical nomenclature abound. The Manhattan Project was a huge “program,” but a “task force” was created to investigate the many potential futures of a large steel company. In the broadest sense, a project is a specific, finite task to be accomplished. Whether large- or small-scale or whether long- or short-run is not particularly relevant. What is relevant is that the project be seen as a unit. There are, however, some attributes that characterize projects.

Importance The most crucial attribute of a project is that it must be important enough in the eyes of senior management to justify setting up a special organizational unit outside the routine structure of the organization. If the rest of the organization senses, or even suspects, that it is not really that important, the project is generally doomed to fail. The symptoms of lack of importance are numerous and subtle: no mention of it by top management, assigning the project to someone of low stature or rank, adding the project to the responsibilities of someone who is already too overworked, failing to monitor its progress, failing to see to its resource needs, and so on.

Scope A project is usually a one-time activity with a well-defined set of desired end results. (We discuss poorly defined, or “quasi-” projects a bit later.) It can be divided into subtasks that must be accomplished in order to achieve the project goals. The project is complex enough that the subtasks require careful coordination and control in terms of timing, precedence, cost, and scope. Often, the project itself must be coordinated with other projects being carried out by the same parent organization.

Life Cycle with a Finite Due Date Like organic entities, projects have life cycles. From a slow beginning they progress to a buildup of size, then peak, begin a decline, and finally must be terminated by some due date. (Also like organic entities, they often resist termination.) Some projects end by being phased into the normal, ongoing operations of the parent organization. The life cycle is discussed further in Section 1.3 where an important exception to the usual description of the growth curve is mentioned. There are several different ways in which to view project life cycles. These will be discussed in more detail later.

Interdependencies Projects often interact with other projects being carried out simultaneously by their parent organization. Typically, these interactions take the form of competition for scarce resources between projects, and much of Chapter 9 is devoted to dealing with these issues. While such interproject interactions are common, projects always interact with the parent organization’s standard, ongoing operations. Although the functional departments of an organization (marketing, finance, manufacturing, and the like) interact with one another in regular, patterned ways, the patterns of interaction between projects and these departments tend to be changeable. Marketing may be involved at the beginning and end of a project, but not in the middle. Manufacturing may have major involvement throughout. Finance is often involved at the beginning and accounting (the controller) at the end, as well as at periodic reporting times. The PM must keep all these interactions clear and maintain the appropriate interrelationships with all external groups.

12

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Uniqueness Though the desired end results may have been achieved elsewhere, they are at least unique to this organization. Moreover, every project has some elements that are unique. No two construction or R & D projects are precisely alike. Though it is clear that construction projects are usually more routine than R & D projects, some degree of customization is a characteristic of projects. In addition to the presence of risk, as noted earlier, this characteristic means that projects, by their nature, cannot be completely reduced to routine. The PM’s importance is emphasized because, as a devotee of management by exception, the PM will find there are a great many exceptions to manage by.

Project Management in Practice A Unique Method for Traveler-Tracking at Copenhagen Airport

IT University of Copenhagen, Denmark was working with Copenhagen Airport to improve the management of their airport through traveler-tracking, without invading people’s privacy. The 3-year project focused on a unique, low-cost approach—capturing the Bluetooth signals from passengers’ phones with two electronic readers that cost only $30 each. Not everyone has a smartphone that emits signals, of course, but about 7 percent of the passengers do,

enough to provide a completely random sample for tracking. To ensure privacy, they collected only a portion of each signal and deleted the addresses. They also informed the public about the project on the airport’s website and on-site as well. To encourage positive traveler response to the project, they provided alerts to passengers willing to synchronize their Bluetooth to receive information regarding when their plane was boarding and a map to the gate.

1.1

Knowing when people were entering and leaving Security allowed the airport to balance the staff at Security so lines didn’t build up, thereby shortening the time passengers must wait, while also reducing over- and under-staffing of screeners. In addition, the information allows them to also post wait times at the check-in gates. The data also lets the airport determine which shops and areas are getting the most

THE DEFINITION OF A “PROJECT”

13

traffic so they can shift usage of facility space to better serve the travelers and the friends and families accompanying them. And when construction and rerouting changes traffic flows, they can determine the impact on passengers and take action to reduce the inconvenience. Source: S. F. Gale, “Data on the Go,” PM Network, Vol. 24.

Resources Projects have limited budgets, both for personnel as well as other resources. Often the budget is implied rather than detailed, particularly concerning personnel, but it is strictly limited. The attempt to obtain additional resources (or any resources) leads to the next attribute—conflict.

Conflict More than most managers, the PM lives in a world characterized by conflict. Projects compete with functional departments for resources and personnel. More serious, with the growing proliferation of projects, is the project-versus-project conflict for resources within multiproject organizations. The members of the project team are in almost constant conflict for the project’s resources and for leadership roles in solving project problems. The PM must be expert in conflict resolution, but we will see later that there are helpful types of conflict. The PM must recognize the difference. The four parties-at-interest or “stakeholders” (client, parent organization, project team, and the public) in any project even define success and failure in different ways. The client wants changes, and the parent organization wants profits, which may be reduced if those changes are made. Individuals working on projects are often responsible to two bosses at the same time; these bosses may have different priorities and objectives. Project management is no place for the timid.

Project Management in Practice The Smart-Grid Revolution Starts in Boulder, Colorado Boulder’s utility company, Xcel Energy, decided that it was time to create a roadmap for a 3-year, $100 million “smart-grid” electrical system that would span the entire city. There were no standards, benchmarks, or tested procedures for converting a city from a conventional electric-grid system to a fully integrated smart one, though it was known that if customers can monitor the true cost of their energy,

they will automatically reduce their usage, by up to 30 percent in some cases. Of course, the smart grid would also allow Xcel to reroute power around bottlenecked lines, detect power outages, identify service risks, cut its use of road crews, read customer meters remotely, reduce outages, and identify false alarms more quickly.

14

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Xcel brought in a mass of partners on the project, such as Accenture consulting for engineering, energy industry consultants, leading technologists, business leaders, IT experts, and of course, Boulder city managers, leaders, and user-citizens. The public and private partners were divided into eight teams, all led by a senior project manager working with a Project Management Office. With all these different stakeholders, with different objectives and interests, it was crucial to have steady, reliable communication to keep everyone up to date and the project on track. Security and privacy were high-priority items on the project, and communication with the community was facilitated through town-hall meetings, the local media,

tours of project sites, and even a touring trailer allowing citizens to get a hands-on demonstration of the smart-grid technology. With the completion of the project, Xcel is now measuring its many benefits and expects it will take a year to collect and analyze all the data across all the seasons. The project partners have also created an industry consortium to establish industry standards for future, larger smart-grid projects. They now see Boulder as a living laboratory from which they can continue to learn and thereby successfully deploy smart grids across the entire country. Source: S. F. Gale, “A Closer Look,” PM Network, Vol. 24.

Nonprojects and Quasi-Projects If the characteristics listed above define a project, it is appropriate to ask if there are nonprojects. There are. The use of a manufacturing line to produce a flow of standard products is a nonproject. The production of weekly employment reports, the preparation of school lunches, the delivery of mail, the flight of Delta-1288 from Dallas to Dulles, checking your e-mail, all are nonprojects. While one might argue that each of these activities is, to some degree, unique, it is not their uniqueness that characterizes them. They are all routine. They are tasks that are performed over and over again. This is not true of projects. Each project is a one-time event.

1.1

THE DEFINITION OF A “PROJECT”

15

Even the construction of a section of interstate highway is a project. No two miles are alike and constructing them demands constant adaptation to the differences in terrain and substructure of the earth on which the roadbed is to be laid. Projects cannot be managed adequately by the managerial routines used for routine work. In addition to projects and nonprojects, there are also quasi-projects: “Bill, would you look into this?” “Judy, we need to finish this by Friday’s meeting.” “Can you find out about this before we meet with the customer?” Most people would consider that they have just been assigned a project, depending on who “we” and “you’’ is supposed to include. Yet there may be no specific task identified, no specific budget given, and no specific deadline defined. Are they still projects, and if so, can project management methods be used to manage them? Certainly! The scope, schedule, and budget have been implied rather than carefully delineated by the words “this,” “meet,” and “we” (meaning “you”) or “you” (which may mean a group or team). In such cases, it is best to try to quickly nail down the scope, schedule, and budget as precisely as possible, but without antagonizing the manager who assigned the project. You may need to ask for additional help or other resources if the work is needed soon—is it needed soon? How accurate/thorough/detailed does it need to be? And other such questions. One common quasi-project in the information systems area is where the project includes discovery of the scope or requirements of the task itself (and possibly also the budget and deadline). How can you plan a project when you don’t know the scope requirements? In this case, the project is, in fact, determining the scope requirements (and possibly the budget and deadline also). If the entire set of work (including the discovery) has been assigned to you as a project, then the best approach is to set this determination as the first “milestone” in the project, at which point the resources, budget, deadline, capabilities, personnel, and any other matters will be reviewed to determine if they are sufficient to the new project requirements. Alternatively, the customer may be willing to pay for the project on a “cost-plus” basis, and call a halt to the effort when the benefits no longer justify the cost.

Project Management in Practice The Olympic Torch Relay Project

Seattle Minneapolis Boston New York Chicago Denver Los Angeles

Atlanta Dallas New Orleans Miami

16

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Getting the Olympic Flame, known as the Olympic Torch Relay, to the Olympic Games is no simple matter. Generally, the Torch Relay has gotten longer and more complex with every Olympic event. In the 1936 Olympics the torch left from the original site of the Olympics, the Temple of Hera in Olympia, Greece, and traveled through seven countries to reach its final destination at the games in Berlin. For the Beijing 2008 Olympics, the flame traveled 137,000 kilometers (about 85,000 miles)! This increasing length and complexity are driven by the realization of hostcountry citizens that it is a rare opportunity to have the Olympic torch pass through your hometown and the corresponding goal of the Olympic Committee to touch as many lives as possible in a positive way. As an example, the planning for the 1996 Atlanta Olympic Torch Relay (see figure) took two years, cost over $20 million, and involved an 84 day, 42 state campaign using 10,000 runners to carry the torch for 15,000 miles! Accompanying the runners was a 40-vehicle caravan carrying security officers, media personnel, medical personnel, computers, telecommunications gear, clothing, food, and spare lanterns

1.2

with extra flames in case the original torch went out. The caravan included: 50 cellular telephones; 60 pagers; 120 radios; 30 cars; 10 motorcycles; and clothing for 10,000 runners, 10,000 volunteers, as well as 2,500 escort runners. The torch relay is also a major marketing campaign, primarily for the relay’s sponsors. Thus, accompanying the Atlanta-bound caravan were trucks hawking Olympic memorabilia: t-shirts, sweatshirts, baseball caps, tickets to the soccer matches, and on and on. In addition to retail commercialism, a number of companies were piggybacking on the torch relay to further their own commercial interests: IBM, Motorola, BellSouth, Texaco, BMW, Lee, Coca-Cola, and so on. The next games will be held in London, 2012, and Rio de Janeiro, 2016—we can only wonder how far and how complex the Torch Relay will be then! Sources: G. Ruffenach, “Getting the Olympic Flame to Atlanta Won’t Be a Simple Cross-Country Run,” The Wall Street Journal, 1996. http://olympics.india-server.com/torch-relay.html; www.bladesplace.id.au/olympic-games-candidates.html

WHY PROJECT MANAGEMENT? The basic purpose for initiating a project is to accomplish specific goals. The reason for organizing the task as a project is to focus the responsibility and authority for the attainment of the goals on an individual or small group. In spite of the fact that the PM often lacks authority at a level consistent with his or her responsibility, the manager is expected to coordinate and integrate all activities needed to reach the project’s goals. In particular, the project form of organization allows the manager to be responsive to: (1) the client and the environment, (2) identify and correct problems at an early date, (3) make timely decisions about trade-offs between conflicting project goals, and (4) ensure that managers of the separate tasks that comprise the project do not optimize the performance of their individual tasks at the expense of the total project—that is, that they do not suboptimize. Actual experience with project management (such as through the currently popular Six-Sigma projects) indicates that the majority of organizations using it experience better control and better customer relations (Davis, 1974), and probably an increase in their project’s return on investment (Ibbs et al., 1997). A significant proportion of users also report shorter development times, lower costs, higher quality and reliability, and higher profit margins. Other reported advantages include a sharper orientation toward results, better interdepartmental coordination, and higher worker morale. On the negative side, most organizations report that project management results in greater organizational complexity. Many also report that project organization increases the likelihood that organizational policy will be violated—not a surprising outcome, considering the degree

1.3

THE PROJECT LIFE CYCLE

17

of autonomy required for the PM. A few firms reported higher costs, more management difficulties, and low personnel utilization. As we will see in Chapter 5, the disadvantages of project management stem from exactly the same sources as its advantages. The disadvantages seem to be the price one pays for the advantages. On the whole, the balance weighs in favor of project organization if the work to be done is appropriate for a project. The tremendous diversity of uses to which project management can be put has had an interesting, and generally unfortunate, side-effect. While we assert that all projects are to some extent unique, there is an almost universal tendency for those working on some specific types of projects to argue, “Software (or construction, or R & D, or marketing, or machine maintenance, or . . .) projects are different and you can’t expect us to schedule (or budget, or organize, or manage, or . . .) in the same way that other kinds of projects do.” Disagreement with such pleas for special treatment is central to the philosophy of this book. The fundamental similarities between the processes involved in carrying out all sorts of projects, be they long or short, product- or service-oriented, parts of all-encompassing programs or stand-alone, are far more pervasive than are their differences. There are also real limitations on project management. For example, the mere creation of a project may be an admission that the parent organization and its managers cannot accomplish the desired outcomes through the functional organization. Further, conflict seems to be a necessary side-effect. As we noted, the PM often lacks the authority-of-position that is consistent with the assigned level of responsibility. Therefore, the PM must depend on the goodwill of managers in the parent organization for some of the necessary resources. Of course, if the goodwill is not forthcoming, the PM may ask senior officials in the parent organization for their assistance. But to use such power often reflects poorly on the skills of the PM and, while it may get cooperation in the instance at hand, it may backfire in the long run. We return to the subject of the advantages, disadvantages, and limitations of the project form of organization later. For the moment, it is sufficient to point out that project management is difficult even when everything goes well. When things go badly, PMs have been known to turn gray overnight and take to hard drink! The trouble is that project organization is the only feasible way to accomplish certain goals. It is literally not possible to design and build a major weapon system, for example, in a timely and economically acceptable manner, except by project organization. The stronger the emphasis on achievement of results in an organization, the more likely it will be to adopt some form of project management. The stake or risks in using project management may be high, but no more so than in any other form of management. And for projects, it is less so. Tough as it may be, it is all we have—and it works! All in all, the life of a PM is exciting, rewarding, at times frustrating, and tends to be at the center of things in most organizations. Project management is now being recognized as a “career path” in a growing number of firms, particularly those conducting projects with lives extending more than a year or two. In such organizations, PMs may have to function for several years, and it is important to provide promotion potential for them. It is also common for large firms to put their more promising young managers through a “tour of duty” during which they manage one or more projects (or parts of projects). This serves as a good test of the aspiring manager’s ability to coordinate and manage complex tasks and to achieve results in a politically challenging environment where negotiation skills are required.

1.3

THE PROJECT LIFE CYCLE Most projects go through similar stages on the path from origin to completion. We define these stages, shown in Figure 1-3, as the project’s life cycle. The project is born (its start-up phase) and a manager is selected, the project team and initial resources are assembled, and

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

100

% Project completion

Slow finish

Quick momentum

Slow start

Figure 1-3 The common stretched-S project life cycle.

0 Time

Peak effort level

Level of effort

18

Time

Conception Selection

Planning, scheduling, monitoring, control

Evaluation and termination

Figure 1-4 Time distribution of project effort.

the work program is organized. Then work gets under way and momentum quickly builds. Progress is made. This continues until the end is in sight. But completing the final tasks seems to take an inordinate amount of time, partly because there are often a number of parts that must come together and partly because team members “drag their feet” for various reasons and avoid the final steps. This “stretched-S” pattern of slow-rapid-slow progress toward the project goal is common. Anyone who has watched the construction of a home or building has observed this phenomenon. For the most part, it is a result of the changing levels of resources used during the successive stages of the life cycle. Figure 1-4 shows project effort, usually in terms of personhours or resources expended per unit of time (or number of people working on the project) plotted against time, where time is broken up into the several phases of project life. Minimal effort is required at the beginning, when the project concept is being developed and subjected

1.3

THE PROJECT LIFE CYCLE

19

to project selection processes. (Later, we will argue that increasing effort in the early stages of the life cycle will improve the chance of project success.) Normally there is a strong correlation between the life-cycle progress curve of Figure 1-3 and the effort curve of Figure 1-4 because effort usually results in corresponding progress (although not always). Hence the mathematical derivative of the former tends to resemble the latter (Cioffi, 2004). Moreover, since the effort curve is generally nonsymmetrical, the progress curve will in general not be symmetrical either. Activity increases as planning is completed and the real work of the project gets underway. This rises to a peak and then begins to taper off as the project nears completion, finally ceasing when evaluation is complete and the project is terminated. While this rise and fall of effort always occurs, there is no particular pattern that seems to typify all projects, nor any reason for the slowdown at the end of the project to resemble the buildup at its beginning. Some projects end without being dragged out, as is shown in Figure 1-4. Others, however, may be like T. S. Eliot’s world, and end “not with a bang but a whimper,” gradually slowing down until one is almost surprised to discover that project activity has ceased. In some cases, the effort may never fall to zero because the project team, or at least a cadre group, may be maintained for the next appropriate project that comes along. The new project will then rise, phoenix-like, from the ashes of the old. The ever-present goals of meeting scope, time, and cost are the major considerations throughout the project’s life cycle. It was generally thought that scope took precedence early in the project’s life cycle. This is the time when planners focus on finding the specific methods required to meet the project’s scope goals. We refer to these methods as the project’s technology because they require the application of a science or art. When the major “how” problems are solved, project workers sometimes become preoccupied with improving scope, often beyond the levels required by the original specifications. This search for better scope delays the schedule and pushes up the costs. At the same time that the technology of the project is defined, the project schedule is designed and project costs are estimated. Just as it was thought that scope took precedence over schedule and cost early in the life cycle, cost was thought to be of prime importance during the periods of high activity, and then schedule became paramount during the final stages, when the client demanded delivery. This conventional wisdom turns out to be untrue. Recent research indicates that scope and schedule are more important than cost during all stages. The reality of time-cost-scope trade-offs will be discussed in greater detail in Chapter 3. Figure 1-3 presents the conventional view of the project life cycle. There are, however, many projects that have a life cycle quite different from the S-shaped Figure 1-3, conventional wisdom to the contrary. Remember that Figure 1-3 shows “percent project completion” as a function of “time.” The life-cycle function is essentially unchanged if, for the horizontal axis, we use “resources” instead. In effect, the life cycle shows what an economist might call “return on input,” that is, the amount of project completion resulting from inputs of time or resources. While the S-shaped return curve reflects reality on many projects, it is seriously misleading for others. For example, consider your progress toward getting a degree, which is usually specified, in large part, by the number of credit hours for courses successfully passed. For smooth progress toward the degree, the life-cycle “curve” would probably resemble a stairstep, each level portion representing a term of study and the step up representing completion of credit toward the degree. Summer vacation would, of course, be a longer horizontal stair continuing into the fall term. Passing a crucial licensing exam, such as the Certified Public Accountant (CPA), the bar exam for attorneys, or even an electrician’s or plumber’s certification, might appear as a long flat line along the horizontal axis with a spike at the time of passing the exam; of course, the effort curve of Figure 1-4 would look completely different. Another type of life-cycle curve might be the installation of a new technology consisting of multiple parts, where each independent part resulted in different incremental benefits. In these

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

cases, organizations prefer to install those parts resulting in “the biggest bang for the buck” first, so the resulting life-cycle curve would show great progress at first, and slightly less next, and continual dwindling off as the remaining parts were installed, essentially concave with “decreasing returns to scale,” as the economists call it. And there might even be an “inverse S-curve” representing fast progress at first, a slowdown in the middle, and then speeding up again at the end. A particularly important alternative life cycle shape can be captured by the analogy of baking a cake. Once the ingredients are mixed, we are instructed to bake the cake in a 350 (F) oven for 35 minutes. At what point in the baking process do we have “cake?” Experienced bakers know that the mixture changes from “goop” (a technical term well known to bakers and cooks) to “cake” quite rapidly in the last few minutes of the baking process. The life cycle of this process looks like the stretched-J curve shown in Figure 1-5. A number of actual projects have a similar life cycle, for example, some computer software projects, or chemistry and chemical engineering projects. In general, this life cycle often exists for projects in which the output is composed or constructed of several subunits (or subroutines) that have little use in and of themselves, but are quite useful when put together. This life-cycle curve would also be typical for projects where a chemical-type reaction occurs that rapidly transforms the output from useless to useful—from goop to cake. Another example is the preparation of the manuscript for the current edition of this book. A great deal of information must be collected, a great deal of rewriting must be done and new materials gathered, but there is no visible result until everything is assembled. Figure 1-3 shows that, as the project nears completion, continued inputs of time or resources result in successively smaller increments of completion—diminishing marginal returns. Figure 1-5 shows the opposite. As these projects near completion, additional inputs result in successively larger increments of progress—increasing marginal returns, obviously bounded at 100 percent completion. In Chapter 7, we will see that the distinction between these types of life cycles plays a critical role in developing budgets and schedules for projects. It is not necessary for the PM to estimate the precise shape of the life-cycle curve, but the PM must know which type of project life cycle applies to the project at hand. There is another comparison between the two types of project life cycles that is instructive. For the stretched-S life cycle in Figure 1-3, percentage of project completion is closely correlated with cost, or the use of resources. In fact, this is the basis for the use of “earned value,” a technique for monitoring project progress that we will describe in more detail in Chapter 10. However, for the stretched-J progress curve in Figure 1-5, the expenditure of resources has little correlation with progress, at least in terms of final benefit. Finally, not only does the shape of the project life-cycle curve fail to conform to a neat, single shape—there are also several different ways in which a project life cycle can be viewed and understood. We might view the project life cycle as a mechanism to control quality, as a way of organizing the management of risk, or as a collection of small projects within larger projects within still larger projects. Each of these views of a project’s life is useful to the project manager.

% Project completion

20

100

Time

Figure 1-5 cycle.

The stretched-J project life

1.3

THE PROJECT LIFE CYCLE

21

Project Management in Practice Turning London’s Waste Dump into the 2012 Olympics Stadium

Back in 2006, the 2012 Olympic Delivery Authority (ODA) chose a river-surrounded, 1-square-mile East London disposal site loaded with discarded appliances, tons of waste, shanties, and soil polluted with petrol, oil, lead, tar, and arsenic as the site for their 2012 Olympic Stadium to seat 80,000 visitors. To meet a mid-2011 completion due date, the ODA project manager Ian Crockford quickly assembled a project team of over 1000, including governmental employees and other stakeholders, such as the London Development Agency as landowner, politicians, utility firms, community councils, miscellaneous local governmental groups, and of course, the athletes, all of whom wanted a voice in the site design. To clean up the site, the team created a “Soil Hospital” on-site with 60 scientists and technicians who processed and cleaned 800,000 tons of soil. To use the surrounding river for transporting equipment and materials to the site, others on the team dredged 30,000 tons of silt, gravel, garbage, and one car from 2.2 kilometers of the river, which hadn’t seen commercial use in over 35 years. When they were ready to design the stadium, they referred to plans and schedules for London’s

90,000-seat Wembley Stadium (but that took 10 years to build) and Sydney’s 2000 Olympics 80,000seat stadium (but that would have stretched halfway across the surrounding rivers on the London site). Moreover, the scope for this stadium was that 25,000 seats would be permanent but the other 55,000 would be temporary, built solely for the 2012 Olympics. To respond, the design team planned a highly-compact field of play that was acceptable to everyone, including the athletes. Construction started in May 2008 with the pouring of concrete, but soon they found that the steel-beamed roof as designed would create turbulence on the compact field. The team redesigned a lighter, more flexible roof made, in part, with 52 tons of scrap metal from old keys, knives, and guns confiscated by the London police, fitting with the ODA’s goals of using recycled materials. The entire stadium uses only one-quarter the amount of steel used in the 2008 Olympic stadium in Beijing. Construction is ontrack to be completed by the mid-2011 deadline at a price of £537 million. Source: J. Danko, “Serious Conditioning,” PM Network, Vol. 24.

22

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Risk During the Life Cycle

Project cost

It would be a great source of comfort if one could predict with certainty, at the start of a project, how the scope, time, and cost goals would be met. In a few cases, routine construction projects, for instance, we can generate reasonably accurate predictions, but often we cannot. There may be considerable uncertainty about our ability to meet project goals. The shaded portion of Figure 1-6 illustrates that uncertainty. Figure 1-6 shows the uncertainty as seen at the beginning of the project. Figure 1-7 shows how the uncertainty decreases as the project moves toward completion. From project start time, t0, the band of uncertainty grows until it is quite wide by the estimated end of the project. As the project actually develops, the degree of uncertainty about the final outcome is reduced. (See the estimate made at t1, for example.) A later forecast, made at t2, reduces the uncertainty further. It is common to make new forecasts about project scope, time, and cost either at fixed intervals in the life of the project or when specific technological milestones are reached. In any event, the more progress made on the project, the less uncertainty there is about achieving the final goal. Note that the focus in Figures 1-6 and 1-7 is on the uncertainty associated with project cost—precisely, the uncertainty of project cost at specific points in time. Without significantly altering the shapes of the curves, we could exchange titles on the axes. The figures would then show the uncertainty associated with estimates of the project schedule, given

Figure 1-6 Estimate of project cost: estimate made at project start.

Project cost

Time

t0

t1

t2

Time

Figure 1-7 Estimates of project cost: estimates made at time t0, t1, and t2.

1.4

PMBOK Guide Chapter 11

1.4

THE STRUCTURE OF THIS TEXT

23

specific levels of expenditure. The relationship between time and cost (and scope) is emphasized throughout this book. Dealing with the uncertainty surrounding this relationship is a major responsibility of the PM. PMBOK® devotes an entire chapter to the subject of risk and uncertainty.

THE STRUCTURE OF THIS TEXT This book, a project in itself, has been organized to follow the life cycle of all projects. It begins with the creative idea that launches most projects and ends with termination of the project. This approach is consistent with our belief that it is helpful to understand the entire process of project management in order to understand and manage its parts. Another characteristic of the book also relates to the process of project management: some topics, such as “procurement,” can largely be treated as stand-alone issues, discussed in a single appropriate place in the book, and then dispensed with. Other topics however, such as “risk,” or “planning,” arise throughout the book and are treated wherever they are relevant, which may be quite often. To attempt to treat them in a single section, or chapter, would be misleading. In addition, although this book is intended primarily for the student who wants to study project management, we feel it can also be of value to the prospective or acting PM, and to senior managers who initiate projects and select, work with, or manage PMs. Therefore, our interests often go beyond the issues of primary concern to beginning students. Most actual projects will not be of the size and complexity addressed in many of our discussions. Though our intent was not to confine our remarks only to large engineering-oriented projects, these are typically the most complex and place the greatest demands on project management. Smaller, simpler projects may therefore not require the depth of tools and techniques we will present, but the student or manager should be aware that such tools exist. Project management actually begins with the initial concept for the project. We feel that this aspect of project management is so important, yet so universally ignored in books on project management, that we included two appendices covering this area in previous editions of this book. In one paper we discussed creativity and idea generation. In another, we described some of the techniques of technological forecasting. While our notion about the importance of these subjects is unchanged, the location of the two appendices has been moved from the end of this work to the Internet. The complete text of both appendices now appears in www.wiley.com/college/meredith/ (along with other items noted in the preface to this edition). We realize that these topics may be of more direct interest to the senior manager than the PM. Though a PM may prefer to skip this material, since what is past is past, we believe that history holds lessons for the future. Wise PMs will wish to know the reasons for, and the history behind, the initiation of their project. In years past, there were arguments between those who insisted that project management was primarily a quantitative science and those who maintained that it was a behavioral science. It has become clear that one cannot adequately manage a project without depending heavily on both mathematics and the science of human behavior. To contend that mathematics is exact and that behavioral science is “mushy” is to ignore the high level of subjectivity in most of the numeric estimates made about the times, costs, and risks associated with projects. On the other hand, to assert that “people don’t really use that stuff” (mathematical models) is to substitute wishful thinking for reality. For nonmathematicians, we have computers to help with the requisite arithmetic. For the nonbehaviorists, there is no help except hard work and an accepting attitude toward the subject. Before undertaking a journey, it is useful to know what roads are to be traveled. While each individual chapter begins with a more detailed account of its contents, what follows is

24

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Project Management

Ch 1: Projects in Contemporary Organizations

Project Initiation

Project Planning

Project Execution

Ch 2: Strategic Management and Project Selection

Ch 6: Project Activity and Risk Planning

Ch 10: Monitoring and Information Systems

Ch 3: The Project Manager

Ch 7: Budgeting: Estimating Costs and Risks

Ch 11: Project Control

Ch 4: Managing Conflict and the Art of Negotiation

Ch 8: Scheduling

Ch 12: Project Auditing

Ch 5: The Project in the Organizational Structure

Ch 9: Resource Allocation

Ch 13: Project Termination

Figure 1-8 Organization chart of the parts and chapters of the text.

a brief description of chapter contents along with their organization (Figure 1-8) into three general areas: project initiation, project planning, and project execution. Part I: Project Initiation. Following this current introductory chapter, the material in Part I focuses on the context for initiating the project. We realize that many instructors (and students) would rather get right to the basics of managing projects, and that can be done by moving directly to Part II of the text. However, we believe that without understanding the context of the project—why it was selected and approved, what project managers are responsible for and their many roles (such as running a team and negotiating for resources), the importance of the Project Management Office, and where (and why) the project resides in the organization’s hierarchy—a PM is courting disaster. Chapter 2 starts with a description of the concept of project management “maturity,” or sophistication, and how firms can evaluate their own competence in project management. It then details the problems of evaluating and selecting projects, as well as the information needed for project selection, the consideration of risk, and some technical details of proposals. The chapter concludes by expanding the concept of project selection to strategic management through judicious selection of the organization’s projects by means of a procedure called the “project portfolio process.” Chapter 3, “The Project Manager,” concerns the PM’s roles, responsibilities, and some personal characteristics a project manager should possess. It also discusses problems a PM faces when operating in a multicultural environment. Next, Chapter 4 covers a subject of critical importance to the PM that is almost universally ignored in project management texts: the art of negotiating for resources. The chapter also includes some major sources of interpersonal conflict among members of the project team. Concluding Part I of the book, Chapter 5 concentrates on establishing the project organization. Different project organizational forms are described, as well as their respective advantages and disadvantages. The staffing of the project team is also discussed. Part II Project Planning. This part of the text discusses the essentials of planning the project in terms of activities, costs, risks, and schedule. Chapter 6 deals with project activity and risk planning and presents tools useful in organizing and staffing the various project tasks

SUMMARY

25

and assessing and prioritizing risks to the project. It also contains a short discussion of phasegate management systems and other ways of dealing with the problems that arise when multidisciplinary teams work on complex projects. Because costs are an important element of project planning, the topic of budgeting, including techniques such as simulation to estimate costs and risks, is addressed next in Chapter 7. Scheduling, a crucial aspect of project planning, is then described in Chapter 8, along with the most common scheduling models such as the Program Evaluation and Review Technique (PERT), and precedence diagramming. Concluding Part II, resource allocation is covered in Chapter 9, where the Critical Path Method (CPM) of applying resources to speed up projects is explained. For single projects, we also discuss how the resource allocation problem can be addressed through resource leveling to minimize the cost of the resources; but for multiple projects, we learn that the issue is how to allocate limited resources among several projects in order to achieve the objectives of each. Part III: Project Execution. Finally, we can address how to actually run a project. Chapter 10 examines the information requirements of a project and the need for monitoring critical activities, particularly through the concepts of time and cost variances and “earned value.” Included in this chapter is a description of some common Project Management Information Systems (PMIS). In general, it is not possible to manage adequately any but the smallest of projects without the use of a computerized PMIS. There are many such systems available and several are briefly discussed, but here we only demonstrate Microsoft Project® (as well as Excel® and other software made to interact easily with Microsoft Project® and Excel®), by far the most popular project management software. (A note of caution: To use any project management software wisely, the user must understand the principles of project management.) Chapter 11 then describes the control process in project management. This chapter covers standards for comparison and tools to help the manager keep the project in control. Chapter 12 deals with methods for both ongoing and terminal audits and evaluations of a project, as well as identifying factors associated with project success and failure. Chapter 13 describes the different forms of project termination, such as outright shutdown, integration into the regular organization, or extension into a new project. Each of these forms presents unique problems for the PM to solve. With this introduction, let us begin our study, a project in itself, and, we hope, an interesting and productive one.

SUMMARY This chapter introduced the subject of project management and discussed its importance in our society. It defined what we mean by a “project,” discussed the need for project management, and described the project life cycle. The final section explained the structure of this text and gave an overview of the material to be described in coming chapters. The following specific points were made in the chapter.

• •

The Project Management Institute (PMI) was founded in 1969 to foster the growth and professionalism of project management. Project management is now being recognized as a valuable “career path” in many organizations, as well as a way to gain valuable experience within the organization.

• •

• • •

Project management, initiated by the military, provides managers with powerful planning and control tools. The three primary forces behind project management are (1) the growing demand for complex, customized goods and services; (2) the exponential expansion of human knowledge; and (3) the global production– consumption environment. The three prime objectives of project management are to meet specified scope within cost and on schedule. Our terminology follows in this order: program, project, task, work package, work unit. Projects are characterized by their importance, specific end results, a definite life cycle, complex interdependencies, some or all unique elements, limited resources, and an environment of conflict.

26

• • •

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Project management, though not problem-free, is the best way to accomplish certain goals. Projects often start slowly, build up speed while using considerable resources, and then slow down as completion nears. This text is organized along the project life cycle concept, starting with project initiation in Chapters 2

to 5, where selection of the project and project manager occurs and project organization begins. Project planning, Chapters 6 to 9, is concerned with activity planning, budgeting, scheduling, and resource allocation. Project execution, covered in Chapters 10 to 13, relates to actually running the project and includes activity monitoring and control, auditing and evaluation, and finally project termination.

GLOSSARY Deliverables The desired elements of value, outcomes, or results that must be delivered for a project to be considered complete. Interdependencies Relations between organizational functions where one function or task is dependent on others. Life Cycle A standard concept of a product or project wherein it goes through a start-up phase, a building phase, a maturing phase, and a termination phase. Parties-at-Interest Individuals or groups (the stakeholders) with a special interest in a project, usually the project team, client, senior management, and specific public interest groups. Program Often not distinguished from a project, but frequently meant to encompass a group of projects oriented toward a specific goal. Project Management The means, techniques, and concepts used to run a project and achieve its objectives.

Risk The chance that project processes or outcomes will not occur as planned. Stakeholder see “Parties-at-Interest.” Suboptimize Doing the best within a function or area but at a cost to the larger whole. Task A subset of a project, consisting of work packages. Technology The means for accomplishing a task. Trade-off Taking less on one measure, such as scope, in order to do better on another, such as schedule or cost. Uncertainty Having only partial or no information about the situation or outcomes, often due to ambiguity or complexity. Work Package A subelement of a task at the lowest level in the Work Breakdown Structure, used to assign costs and values.

QUESTIONS Material Review Questions

1. Name and briefly describe the societal forces that have contributed to the need for project management. 2. Describe the life cycle of a project in terms of (1) the degree of project completion; (2) required effort. 3. Describe the limitations of project management. 4. List the seven main characteristics of a project and briefly describe the important features of each. 5. Name and briefly describe the three primary goals of a project. 6. Discuss the advantages and disadvantages of project management.

7. How do projects, programs, tasks, and work packages differ? 8. How would you define a project? 9. What are some of the interdependencies related to a project? 10. What are some sources of conflict the project manager must deal with? 11. Differentiate between direct and ancillary project goals. Would learning a new skill through the project be a direct or ancillary goal? Entering a new market? 12. Describe the characteristics of quasi-projects.

Class Discussion Questions

13. Give several examples of projects found in our society, avoiding those already discussed in the chapter. 14. Describe some situations in which project management would probably not be effective.

15. How does the rate-of-project-progress chart (Fig. 1-3) help a manager make decisions? 16. Expound on the adage, “Projects proceed smoothly until 90 percent complete, and then remain at 90 percent forever.”

INCIDENTS FOR DISCUSSION

27

17. Discuss the duties and responsibilities of the project manager. How critical is the project manager to the success of the project? 18. Would you like to be a project manager? Why, or why not?

28. What additional benefits can the Copenhagen Airport reap from this passenger data? 29. How widespread will this technology become? What uses will be garnered from it? Do any of them concern you?

19. Discuss why there are trade-offs among the three prime objectives of project management. 20. Why is the life cycle curve often “S” shaped? 21. How might project management be used when doing a major schoolwork assignment? 22. Why is there such a pronounced bend in the curve of Figure 1-2? 23. Which of the identified project attributes in Section 1.1 are always present? Which are simply frequently present? 24. Describe a project whose life cycle would be a straight line from start to finish. Describe a project with an inverse-S life cycle.

The Smart-Grid Revolution Starts in Boulder, Colorado

The Olympic Torch Relay Project

25. Is the torch relay another part of the Olympics themselves, perhaps a sub-project? 26. Is the life cycle for this project S-shaped or J-shaped or something else? Why?

30. What other benefits will accrue with smart grids? 31. Why do you imagine Xcel agreed to invest $100 million in this risky experiment? 32. What conflicts do you suspect might have occurred between all the different stakeholders in this project? Turning London’s Waste Dump into the 2012 Olympics Stadium

33. Which of the “triple constraints” seems to be uppermost here? Which constraints was Crockford trading between? 34. Was the life cycle for this project S-shaped, J-shaped, or something else? Considering just the purpose of the river dredging as a project itself, what was the shape of its life cycle? 35. Were there any ancillary goals for this project? What might they have been? 36. Which of the project-defining factors in Section 1.1 were active here?

A Unique Method for Traveler Tracking at Copenhagen Airport

27. What was unique about this project? What was the main conflict?

INCIDENTS FOR DISCUSSION Blanka Transport, Inc.

After several years of driving long-haul trucks, Joe Blanka founded his own trucking company, Blanka Transport Inc. (BTI), which specialized in less-than-carload shipments in the midwestern part of the United States. Joe developed a successful method for scheduling BTI’s runs that met or exceeded the delivery expectations of its customers. As a result, BTI shipments were growing at a rate between 15 and 20 percent per year. The growth, however, was not evenly distributed across BTI’s territory. On some routes, capacity was overloaded in one direction and underloaded in the other. Joe noticed that the imbalance problem was not stable across time. In some months capacity was short in one direction, and in other months it was short in another direction. He thought that one way of solving the problem would be through marketing, by offering incentives to customers

whose shipments would improve load balance. Another approach to the problem was to analyze and restructure the route–equipment combinations. He also thought that it might be possible to warehouse some less-urgent shipments for short periods in order to help the balance. Joe’s son, the first member of the Blanka family to attend college, was a senior in engineering school. He had just completed a course in project management, and after briefly describing some of the basic concepts to his father, he suggested that a project might be a good way to deal with the balance problem. He thought that the Marketing Manager and the Route Manager could serve as project co-managers. He also felt that some of the older, more experienced drivers might be helpful. The objective of the project would be to decrease the size of the route imbalances by 75 percent in a 1-year period.

28

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Questions: Is this a proper approach to the problem? What, if any, helpful suggestions would you make to Joe? Maladroit Cosmetics Company

The plant manager of the Maladroit Cosmetics Company must replace several of her filling machines that have become obsolete. She is about to take delivery of six machines at a total cost of $4 million. These machines must be installed and fully tested in time to be used on a new production line scheduled to begin operation in six months. Because this project is important, the plant manager would like to devote as much time as possible to the job, but she is currently

handling several other projects. She thinks she has three basic choices: (1) she can handle the project informally out of her office; (2) she can assign the project to a member of her staff; or (3) the company that manufactures the machines can handle the installation project for a fee close to what the installation would cost Maladroit. Questions: Which of the three choices do you recommend, and why? If the project was one small machine at a total cost of $4,000, would your answer be different? Discuss the relative importance of the capital investment required versus the role of the investment in machinery.

CONTINUING INTEGRATIVE CLASS PROJECT It often helps in communicating the process, difficulties, and satisfactions of project management if the class can do a team project together during the term of the course. The instructor may have a pre-chosen project for the class to work on, perhaps in a local organization, or the school itself (where there are many excellent projects: the cafeteria, parking, library, counseling, class scheduling, etc.), but if not, the following project is offered as an alternative. The project is to prepare a “Student Study Guide” for this course, due (time requirement) on the last day of the course before the final examination. The purpose of the guide is to help the students learn the material of the course, both by preparing the guide as well as using it to study for the final examination. The requirements (scope) for the guide are as follows:

• • • • • • •

a professional-looking appearance a consistent approach throughout the chapters a copy for every student, as well as the Instructor presented in either hard copy CD, flash memory, or electronic (e.g., web) form (check with your Instructor) everyone in class must participate, with one exception noted further below. if subteams are used, they must not be organized to operate independently of each other (for example, by doing all the work on one of the chapters). the project plans can be constructed manually or in Microsoft Project® or another software program (check with your Instructor)

In addition, one student will be appointed as “Historian,” whose job is to monitor and prepare a written report on the progress of the project over its duration. This includes both the tasks to be accomplished, but also the attitude and spirit of the Project Manager (PM), the project team and/or subteams, and the various stakeholders in the project (team members, Instructor,

future students who may use the Guide) as well as the culture and environment of the project. The main task of the Historian is to compare the reality of the class project to that described in the textbook and point out in the written report similarities and differences that will be recognizable by the PM and team members. The Historian will have no work to do on the project itself, but will need to sit in on meetings, confer with the PM and subteam heads, talk to team members occasionally, confer with the Instructor, and other such activities as needed to properly monitor task progress. The role of this person is especially critical for the class to learn how closely their project followed the typical path of a normal project, what problems arose and how they should have been handled, and so forth. As a result, this person should probably be selected by the Instructor right at the beginning of the course. There may also be some expenses (budget requirement), such as photocopying costs and travel expenses, that may require assistance from the Instructor. Usually these costs are minor, but it depends on the project. Of course, in a real project the major cost would be the labor/personnel costs of the team members doing the work, a cost that is essentially “free” here. In future chapters we will continue to develop the various elements of the project, such as selecting the PM, organizing the team, scheduling the deliverables, and monitoring progress. However, executing the requisite tasks of the project takes the most time in a real project but is a topic that is outside the scope of this text, which concerns only the generic tasks of project management. (Every project will have different tasks associated with it, many with very technical requirements.) Therefore, it will be necessary to forge ahead and do all the preparatory project elements, particularly in Parts I and II of the book, so that progress on the project tasks can begin right away. It would, of course, be best if the class could read all the material up to Chapter 10, which initiates Part III: Project Execution, where the work begins, before actually starting the project. Unfortunately, the course would be almost over by then and it would be too

APPENDIX: PMI CERTIFICATIONS

late to start a project. As a result, the PM and the class will have to skip ahead and read the Continuing Integrative Class Project assignments, at least for Chapters 2–10 now; hopefully, they will discover in retrospect how they could have conducted each of the various elements of the project better. But for right now, it is most important to cover the project elements in Chapters 2 and 3—what the project will be and

29

who will be the PM, respectively, so the project can get underway ASAP. It is best to do these two elements in the very first class, the first one in consultation with the Instructor, and the second one with the Instructor ABSENT from the room but with instructions for where to find him or her once the class has selected the PM, hopefully within 20 minutes but most certainly by the end of the class. Good luck!

BIBLIOGRAPHY Cioffi, D. F. Personal communication, 2004. Collyer, S., C. Warren, B. Hemsley, and C. Stevens. “Aim, Fire, Aim—Project Planning Styles in Dynamic Environments.” Project Management Journal, September 2010. Darnell, R. “The Emerging Role of the Project Manager.” PM Network, July 1997. Davis, E. W. “CPM Use in Top 400 Construction Firms.” Journal of the Construction Division, American Society of Civil Engineers, 1974. Davis, E. W. Project Management: Techniques, Applications, and Managerial Issues, 2nd ed. Norcross, GA: AIIE Monograph, 1983. Gido, J., and J. P. Clements. Successful Project Management, with Microsoft Project 2003 CD-ROM. Cincinnati: Thompson/South-Western, 2004. Grey, C. F., and E. W. Larson. Project Management: The Managerial Process. New York: McGraw-Hill/Irwin, 2005. Hughes, T. P. Rescuing Prometheus. New York, Pantheon, 1998. Ibbs, C. W., and Y. H. Kwak. “Measuring Project Management’s Return on Investment.” PM Network, November 1997.

Ibbs, C. W., and Y. H. Kwak. “Assessing Project Management Maturity.” Project Management Journal, March 2000. Kerzner, H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 8th ed. New Jersey: Wiley, 2003. Pande, P. S., R. P. Newman, and R. R. Cavanagh. The Six Sigma Way, New York: McGraw-Hill, 2000. Project Management Institute. A Guide to the Project Management Body of Knowledge, 4th ed. Newtown Square, PA: Project Management Institute, 2008. Pyzdek, T. The Six Sigma Handbook, rev. ed., New York: McGraw-Hill, 2003. Sandberg, J. “Rise of False Deadline Means Truly Urgent Often Gets Done Late.” Wall Street Journal, January 24, 2007. Shenhar, A. J., O. Levy, and D. Dvir. “Mapping the Dimensions of Project Success.” Project Management Journal, June 1997. Starkweather, J. A., and D. H. Stevens. “PMP® Certification as a Core Competency: Necessary but Not Sufficient.” Project Management Journal, February 2011. Sun, M. “Weighing the Social Costs of Innovation.” Science, March 30, 1984.

APPENDIX: PMI CERTIFICATIONS We discuss here only the CAPM® and PMP® certifications. For information on the other credentials, please visit the PMI website at www.pmi.org.

Certified Associate in Project Management (CAPM®): This is the “entry level” credential which typically leads to qualifying for the full Project Management Professional (PMP®) credential, although a candidate can maintain their CAPM® certification by retaking the exam every 5 years. It is mainly for project team members with 1500 hours of documented experience or for those who can verify they have taken 23 face-to-face hours of project management classroom education or training. The exam is 3 hours to complete 150 questions and costs $225 to sit for the exam.

Project Management Professional (PMP®): This is the longstanding standard certification that a person is fully competent in project management and regularly lead and direct project teams. The credential is maintained by gaining 60 PDUs every three years. To sit for the exam, a candidate must have a high school education plus five years of documented project management experience and can verify they have taken 35 hours of face-to-face project management classroom education or training. Alternatively, a candidate can demonstrate that they have a bachelor’s degree (or global equivalent) plus three years of documented project management experience and can verify they have taken 35 hours of project management classroom education or training. The exam is 4 hours to complete 200 questions and costs $405 to sit for the exam.

30

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

The following reading describes the common occurrence of someone suddenly being appointed a project manager and finding he or she has been inadequately trained for the task. Based on the authors’ own experiences and interviews with dozens of senior project managers, they distill twelve guidelines for new project managers. The guidelines run the gamut

D I R E C T E D

from project initiation, through planning, to execution and close-out. Some are technical, some are uncommon sense, and many are philosophical, and sometimes political. But they are sage advice, not only for the novice but for the experienced project manager as well.

R E A D I N G

LESSONS FOR AN ACCIDENTAL PROFESSION* J. K. Pinto and O. P. Kharbanda

Projects and project management are the wave of the future in global business. Increasingly technically complex products and processes, vastly shortened time-to-market windows, and the need for cross-functional expertise make project management an important and powerful tool in the hands of organizations that understand its use. But the expanded use of such techniques is not always being met by a concomitant increase in the pool of competent project managers. Unfortunately, and perhaps ironically, it is the very popularity of project management that presents many organizations with their most severe challenges. They often belatedly discover that they simply do not have sufficient numbers of the sorts of competent project managers who are often the key driving force behind successful product or service development. Senior managers in many companies readily acknowledge the ad hoc manner in which most project managers acquire their skills, but they are unsure how to better develop and provide for a supply of well-trained project leaders for the future. In this article, we seek to offer a unique perspective on this neglected species. Though much has been written on how to improve the process of project management, less is known about the sorts of skills and challenges that specifically characterize project managers. What we do know tends to offer a portrait of successful project managers as strong leaders, possessing a variety of problem-solving, communication, motivational, visionary, and team-building skills. Authors such as Posner (1987), Einsiedel (1987), and Petterson (1991) are correct. Project managers are a special breed. Managing projects is a unique challenge that requires a strategy and methodology

all its own. Perhaps most important, it requires people willing to function as leaders in every sense of the term. They must not only chart the appropriate course, but provide the means, the support, and the confidence for their teams to attain these goals. Effective project managers often operate less as directive and autocratic decision makers than as facilitators, team members, and cheerleaders. In effect, the characteristics we look for in project managers are varied and difficult to pin down. Our goal is to offer some guidelines for an accidental profession, based on our own experiences and interviews with a number of senior project managers—most of whom had to learn their own lessons the hard way.

“Accidental” Project Managers Project managers occupy a unique and often precarious position within many firms. Possessing little formal authority and forced to operate outside the traditional organizational hierarchy, they quickly and often belatedly learn the real limits of their power. It has been said that an effective project manager is the kingpin, but not the king. They are the bosses, it is true, but often in a loosely defined way. Indeed, in most firms they may lack the authority to conduct performance appraisals and offer incentives and rewards to their subordinates. As a result, their management styles must be those of persuasion and influence, rather than coercion and command. Because of these and other limitations on the flexibility and power of project managers, project management has

*Reprinted from Business Horizons with permission. Copyright Indiana University Kelly School of Business. (Additional copyright information for cases and readings can be found on the credits page following Chapter 13.)

DIRECTED READING

rightly been termed the “accidental profession” by more than one writer. There are two primary reasons for this sobriquet. First, few formal or systematic programs exist for selecting and training project managers, even within firms that specialize in project management work. This results at best in ad hoc training that may or may not teach these people the skills they need to succeed. Most project managers fall into their responsibilities by happenstance rather than by calculation. Second, as Frame (1987) cogently observed, few individuals grow up with the dream of one day becoming a project manager. It is neither a well-defined nor a well-understood career path within most modern organizations. Generally, the role is thrust upon people, rather than being sought. Consider the typical experiences of project managers within many corporations. Novice managers, new to the company and its culture, are given a project to complete with the directive to operate within a set of narrowly defined constraints. These constraints most commonly include a specified time frame for completion, a budget, and a set of performance characteristics. Those who are able to quickly master the nature of their myriad duties succeed; those who do not generally fail. This “fly or die” mentality goes far toward creating an attitude of fear among potential project managers. Generation after generation of them learn their duties the hard way, often after having either failed completely or stumbled along from one crisis to another. The predictable result is wasteful: failed projects; managers battling entrenched bureaucracy and powerful factions; money, market opportunities, and other resources irretrievably lost to the company. The amazing part of this scenario is that it is repeated again and again in company after company. Rather than treating project management as the unique and valuable discipline it is, necessitating formal training and selection policies, many companies continue to repeat their past mistakes. This almost leads one to believe they implicitly view experience and failure as the best teacher. We need to shed light on the wide range of demands, opportunities, travails, challenges, and vexations that are part of becoming a better project manager. Many of the problems these individuals struggle with every day are far more managerial or behavioral in nature than technical. Such behavioral challenges are frequently vexing, and though they can sometimes seem inconsequential, they have a tremendous impact on the successful implementation of projects. For example, it does not take long for many project managers to discover exactly how far their personal power and status will take them in interacting with the rest of the organization. Hence, an understanding of influence tactics and political behavior is absolutely essential. Unfortunately, novice project managers are rarely clued into this important bit of information until it is too late—until, perhaps, they have appealed through formal channels for extra resources and been denied.

31

Consider the following examples:

A long-distance telephone company whose CEO became so enamored of the concept of high-profile project teams—or “skunkworks,” as they have come to be called—that he assigned that title to the few most highly visible, strategically important projects. Quickly, both senior and middle managers in departments across the organization came to realize that the only way to get their pet projects the resources necessary to succeed was to redesignate all new projects as “skunkworks.” At last report, there were more than 75 high-profile skunkworks projects whose managers report directly to the CEO. The company now has severe difficulties in making research allocation decisions among its projects and routinely underfunds some vital projects while overfunding other, less important ones. A large computer hardware manufacturer has been dominated by the members of the hardware engineering department to such an extent that practically all new product ideas originate internally, within the department. By the time marketing personnel (sneeringly called “order takers” by the engineering department) are brought on board, they are presented with a fait accompli: a finished product they are instructed to sell. Marketing managers are now so cynical about new projects that they usually do not even bother sending a representative to new product development team meetings. A medium-sized manufacturing firm made it a policy to reward and punish project managers on the basis of their ability to bring projects in on time and under budget. These project managers were never held to any requirement that the project be accepted by its clients or become commercially successful. They quickly learned that their rewards were simply tied to satisfying the cost accountants, so they began to cut corners and make decisions that seriously undermined product quality. Projects in one division of a large, multinational corporation are routinely assigned to new managers who often have less than one year of experience with the company. Given a project scheduling software package and the telephone number of a senior project manager to be used “only in emergencies,” they are instructed to form their project teams and begin the development process without any formal training or channels of communication to important clients and functional groups. Not surprisingly, senior managers at this company estimate that fewer than 30 percent of new product development efforts are profitable. Most take so long to develop, or incur such high cost overruns, that they are either abandoned before scheduled introduction or never live up to their potential in the marketplace.

32

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

This ad hoc approach to project management—coupled, as it frequently is, with an on-the-job training philosophy— is pervasive. It is also pernicious. Under the best of circumstances, project managers are called upon to lead, coordinate, plan, and control a diverse and complex set of processes and people in the pursuit of achieving project objectives. To hamper them with inadequate training and unrealistic expectations is to unnecessarily penalize them before they can begin to operate with any degree of confidence or effectiveness. The successful management of projects is simultaneously a human and technical challenge, requiring a far-sighted, strategic outlook coupled with the flexibility to react to conflicts and trouble areas as they arise on a daily basis. The project managers who are ultimately successful at their profession must learn to deal with and anticipate the constraints on their project team and personal freedom of action while consistently keeping their eyes on the ultimate prize.

From Whence Comes the Challenge? One of the most intriguing and challenging aspects of project management lies in the relationship of project teams to the rest of the parent organization. With the exception of companies that are set up with matrix or project structures, most firms using project management techniques employ some form of standard functional structure. When project teams are added to an organization, the structural rules change dramatically. The vast majority of personnel who serve on project teams do so while maintaining links back to their functional departments. In fact, they typically split their time between the project and their functional duties. The temporary nature of projects, combined with the very real limitations on power and discretion most project managers face, constitutes the core challenge of managing projects effectively. Clearly the very issues that characterize projects as distinct from functional work also illustrate the added complexity and difficulties they create for project managers. For example, within a functional department it is common to find people with more homogeneous backgrounds. This means that the finance department is staffed with finance people, the marketing department is made up of marketers, and so on. On the other hand, most projects are constructed from special, cross-functional teams composed of representatives from each of the relevant functional departments, who bring their own attitudes, time frames, learning, past experiences, and biases to the team. Creating a cohesive and potent team out of this level of heterogeneity presents a challenge for even the most seasoned and skilled of project managers. But what is the ultimate objective? What determines a successful project and how does it differ from projects we may rightfully consider to have failed? Any seasoned project manager will usually tell you that a successful project is

one that has come in on time, has remained under budget, and performs as expected (that is, it conforms to specifications). Recently, though, there has been a reassessment of this traditional model for project success. The old triple constraint is rapidly being replaced by a new model, invoking a fourth hurdle for project success: client satisfaction. This means that a project is only successful if it satisfies the needs of its intended user. As a result, client satisfaction places a new and important constraint on project managers. No wonder, then, that there is a growing interest in the project manager’s role within the corporation.

The Vital Dozen for Project Managers Over the last several years, we have conducted interviews with dozens of senior project managers in which we asked them a simple question: “What information were you never given as a novice project manager that, in retrospect, could have made your job easier?” From the data gathered in these interviews, we have synthesized some of the more salient issues, outlined in Figure 1 and detailed below, that managers need to keep in mind when undertaking a project implementation effort. While not intended to appear in any particular order, these 12 rules offer a useful way to understand the challenge project managers face and some ways to address these concerns. 1. Understand the context of project management. Much of the difficulty in becoming an effective project manager lies in understanding the particular challenges project management presents in most corporations. Projects are a unique form of organizational work, playing an important role within many public and private organizations today. They act as mechanisms for the effective introduction of new products and services. They offer a level of intraorganizational efficiency that all companies seek but few find. But they also

1. Understand the context of project management. 2. Recognize project team conflict as progress. 3. Understand who the stakeholders are and what they want. 4. Accept and use the political nature of organizations. 5. Lead from the front. 6. Understand what “success”means. 7. Build and maintain a cohesive team. 8. Enthusiasm and despair are both infectious. 9. One look forward is worth two looks back. 10. Remember what you are trying to do. 11. Use time carefully or it will use you. 12. Above all, plan, plan, plan. Figure 1 Twelve points to remember.

DIRECTED READING

force managers to operate in a temporary environment outside the traditional functional lines of authority, relying upon influence and other informal methods of power. In essence, it is not simply the management of a project per se that presents such a unique challenge; it is also the atmosphere within which the manager operates that adds an extra dimension of difficulty. Projects exist outside the established hierarchy. They threaten, rather than support, the status quo because they represent change. So it is important for project managers to walk into their assigned role with their eyes wide open to the monumental nature of the tasks they are likely to face. 2. Recognize project team conflict as progress. One of the common responses of project managers to team conflict is panic. This reaction is understandable in that project managers perceive—usually correctly—that their reputation and careers are on the line if the project fails. Consequently, any evidence they interpret as damaging to the prospects of project success, such as team conflict, represents a very real source of anxiety. In reality, however, these interpersonal tensions are a natural result of putting individuals from diverse backgrounds together and requiring them to coordinate their activities. Conflict, as evidenced by the stages of group development, is more often a sign of healthy maturation in the group. The result of differentiation among functional departments demonstrates that conflict under these circumstances is not only possible but unavoidable. One of the worst mistakes a project manager can make when conflicts emerge is to immediately force them below the surface without first analyzing the nature of the conflict. Although many interpersonal conflicts are based on personality differences, others are of a professional nature and should be addressed head-on. Once a project manager has analyzed the nature of the conflict among team members, a variety of conflict handling approaches may be warranted, including avoidance, defusion, or problem-solving. On the other hand, whatever approach is selected should not be the result of a knee-jerk reaction to suppress conflict. In our experience, we have found many examples that show that even though a conflict is pushed below the surface, it will continue to fester if left unaddressed. The resulting eruption, which will inevitably occur later in the project development cycle, will have a far stronger effect than would the original conflict if it had been handled initially. 3. Understand who the stakeholders are and what they want. Project management is a balancing act. It requires managers to juggle the various and often conflicting demands of a number of powerful project stakeholders. One of the best tools a project manager can use is to develop a realistic assessment early in the project identifying the principal stakeholders and their agendas. In some projects, particularly those with important external clients or constituent groups, the number of stakeholders may be quite

33

large, particularly when “intervenor” groups are included. Intervenors, according to Cleland (1983), may include any external group that can drastically affect the potential for project success, such as environmental activists in a nuclear plant construction project. Project managers who acknowledge the impact of stakeholders and work to minimize their effect by fostering good relations with them are often more successful than those who operate in a reactive mode, continually surprised by unexpected demands from groups that were not initially considered. As a final point about stakeholders, it is important for a project manager’s morale to remember that it is essentially impossible to please all the stakeholders all the time. The conflicting nature of their demands suggests that when one group is happy, another is probably upset. Project managers need to forget the idea of maximizing everyone’s happiness and concentrate instead on maintaining satisfactory relations that allow them to do their job with a minimum of external interference. 4. Accept the political nature of organizations and use it to your advantage. Like it or not, we exist in a politicized world. Unfortunately, our corporations are no different. Important decisions involving resources are made through bargaining and deal-making. So project managers who wish to succeed must learn to use the political system to their advantage. This involves becoming adept at negotiation as well as using influence tactics to further the goals of the project. At the same time, it is important to remember that any project representing possible organizational change is threatening, often because of its potential to reshuffle the power relationships among the key units and actors. Playing the political system acknowledges this reality. Successful project managers are those who can use their personal reputations, power, and influence to ensure cordial relations with important stakeholders and secure the resources necessary to smooth the client’s adoption of the project. Pursuing a middle ground of political sensibility is the key to project implementation success. There are two alternative and equally inappropriate approaches to navigating a firm’s political waters: becoming overly political and predatory—we call these people “sharks”—and refusing to engage in politics to any degree—the politically “naive.” Political sharks and the politically naive are at equal disadvantage in managing their projects: sharks because they pursue predatory and self-interested tactics that arouse distrust, and the naive because they insist on remaining above the fray, even at the cost of failing to attain and keep necessary resources for their projects. Figure 2 illustrates some of the philosophical differences among the three types of political actors. The process of developing and applying appropriate political tactics means using politics as it can most effectively be used: as a basis for negotiation and bargaining. “Politically sensible” implies being politically sensitive to the concerns (real or

34

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

Characteristics Underlying Attitude Intent Techniques

Naive Politics is unpleasant Avoid at all costs Tell it like it is

Sensible Politics is necessary Further departmental goals Network; expand connections;

use system to give and receive favors Favorite Tactics

Figure 2

None—the truth will win out

Negotiate, bargain

Sharks Politics is an opportunity Self-serving and predatory Manipulate; use fraud and deceit when necessary Bully; misuse information; cultivate and use “friends” and other contacts

Characteristics of political behaviors.

imagined) of powerful stakeholder groups. Legitimate or not, their concerns over a new project are real and must be addressed. Politically sensible managers understand that initiating any sort of organizational disruption or change by developing a new project is bound to reshuffle the distribution of power within the firm. That effect is likely to make many departments and managers very nervous as they begin to wonder how the future power relationships will be rearranged. Appropriate political tactics and behavior include making alliances with powerful members of other stakeholder departments, networking, negotiating mutually acceptable solutions to seemingly insoluble problems, and recognizing that most organizational activities are predicated on the give-and-take of negotiation and compromise. It is through these uses of political behavior that managers of project implementation efforts put themselves in the position to most effectively influence the successful introduction of their systems. 5. Lead from the front; the view is better. One message that comes through loud and clear is that project management is a “leader intensive” undertaking. Strong, effective leaders can go a long way toward helping a project succeed even in the face of a number of external or unforeseen problems. Conversely, a poor, inflexible leader can often ruin the chances of many important projects ever succeeding. Leaders are the focal point of their projects. They serve as a rallying point for the team and are usually the major source of information and communication for external stakeholders. Because their role is so central and so vital, it is important to recognize and cultivate the attributes project “leaders” must work to develop. The essence of leadership lies in our ability to use it flexibly. This means that not all subordinates or situations merit the same response. Under some circumstances an autocratic approach is appropriate; other situations will be far better served by adopting a consensual style. Effective project leaders seem to understand this idea intuitively. Their approach must be tailored to the situation; it is self-defeating to attempt to tailor the situation to a preferred approach. The

worst leaders are those who are unaware of or indifferent to the freedom they have to vary their leadership styles. And they see any situation in which they must involve subordinates as inherently threatening to their authority. As a result, they usually operate under what is called the “Mushroom” Principle of Management.” That is, they treat their subordinates the same way they would raise a crop of mushrooms— by keeping them in the dark and feeding them a steady diet of manure. Flexible leadership behavior consists of a realistic assessment of personal strengths and weaknesses. It goes without saying that no one person, including the project manager, possesses all necessary information, knowledge, or expertise to perform the project tasks on his own. Rather, successful project managers usually acknowledge their limitations and work through subordinates’ strengths. In serving as a facilitator, one of the essential abilities of an exceptional project manager is knowing where to go to seek the right help and how to ask the right questions. Obviously, the act of effective questioning is easier said than done. However, bear in mind that questioning is not interrogation. Good questions challenge subordinates without putting them on the spot; they encourage definite answers rather than vague responses, and they discourage guessing. The leader’s job is to probe, to require subordinates to consider all angles and options, and to support them in making reasoned decisions. Direct involvement is a key component of a leader’s ability to perform these tasks. 6. Understand what “success” means. Successful project implementation is no longer subject to the traditional “triple constraint.” That is, the days when projects were evaluated solely on adherence to budget, schedule, and performance criteria are past. In modern business, with its increased emphasis on customer satisfaction, we have to retrain project managers to expand their criteria for project success to include a fourth item: client use and satisfaction. What this suggests is that project “success” is a far more comprehensive word than some managers may have initially thought. The implication for rewards is also important. Within some organizations that regularly implement

DIRECTED READING

projects, it is common practice to reward the implementation manager when, in reality, only half the job has been accomplished. In other words, giving managers promotions and commendations before the project has been successfully transferred to clients, is being used, and is affecting organizational effectiveness is seriously jumping the gun. Any project is only as good as it is used. In the final analysis, nothing else matters if a system is not productively employed. Consequently, every effort must be bent toward ensuring that the system fits in with client needs, that their concerns and opinions are solicited and listened to, and that they have final sign-off approval on the transferred project. In other words, the intended user of the project is the major determinant of its success. Traditionally, the bulk of the team’s efforts are centered internally, mainly on their own concerns: budgets, timetables, and so forth. Certainly, these aspects of the project implementation process are necessary, but they should not be confused with the ultimate determinant of success: the client. 7. Build and maintain a cohesive team. Many projects are implemented through the use of cross-functional teams. Developing and maintaining cordial team relations and fostering a healthy intergroup atmosphere often seems like a fulltime job for most project managers. However, the resultant payoff from a cohesive project team cannot be overestimated. When a team is charged to work toward project development and implementation, the healthier the atmosphere within that team, the greater the likelihood the team will perform effectively. The project manager’s job is to do whatever is necessary to build and maintain the health (cohesion) of the team. Sometimes that support can be accomplished by periodically checking with team members to determine their attitudes and satisfaction with the process. Other times the project manager may have to resort to less conventional methods, such as throwing parties or organizing field trips. To effectively intervene and support a team, project managers play a variety of roles—motivator, coach, cheerleader, peacemaker, conflict resolver. All these duties are appropriate for creating and maintaining an effective team. 8. Enthusiasm and despair are both infectious. One of the more interesting aspects of project leaders is that they often function like miniaturized billboards, projecting an image and attitude that signals the current status of the project and its likelihood for success. The team takes its cue from the attitudes and emotions the manager exhibits. So one of the most important roles of the leader is that of motivator and encourager. The worst project managers are those who play their cards close to their chests, revealing little or nothing about the status of the project (again, the “Mushroom Manager”). Team members want and deserve to be kept abreast of what is happening. It is important to remember that the success or failure of the project affects the team as well as the manager. Rather than allowing the rumor mill to churn out disinformation, team leaders need to function as honest

35

sources of information. When team members come to the project manager for advice or project updates, it is important to be honest. If the manager does not know the answer to the questions, he should tell them that. Truth in all forms is recognizable, and most project team members are much more appreciative of honesty than of eyewash. 9. One look forward is worth two looks back. A recent series of commercials from a large computer manufacturer had as their slogan the dictum that the company never stop asking “What if?.” Asking “What if?” questions is another way of saying we should never become comfortable with the status of the project under development. One large-scale study found that the leading determinant of project failure was the absence of any troubleshooting mechanisms—that is, no one was asking the “What if?” questions. Projecting a skeptical eye toward the future may seem gloomy to some managers. But in our opinion, it makes good sense. We cannot control the future but we can actively control our response to it. A good example of the failure to apply this philosophy is evidenced by the progress of the “Chunnel” intended to link Great Britain with France. Although now in full operation, it was not ready for substantial traffic until some 15 months later than originally scheduled. As a result, Chunnel traffic missed the major summer vacation season with a concomitant loss in revenue. At the same time, the final cost (£15 billion) is likely to be six times the original estimate of £2.3 billion (O’Connor, 1993). It is instructive to take note of a recent statement by one of the project’s somewhat harassed directors who, when pressed to state when the Chunnel would be ready, replied, “Now it will be ready when it’s ready and not before!” Clearly, the failure to apply adequate contingency planning has led to the predictable result: a belief that the project will simply end when it ends. 10. Remember what you are trying to do. Do not lose sight of the purpose behind the project. Sometimes it is easy to get bogged down in the minutiae of the development process, fighting fires on a daily basis and dealing with thousands of immediate concerns. The danger is that in doing so, project managers may fail to maintain a view of what the end product is supposed to be. This point reemphasizes the need to keep the mission in the forefront—and not just the project manager, but the team as well. The goal of the implementation serves as a large banner the leader can wave as needed to keep attitudes and motives focused in the right direction. Sometimes a superordinate goal can serve as a rallying point. Whatever technique project managers use, it is important that they understand the importance of keeping the mission in focus for all team members. A simple way to discover whether team members understand the project is to intermittently ask for their assessment of its status. They should know how their contributions fit into the overall installation plan. Are they aware of the specific contributions of other team members? If no, more attention

36

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

needs to be paid to reestablishing a community sense of mission. 11. Use time carefully or it will use you. Time is a precious commodity. Yet when we talk to project managers, it seems that no matter how hard they work to budget it, they never have enough. They need to make a realistic assessment of the “time killers” in their daily schedule: How are they spending their time and what are they doing profitably or unprofitably? We have found that the simple practice of keeping a daily time log for a short time can be an eyeopening experience. Many project managers discover that they spend far too much of their time in unproductive ways: project team meetings without agendas that grind on and on, unexpected telephone calls in the middle of planning sessions, quick “chats” with other managers that end up taking hours, and so forth. Efficient time management—one of the keys to successful project development—starts with project managers. When they actively plan their days and stick to a time budget, they usually find they are operating efficiently. On the other hand, when they take each problem as it comes and function in an ad hoc, reactive mode, they are likely to remain prisoners of their own schedules. A sure recipe for finding the time and resources needed to get everything done without spending an inordinate amount of time on the job or construction site is provided by Gosselin (1993). The author lists six practical suggestions to help project managers control their tasks and projects without feeling constantly behind schedule:

• • • • • •

Create a realistic time estimate without overextending yourself. Be absolutely clear about what the boss or client requires. Provide for contingencies (schedule slippage, loss of key team member). Revise original time estimate and provide a set of options as required. Be clear about factors that are fixed (specifications, resources, and so on). Learn to say “Yes, and . . .” rather than “No, but . . .” Negotiation is the key.

12. Above all, plan, plan, plan. The essence of efficient project management is to take the time to get it as right as possible the first time. “It” includes the schedule, the team composition, the project specifications, and the budget. There is a truism that those who fail to plan are planning to fail. One of the practical difficulties with planning is that so many of us distinguish it from other aspects of the project development, such as doing the work. Top managers are often particularly guilty of this offense as they wait impatiently for the project manager to begin doing the work. Of course, too much planning is guaranteed to elicit repeated and pointed questions from top management and

other stakeholders as they seek to discover the reason why “nothing is being done.” Experienced project managers, though, know that it is vital not to rush this stage by reacting too quickly to top management inquiries. The planning stage must be managed carefully to allow the project manager and team the time necessary to formulate appropriate and workable plans that will form the basis for the development process. Dividing up the tasks and starting the “work” of the project too quickly is often ultimately wasteful. Steps that were poorly done are often steps that must be redone. A complete and full investigation of any proposed project does take significant time and effort. However, bear in mind that overly elaborate or intricate planning can be detrimental to a project; by the time an opportunity is fully investigated, it may no longer exist. Time and again we have emphasized the importance of planning, but it is also apparent that there comes a limit, both to the extent and the time frame of the planning cycle. A survey among entrepreneurs, for example, revealed that only 28 percent of them drew up a full-scale plan (Sweet, 1994). A lesson here for project managers is that, like entrepreneurs, they must plan, but they must also be smart enough to recognize mistakes and change their strategy accordingly. As is noted in an old military slogan, “No plan ever survives its first contact with the enemy.”

Project Managers in the Twenty-First Century In our research and consulting experiences, we constantly interact with project managers, some with many years of experience, who express their frustration with their organizations because of the lack of detailed explication of their assigned tasks and responsibilities. Year after year, manager after manager, companies continue to make the same mistakes in “training” their project managers, usually through an almost ritualized baptism of fire. Project managers deserve better. According to Rodney Turner (1993), editor of the International Journal of Project Management: Through the 90’s and into the 21st century, projectbased management will sweep aside traditional functional line management and (almost) all organizations will adopt flat, flexible organizational structures in place of the old bureaucratic hierarchies . . . [N]ew organizational structures are replacing the old . . . [M]anagers will use project-based management as a vehicle for introducing strategic planning and for winning and maintaining competitive advantage. Turner presents quite a rosy future, one that is predicated on organizations recognizing the changes they are currently undergoing and are likely to continue to see in the years ahead. In this challenging environment, project management

DIRECTED READING

is emerging as a technique that can provide the competitive edge necessary to succeed, given the right manager. At the same time, there seems to have been a sea change in recent years regarding the image of project managers. The old view of the project manager as essentially that of a decision maker, expert, boss, and director seems to be giving way to a newer ideal: that of a leader, coach, and facilitator. Lest the reader assume these duties are any easier, we would assert that anyone who has attempted to perform these roles knows from personal experience just how difficult they can be. As part of this metamorphosis, says Clarke (1993), the new breed of project manager must be a natural salesperson who can establish harmonious customer (client) relations and develop trusting relationships with stakeholders. In addition to some of the obvious keys to project managers’ success— personal commitment, energy, and enthusiasm—it appears that, most of all, successful project managers must manifest an obvious desire to see others succeed. For successful project managers, there will always be a dynamic tension between the twin demands of technical training and an understanding of human resource needs. It must be clearly understood, however, that in assessing the relative importance of each challenge, the focus must clearly be on managing the human side of the process. As research and practice consistently demonstrate, project management is primarily a challenge in managing people. This point was recently brought to light in an excellent review of a book on managing the “human side” of projects (Horner, 1993): There must be many project managers like me who come from a technological background, and who suffered an education which left them singularly illprepared to manage people. Leading researchers and scholars perceive the twentyfirst century as the upcoming age of project management. The globalization of markets, the merging of many European economies, the enhanced expenditures of money on capital improvement both in the United States and abroad, the rapidly opening borders of Eastern European and Pacific Rim countries, with their goals of rapid infrastructure expansion—all of this offers an eloquent argument for the enhanced popularity of project management as a technique for improving the efficiency and effectiveness of organizational operations. With so much at stake, it is vital that we immediately begin to address some of the deficiencies in our project management theory and practice. Project management techniques are well known. But until we are able to take further steps toward formalizing training by teaching the necessary skill set, the problems with efficiently developing, implementing, and gaining client acceptance for these projects are likely to continue growing. There is currently a true window of opportunity in the field of project management. Too often in the past, project managers have been forced to learn their skills the hard way,

37

through practical experience coupled with all the problems of trial and error. Certainly, experience is a valuable component of learning to become an effective project manager, but it is by no means the best. What conclusions are to be drawn here? If nothing else, it is certain that we have painted a portrait of project management as a complex, time-consuming, often exasperating process. At the same time, it is equally clear that successful project managers are a breed apart. To answer the various calls they continually receive, balance the conflicting demands of a diverse set of stakeholders, navigate tricky corporate political waters, understand the fundamental process of subordinate motivation, develop and constantly refine their leadership skills, and engage in the thousands of pieces of detailed minutiae while keeping their eyes fixed firmly on project goals requires individuals with special skills and personalities. Given the nature of their duties, is it any wonder successful project managers are in such short supply and, once identified, so valued by their organizations? There is good news, however. Many of these skills, though difficult to master, can be learned. Project management is a challenge, not a mystery. Indeed, it is our special purpose to demystify much of the human side of project management, starting with the role played by the linchpin in the process: the project manager. The problem in the past has been too few sources for either seasoned or novice project managers to turn to in attempting to better understand the nature of their unique challenge and methods for performing more effectively. Too many organizations pay far too little attention to the process of selecting, training, and encouraging those people charged to run project teams. The predictable result is to continually compound the mistake of creating wave after wave of accidental project managers, forcing them to learn through trial and error with minimal guidance in how to perform their roles. Managing a project is a challenge that requires a strategy and methodology all its own. Perhaps most important, it requires a project manager willing to function as a leader in every sense of the term. We have addressed a wide range of challenges, both contextual and personal, that form the basis under which projects are managed in today’s organizations. It is hoped that readers will find something of themselves as well as something of use contained in these pages. References B. N. Baker, P. C. Murphy, and D. Fisher, “Factors Affecting Project Success,” in D. I. Cleland and W. R. King, eds., Project Management Handbook (New York: Van Nostrand Reinhold, 1983): 778–801. K. Clarke, “Survival Skills for a New Breed,” Management Today, December 1993, p. 5.

38

CHAPTER 1 / PROJECTS IN CONTEMPORARY ORGANIZATIONS

D. I. Cleland, “Project Stakeholder Management,” in D. I. Cleland and W. R. King, eds., Project Management Handbook (New York:Van Nostrand Reinhold, 1983): 275–301. J. C. Davis, “The Accidental Profession,” Project Management Journal, 15, 3 (1984): 6. A. A. Einsiedel, “Profile of Effective Project Managers,” Project Management Journal, 18, 5 (1987): 51–56. J. Davidson Frame, Managing Projects in Organizations (San Francisco: Jossey-Bass, 1987). T. Gosselin, “What to Do with Last-Minute Jobs,” World Executive Digest, December 1993, p. 70. R. J. Graham, “A Survival Guide for the Accidental Project Manager,” Proceedings of the Annual Project Management Institute Symposium (Drexel Hill, PA: Project Management Institute, 1992), pp. 355–361. M. Horner, “Review of ‘Managing People for Project Success,’ ” International Journal of Project Management, 11 (1993): 125–126. P. R. Lawrence and J. W. Lorsch, “Differentiation and Integration in Complex Organizations,” Administrative Science Quarterly, 11 (1967):147. M. Nichols, “Does New Age Business Have a Message for Managers?” Harvard Business Review, March–April 1994, pp. 52–60. L. O’Connor, “Tunnelling Under the Channel,” Mechanical Engineering, December 1993, pp. 60–66. N. Pettersen, “What Do We Know about the Effective Project Manager?” International Journal of Project Management, 9 (1991): 99–104. J. K. Pinto and O. P. Kharbanda, Successful Project Managers: Leading Your Team to Success (New York: Van Nostrand Reinhold, 1995).

J. K. Pinto and D. P. Slevin, “Critical Factors in Successful Project Implementation,” IEEE Transactions on Engineering Management, EM-34, 1987, pp. 22–27. B. Z. Posner, “What It Takes to Be a Good Project Manager,” Project Management Journal, 18, 1 (1987): 51–54. W. A. Randolph and B. Z. Posner, “What Every Manager Needs to Know about Project Management,” Sloan Management Review, 29, 4 (1988): 65–73. P. Sweet, “A Planner’s Best Friend,” Accountancy, 113 (1994): 56–58. H. J. Thamhain, “Developing Project Management Skills,” Project Management Journal, 22, 3 (1991): 39–53. R. Turner, “Editorial,” International Journal of Project Management, 11 (1993): 195. Questions 1. What are the reasons the author advances for project management to be considered an “accidental profession?” The twelve guidelines are presented in no particular order. Order them by level of importance and explain your reasoning. 2. Where would you place yourself in Figure 2? 3. A few of the guidelines are related to the need to understand the reason for the project in the first place. Which guidelines would you place in this category? Why is this so crucial? 4. Why, in lesson 9, is always thinking about “what if” so important? 5. Lesson 12 warns about not planning enough, but also about spending too much time planning. How do you draw the line?

P

A

R

T

I PROJECT INITIATION

As noted earlier, the material in Part I of this text (highlighted in the figure) focuses on project initiation, which relates to the context of the project. Although this material may not appear germane to someone who wants to learn about how to actually run a project, having only the planning and execution tools and being ignorant of the context of the project is a recipe for disaster. It’s like knowing how to sail a ship but not

understanding your role as the captain and the purpose of the trip. Project initiation begins with the judicious selection of the organization’s projects to align them with the organization’s overall strategy. Chapter 2 describes how to evaluate and select projects that contribute to the organization’s strategy and discusses the information needed as well as the

Project Management

Ch 1: Projects in Contemporary Organizations

Project Initiation

Project Planning

Project Execution

Ch 2: Strategic Management and Project Selection

Ch 6: Project Activity and Risk Planning

Ch 10: Monitoring and Information Systems

Ch 3: The Project Manager

Ch 7: Budgeting: Estimating Costs and Risks

Ch 11: Project Control

Ch 4: Managing Conflict and the Art of Negotiation

Ch 8: Scheduling

Ch 12: Project Auditing

Ch 5: The Project in the Organizational Structure

Ch 9: Resource Allocation

Ch 13: Project Termination

39

40

PART I / PROJECT INITIATION

management of risk during this process. The chapter concludes with a description of an eight-step procedure called the “project portfolio process” that aligns project selection with the strategy. Chapter 3, “The Project Manager,” concerns the many roles of the project manager (PM), the multiple responsibilities, and some personal characteristics a project manager should possess. It also discusses the problems a PM faces when operating in a multicultural environment. Next, Chapter 4 covers a subject of critical importance to the PM that is almost universally ignored in

project management texts: the art of negotiating for resources. The chapter also describes some major sources of interpersonal conflict among members of the project team. Concluding Part I of the book, Chapter 5 discusses various ways to establish the project organization. Different organizational forms are described, as well as their respective advantages and disadvantages. The staffing of the project team is also discussed.

C

H

A

P

T

E

R

2 Strategic Management and Project Selection

More and more, the accomplishment of important tasks and goals in organizations today is being achieved through the use of projects. The phrases we hear and read about daily at our work and in conversations with our colleagues, such as “management by projects” and “project management maturity,” reflect this increasing trend in our society. The explosively rapid adoption of such a powerful tool as project management to help organizations achieve their goals and objectives is certainly awesome. In addition to project management’s great utility when correctly used, however, its utility has also led to many misapplications. As noted by one set of scholars (Cleland et al., 1983, p. 155), the rapid adoption of project management means:

• • •

there are many projects that fall outside the organization’s stated mission; there are many projects being conducted that are completely unrelated to the strategy and goals of the organization; and there are many projects with funding levels that are excessive relative to their expected benefits.

What was true 30 years ago, is still true today. In addition to the growth in the number of organizations adopting project management, there is also accelerating growth in the number of multiple, simultaneous, and often interrelated projects in organizations. Thus, the issue naturally arises as to how one manages all these projects. Are they all really projects? (It has been suggested that perhaps up to 80 percent of all “projects” are not actually projects at all, since they do not include the three project requirements for objectives, budget, and due date.) Should we be undertaking all of them? Of those we should implement, what should be their priorities? It is not unusual these days for organizations to be wrestling with hundreds of new projects. With so many ongoing projects it becomes difficult for smaller projects to get adequate support, or even the attention of senior management. Three particularly common problems in organizations trying to manage multiple projects are: 1. Delays in one project cause delays in other projects because of common resource needs or technological dependencies.

41

42

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

2. The inefficient use of corporate resources results in peaks and valleys of resource utilization. 3. Bottlenecks in resource availability or lack of required technological inputs result in project delays that depend on those scarce resources or technology. As might be expected, the report card on organizational success with management by projects is not stellar. For example, one research study (Thomas et al., 2001) has found that 30 percent of all projects are canceled midstream, and over half of completed projects came in up to 190 percent over budget and 220 percent late. This same study found that the primary motivation of organizations to improve and expand their project management processes was due to major troubled or failed projects, new upcoming mega-projects, or to meet competition or maintain their market share. Those firms that “bought” project management skills from consultants tended to see it as a “commodity.” These firms also commonly relied on outsourcing difficult activities, or even entire projects. Those who developed the skills internally, however, saw project management as offering a proprietary competitive advantage. The latter firms also moved toward recognizing project management as a viable career path in their organization, leading to senior management positions. A major development among those choosing to develop project management expertise in house, particularly those interested in using projects to accomplish organizational goals and strategies, is the initiation of a Project Management Office (PMO), described in detail in Chapter 5. This office strives to develop multi-project management expertise throughout the organization, to evaluate the interrelationships between projects (e.g., such as resource and skill requirements), and to ensure that projects are clearly related to the organization’s goals. It is expected that the PMO will promote those projects that capitalize on the organization’s strengths, offer a competitive advantage, and mutually support each other, while avoiding those with resource or technology needs in areas where the organization has no desire for development. The challenges thus facing the contemporary organization are how to make sure that projects are closely tied to the organization’s goals and strategy, how to handle the growing number of ongoing projects, and how to make these projects more successful, topics we discuss more fully in Section 2.7. The latter two of these objectives concern “project management maturity”—the development of project and multiproject management expertise. Following a discussion of project management maturity, we launch into a major aspect of multiproject management: selecting projects for implementation and then briefly discuss the uncertainty, or risk, involved. Given that the organization has an appropriate mission statement and strategy, projects must be selected that are consistent with the strategic goals of the organization. Project selection is the process of evaluating individual projects or groups of projects and then choosing to implement some set of them so that the objectives of the parent organization will be achieved. Because considerable uncertainty may surround one’s initial notions of precisely how most projects will be carried out, what resources will be required, and how long it will take to complete the project, we will introduce risk analysis into the selection process. Following this, we illustrate the process of selecting for implementation the set of projects that best meets the strategic goals of the organization, the Project Portfolio Process. Last, the chapter closes with a short discussion of project proposals. Before proceeding, a final comment is pertinent. It is not common to discuss project selection, the construction of a project portfolio, and similar matters in any detail in elementary texts on project management. The project manager typically has little or no say in the project funding decision, nor is he or she usually asked for input concerning the development of organizational strategy. Why then discuss these matters? The answer is simple, yet persuasive. The project manager who does not understand what a given project is expected to contribute to the parent organization lacks critical information needed to manage the project in order to optimize its contribution.

2.1

2.1

43

PROJECT MANAGEMENT MATURITY

PMBOK Guide 1.7

PROJECT MANAGEMENT MATURITY

As organizations have employed more and more projects for accomplishing their objectives (often referred to as “managing organizations by projects”), it has become natural for senior managers—as well as scholars—to wonder if the organization’s project managers have a mastery of the skills required to manage projects competently. For a great many organizations, the answer appears to be “NO!” The record of IT/software projects is particularly poor with less than 15 percent reaching “planned expectations” (KPMG, 2005; Cicmil et al., 2006; and elsewhere). A recent survey by PMI (2011) indicated that one of the key factors for improving the success rate of projects was the organization’s project management competency, now known as “maturity,” including the standardization of project management techniques which increased project success rates by over 25 percent. For more on this topic, see the Afterword in Section 13.5. Dinsmore (1998) describes one such “project management maturity” measure that scores firms on five successive levels of maturity. In the first level, “Initial,” there is no formal process for managing projects. The second level, “Repeatable,” has procedures in place for planning, scheduling, tracking, and estimating. The data are not integrated even if the firm has PM software available. The third level is “Defined.” On this level, the firm has integrated systems for tracking and managing projects, but are not routinely understood and used for controlling projects. At level four, “Managed,” systems are installed and used to manage and control projects. The project success rate is high. Level five, “Optimizing,” has integrated databases used to generate information on the senior-management level as well as for managers of single projects or portfolios of several projects. The database also contains historical information to allow continued improvement of the project management system. In the last few years, a number of different ways to measure “project management maturity” have been suggested (Pennypacker et al., 2003), such as basing the evaluation on PMI’s PMBOK Guide (Lubianiker, 2000), PMI’s Organizational Project Management Maturity Model (OPM3; see www.pmi.org/opm3/), or the ISO 9001 standards (contact the American Society for Quality). We will refer to project management maturity models again in Chapter 11 on Project Control and we will also urge that historical information on how to improve project management be maintained and utilized to allow continued improvement of project management systems.

Project Management in Practice Implementing Strategy through Projects at Blue Cross/Blue Shield Since strategic plans are usually developed at the executive level, implementation by middle level managers is often a problem due to poor understanding of the organization’s capabilities and top management’s expectations. However, bottom-up development of departmental goals and future plans invariably lacks the vision of the overall market and competitive environment. At Blue Cross/Blue Shield (BC/BS) of Louisiana, this problem was avoided by closely tying project management tools to the organizational

strategy. The resulting system provided a set of checks and balances for both BC/BS executives and project managers. Overseeing the system is a newly created Corporate Project Administration Group (CPAG) that helps senior management translate their strategic goals and objectives into project management performance, budget, and schedule targets. These may include new product development, upgrading information systems, or implementing facility automation systems.

44

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

CPAG also works with the project teams to develop their plans, monitoring activities and reports so they dovetail with the strategic intentions. The primary benefits of the system have been that it allows:

• •

senior management to select any corporate initiative and determine its status; PMs to report progress in a relevant, systematic, timely manner;

PMBOK Guide Table 3-1

2.2

• •

all officers, directors, and managers to view the corporate initiatives in terms of the overall strategic plan; and senior management to plan, track, and adjust strategy through use of financial project data captured by the system.

Source: P. Diab, “Strategic Planning Project Management Competitive Advantage,” PM Network, Vol. 12.

Quite a few consulting firms, as well as scholars, have devised formal maturity measures. One of these measures, PM3®, is described by R. Remy (1997). In this system, the final project management “maturity” of an organization is assessed as being at one of five levels: ad-hoc (disorganized, accidental successes and failures); abbreviated (some processes exist, inconsistent management, unpredictable results); organized (standardized processes, more predictable results); managed (controlled and measured processes, results in line with plans); and adaptive (continuous improvement in processes, success is normal, performance keeps improving). Another maturity model has been devised and applied to 38 organizations in four different industries (Ibbs et al., 2000). This model consists of 148 questions divided into six processes/life-cycle phases (initiating, planning, executing, controlling, closing, and organizational environment), and the nine PMBOK knowledge areas (integration, scope, time, cost, quality, human resources, communication, risk, and procurement). The model assesses an organization’s project management maturity in terms of five stages of maturity: ad-hoc, planned, managed, integrated, and sustained (the highest level). Regardless of model form, it appears that most organizations do not score very well in terms of maturity. On one form, about three-quarters are no higher than level 2 (planned) and fewer than 6 percent are above level 3 (managed). On another perspective, the average of the 38 organizations was only slightly over 3, though individual firms ranged between 1.8 and 4.6 on the five-point scale. Next we detail the project selection process, discussing the various types of selection models commonly used, some criteria for selection, and the role of risk in the process.

PROJECT SELECTION CRITERIA AND MODELS Project selection is the process of evaluating proposed projects or groups of projects, and then choosing to implement some set of them so that the objectives of the parent organization will be achieved. This same systematic process can be applied to any area of the organization’s business in which choices must be made between competing alternatives. For example, a manufacturing firm can use evaluation/selection techniques to choose which machine to adopt in a part-fabrication process; a TV station can select which of several syndicated comedy shows to rerun in its 7:30 p.m. weekday time-slot; a construction firm can select the best subset of a large group of potential projects on which to bid; or a hospital can find the best mix of psychiatric, orthopedic, obstetric, and other beds for a new wing. Each project will have different costs, benefits, and risks. Rarely are these known with certainty. In the face of such differences, the selection of one project out of a set is a difficult task. Choosing a number of different projects, a portfolio, is even more complex (discussed in Section 2.5).

2.2

PROJECT SELECTION CRITERIA AND MODELS

45

In the paragraph just above, all firms except the hypothetical construction firm are considering projects that are “inside” the organization; that is, they are for “clients” within the organization funding the projects. The construction firm is considering a set of potential projects to perform for clients outside of the construction firm itself. Whether for inside or outside clients, the projects will use the organization’s own resources, and both types of projects are usually dealt with as “competing” for the same pool of resources. Only rarely will a project manager be involved in the process by which projects are selected for inclusion in the set of projects the parent organization adopts for investment. It is, however, critically important to the success of the PM that he or she fully understands the parent organization’s objectives in undertaking a project that the PM is expected to lead. As we will see, most of the decisions that the PM is forced to make will have an impact on the degree to which the project contributes to those objectives the parent organization expected from the project. This is not the last time we will note the importance for the PM to understand why his or her project was selected for investment. In the following sections, we discuss several techniques that can be used to help senior managers select projects. Project selection is only one of many decisions associated with project management. To deal with all of these problems, we use models. We need such models because they abstract the relevant issues about a problem from the mass of detail in which the problem is embedded—reality is far too complex to deal with in its entirety. The model allows us to strip away almost all the reality from a problem, leaving only the relevant aspects of the “real” situation for us to deal with. This process of carving away the unwanted reality from the bones of a problem is called modeling the problem. The proper choice of investment projects is crucial to the long-run survival of every firm. Daily we witness the results of both good and bad investment choices. In our daily newspapers we read of Cisco System’s decision to purchase firms that have developed valuable communication network software rather than to develop its own software. We read of Procter and Gamble’s decision to invest heavily in marketing its products on the Internet and through social media; or problems faced by school systems when they update student computer labs— should they invest in Microsoft®-based systems or stick with their traditional choice, Apple®? But can such important choices be made rationally? Once made, do they ever change, and if so, how? These questions reflect the need for effective selection models. Within the limits of their capabilities, such models can be used to increase profits, select investments competing for limited capital resources, or improve the market position of an organization. They can be used for ongoing evaluation as well as initial selection, and thus are a key to the allocation and reallocation of the organization’s scarce resources. When a firm chooses a project selection model, the following criteria, based on Souder (1973), are most important. 1. Realism The model should reflect the reality of the firm’s decision situation, especially the multiple objectives of both the firm and its managers, bearing in mind that without a common measurement system, direct comparison of different projects is impossible. The model should also take into account the realities of the firm’s limitations on facilities, capital, personnel, and so forth, and include factors that reflect project technical and market risks: performance, cost, time, customer rejection, and implementation. 2. Capability The model should be sophisticated enough to deal with the relevant factors: multiple time periods, situations both internal and external to the project (e.g., strikes, interest rate changes), and so on. 3. Flexibility The model should give valid results within the range of conditions that the firm might experience. It should be easy to modify in response to changes in the firm’s

46

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

environment; for example, tax law changes, new technological advancements that alter risk levels, and, above all, organizational goal changes. 4. Ease of use The model should be reasonably convenient, not take a long time to execute, and be easy to use and understand. It should not require special interpretation, data that are difficult to acquire, excessive personnel, or unavailable equipment. 5. Cost Data-gathering and modeling costs should be low relative to the cost of the project and less than the potential benefits of the project. All costs should be considered, including the costs of data management and of running the model. We would add the following sixth criterion. 6. Easy computerization It should be easy and convenient to gather and store the information in a computer database, and to manipulate data in the model through use of a widely available, standard computer package such as Excel®. Since the development of computers and the establishment of operations research as an academic subject in the mid-1950s, the use of formal, numeric models to assist in decision making has expanded. Many of these models use financial metrics such as profits and/or cash flow to measure the “correctness” of a managerial decision. Project selection decisions are no exception, being based primarily on the degree to which the financial goals of the organization are met. As we will see later, this stress on financial goals, largely to the exclusion of other criteria, raises some serious problems for the firm, irrespective of whether the firm is for-profit or not-for-profit. There are two basic types of project selection models, numeric and nonnumeric. Both are widely used. Many organizations use both at the same time, or they use models that are combinations of the two. Nonnumeric models, as the name implies, do not use numbers as inputs. Numeric models do, but the criteria being measured may be either objective or subjective. It is important to remember that the qualities of a project may be represented by numbers, and that subjective measures are not necessarily less useful or reliable than objective measures. Before examining specific kinds of models within the two basic types, let us consider just what we wish the model to do for us, never forgetting two critically important, but often overlooked, facts.

• •

Models do not make decisions—people do. The manager, not the model, bears responsibility for the decision. The manager may “delegate” the task of making the decision to a model, but the responsibility cannot be abdicated. All models, however sophisticated, are only partial representations of the reality they are meant to reflect. Reality is far too complex for us to capture more than a small fraction of it in any model. Therefore, no model can yield an optimal decision except within its own, possibly inadequate, framework.

We seek a model to assist us in making project selection decisions. This model should possess the characteristics discussed previously and, above all, it should evaluate potential projects by the degree to which they will meet the firm’s objectives. To construct a selection/ evaluation model, therefore, it is necessary to develop a list of the firm’s objectives. This list of objectives should be generated by top management and might include maintenance of specific market shares, development of an improved image with specific clients or competitors, or expansion into a new line of business, just to mention a few. When the list of objectives has been developed, an additional refinement is recommended. The elements in the list should be weighted. Each item is added to the list because it represents a contribution to the success of the organization, but each item does not make an equal contribution. The weights reflect different degrees of contribution each element makes in accomplishing a set of goals.

2.3

TYPES OF PROJECT SELECTION MODELS

47

Once the list of weighted goals has been developed, one more task remains. The probable contribution of each project to each goal should be estimated. A project is selected or rejected because it is predicted to have certain outcomes, if implemented, which contribute to goal achievement. If the estimated level of goal achievement is sufficiently large, the project is selected. A paper by Åstebro (2004) reports on a study of more than 500 R & D projects. He found that four project characteristics were excellent predictors of a project’s commercial success: (1) expected profitability, (2) technological opportunity, (3) development risk, and (4) appropriability, the degree to which a project is appropriate for the organization undertaking it. This finding is particularly important because the experimental design was free of the hindsight bias that is so common in studies of project success and failure. The model correctly predicted almost 80 percent of the project failures and almost 75 percent of the project successes. A major consulting firm (Booz, Allen, and Hamilton, 1966) has argued that the primary cause for the failure of R & D projects is insufficient care in evaluating the proposal before the expenditure of funds. What is true for R & D projects also appears to be true for other kinds of projects, and it is clear that product development projects are more successful if they incorporate user needs and satisfaction in the design process (Matzler et al., 1998). Careful analysis of a potential project is mandatory for profitability in the construction business. There are many horror stories (Meredith, 1981) about firms that undertook projects for the installation of a computer information system without sufficient analysis of the time, cost, and disruption involved. Once again, we must emphasize that the tendency of many organizations to depend on profitability models to the exclusion of nonfinancial costs and benefits is a serious mistake. It is not uncommon for the “minor side-effects” of a new product or process to have major impacts on the parent organization. Often, projects intended to alter the organization’s infrastructure—extending engineering software to include new analytic methods or installing a day-care facility for preschool children of employees—can have significant positive effects on worker morale and productivity. On the other hand, replacing workers with new technology may make financial sense but could hurt morale and productivity so much that the change substantially reduces profitability.

2.3

TYPES OF PROJECT SELECTION MODELS Of the two basic types of selection models (numeric and nonnumeric), nonnumeric models are older and simpler and have only a few subtypes to consider. We examine them first.

Nonnumeric Models The Sacred Cow In this case the project is suggested by a senior and powerful official in the organization. Often the project is initiated with a simple comment such as, “If you have a chance, why don’t you look into…,” and there follows an undeveloped idea for a new product, for the development of a new market, for the design and adoption of a global data base and information system, or for some other project requiring an investment of the firm’s resources. The immediate result of this bland statement is the creation of a “project” to investigate whatever the boss has suggested. The project is “sacred” in the sense that it will be maintained until successfully concluded, or until the boss, personally, recognizes the idea as a failure and terminates it. The Operating Necessity If a flood is threatening the plant, a project to build a protective dike does not require much formal evaluation. XYZ Steel Corporation has used this criterion (and the following criterion also) in evaluating potential projects. If the project is required in order to keep the system operating, the primary question becomes: Is the system worth saving

48

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

at the estimated cost of the project? If the answer is yes, project costs will be examined to make sure they are kept as low as is consistent with project success, but the project will be funded. The Competitive Necessity Using this criterion, XYZ Steel undertook a major plant rebuilding project in the late 1960s in its steel-bar-manufacturing facilities near Chicago. It had become apparent to XYZ’s management that the company’s bar mill needed modernization if the firm was to maintain its competitive position in the Chicago market area. Although the planning process for the project was quite sophisticated, the decision to undertake the project was based on a desire to maintain the company’s competitive position in that market. In a similar manner, many business schools are restructuring their undergraduate and MBA programs to stay competitive with the more forward-looking schools. In large part, this action is driven by declining numbers of tuition-paying students and the need to develop stronger programs to attract them. Investment in an operating necessity project takes precedence over a competitive necessity project, but both types of projects may bypass the more careful numeric analysis used for projects deemed to be less urgent or less important to the survival of the firm. The Product Line Extension In this case, a project to develop and distribute new products would be judged on the degree to which it fits the firm’s existing product line, fills a gap, strengthens a weak link, or extends the line in a new, desirable direction. Sometimes careful calculations of profitability are not required. Decision makers can act on their beliefs about what will be the likely impact on the total system performance if the new product is added to the line. Comparative Benefit Model For this situation, assume that an organization has many projects to consider, perhaps several dozen. Senior management would like to select a subset of the projects that would most benefit the firm, but the projects do not seem to be easily comparable. For example, some projects concern potential new products, some require the conduct of a research and development project for a government agency, some concern changes in production methods, others concern computerization of certain records, and still others cover a variety of subjects not easily categorized (e.g., a proposal to create a daycare center for employees with small children). The organization has no formal method of selecting projects, but members of the Selection Committee think that some projects will benefit the firm more than others, even if they have no precise way to define or measure “benefit.” The concept of comparative benefits, if not a formal model, is widely adopted for selection decisions on all sorts of projects. Most United Way organizations use the concept to make decisions about which of several social programs to fund. Senior management of the funding organization then examines all projects with positive recommendations and attempts to construct a portfolio that best fits the organization’s aims and its budget. Of the several techniques for ordering projects, the Q-Sort (Helin et al., 1974) is one of the most straightforward. First, the projects are divided into three groups—good, fair, and poor— according to their relative merits. If any group has more than eight members, it is subdivided into two categories, such as fair-plus and fair-minus. When all categories have eight or fewer members, the projects within each category are ordered from best to worst. Again, the order is determined on the basis of relative merit. The rater may use specific criteria to rank each project, or may simply use general overall judgment. (See Figure 2-1 for an example of a Q-Sort.) The process described may be carried out by one person who is responsible for evaluation and selection, or it may be performed by a committee charged with the responsibility. If a committee handles the task, the individual rankings can be developed anonymously, and the set of anonymous rankings can be examined by the committee itself for consensus. It is common for such rankings to differ somewhat from rater to rater, but they do not often vary

2.3

TYPES OF PROJECT SELECTION MODELS

49

1.

2.

3.

4.

5.

Figure 2-1 The Q-sort method. Source: Souder 1983.

strikingly because the individuals chosen for such committees rarely differ widely on what they feel to be appropriate for the parent organization. Projects can then be selected in the order of preference, though they are usually evaluated financially before final selection. There are other, similar nonnumeric models for accepting or rejecting projects. Although it is easy to dismiss such models as unscientific, they should not be discounted casually. These models are clearly goal-oriented and directly reflect the primary concerns of the organization. The sacred cow model, in particular, has an added feature; sacred cow projects are visibly supported by “the powers that be.” Full support by top management is certainly an important contributor to project success (Meredith, 1981). Without such support, the probability of project success is sharply lowered. Sustainability The December 2009 issue of PM Network is devoted to “sustainability.” The discussion begins with the following (Gale, 2009): “Somewhere along the line, sustainability became interchangeable with that other buzzword; green. There’s just one small problem. It’s not really accurate. Sustainability does, of course, call for incorporating environmental concerns into project decision-making, but it also covers social issues—and the bottom line.” More and more organizations are building sustainability into the set of criteria that must be met for proposed projects to be selected for funding. Jewelry companies avoid the use of “blood diamonds,” and manufacturing firms avoid purchasing inputs from suppliers that use child labor. The sale of a pharmaceutical of questionable purity or serious side-effects is commonly far more costly in the long run than the cost of better quality control or the research needed for better drug design. In other words, sustainability focuses on long-run profitability rather than short-run payoff. To integrate sustainability into the organization’s decisionmaking requires the appointment of a senior manager with responsibility for the task. Metrics must be developed to measure the results of policy changes to increase sustainability, and this often requires developing the “soft” measures we will discuss later in this chapter.

50

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

Project Management in Practice Taipei 101: Refitted as World’s Tallest Sustainable Building

The owners of Taiwan’s Taipei 101 tower, the tallest building in East Asia, wanted to show the world that it is possible to make an existing building sustainable by winning a LEED (Leadership in Energy and Environmental Design) certification. When the building was constructed in 1998, advanced elements of sustainability were included, such as low-emissivity windows, energy-efficient HVAC systems, and smart controls on its double-deck elevators. The new $1.8 million effort will extend these green elements to include eco-friendly processes (cleaning, solid-waste management, purchasing), healthy office environments (air-quality testing, environmental inspections), energy consumption (optimizing operating and maintenance programs, automatic

turnoff of lighting in unoccupied restrooms), water usage (replacing toilet and urinal flush valves, reducing washbasin faucet flow rates), and tenant recycling, waste management, and office fit-outs. However, the engineering aspects of the tower refitting were the easy parts of the project. More difficult was getting all 85 organizations occupying the tower, comprising over 10,000 people, on board with the recycling (including purchase of recycled supplies) and other sustainability routines. The project manager notes that changing people’s attitudes is by far the greatest challenge for sustainability. Source: S. A. Swanson. “The Sky’s the Limit,” PM Network, Vol. 24.

2.3

TYPES OF PROJECT SELECTION MODELS

51

Numeric Models: Profit/Profitability

PMBOK Guide Chapter 7

As noted earlier, a large majority of all firms using project evaluation and selection models use profitability as the sole measure of acceptability. We will consider these models first, and then discuss more comprehensive models. Cost aspects of profitability are covered in area 4 of the PMBOK®. Payback Period The payback period for a project is the initial fixed investment in the project divided by the estimated annual net cash inflows from the project. The ratio of these quantities is the number of years required for the project to repay its initial fixed investment. For example, assume a project costs $100,000 to implement and has annual net cash inflows of $25,000. Then Payback period

$100,000/$25,000

4 years

This method assumes that the cash inflows will persist at least long enough to pay back the investment, and it ignores any cash inflows beyond the payback period. The method also serves as an (inadequate) proxy for risk. The faster the investment is recovered, the less the risk (discussed further in Section 2.4) to which the firm is exposed. Discounted Cash Flow Also referred to as the net present value (NPV) method, the discounted cash flow method determines the net present value of all cash flows by discounting them by the required rate of return (also known as the hurdle rate, cutoff rate, and similar terms) as follows: n

NPV (project)

A0

∑ (1 t 1

Ft k )t

where Ft the net cash flow in period t, k the required rate of return, and A0 initial cash investment (because this is an outflow, it will be negative). To include the impact of inflation (or deflation) where pt is the predicted rate of inflation during period t, we have n

NPV (project)

A0

∑ (1 t 1

Ft k pt )t

Early in the life of a project, net cash flow is likely to be negative, the major outflow being the initial investment in the project, A0. If the project is successful, however, cash flows will become positive. The project is acceptable if the sum of the net present values of all estimated cash flows over the life of the project is positive. A simple example will suffice. Using our $100,000 investment with a net cash inflow of $25,000 per year for a period of eight years, a required rate of return of 15 percent, and an inflation rate of 3 percent per year, we have 8

NPV (project)

$100, 000

∑ (1 t 1

$25, 000 0.15 0.03)t

$1939 Because the present value of the inflows is greater than the present value of the outflow— that is, the net present value is positive—the project is deemed acceptable.

52

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

PsychoCeramic Sciences, Inc. PsychoCeramic Sciences, Inc. (PSI), a large producer of cracked pots and other cracked items, is considering the installation of a new marketing software package that will, it is hoped, allow more accurate sales information concerning the inventory, sales, and deliveries of its pots as well as its vases designed to hold artificial flowers. The information systems (IS) department has submitted a project proposal that estimates the investment requirements as follows: an initial investment of $125,000 to be paid up-front to the Pottery Software Corporation; an additional investment of $100,000 to modify and install the software; and another $90,000 to integrate the new software into the overall information system. Delivery and installation is estimated to take one year; integrating the entire system should require an additional year. Thereafter, the IS department predicts that scheduled software updates will require further expenditures of about $15,000 every second year, beginning in the fourth year. They will not, however, update the software in the last year of its expected useful life. The project schedule calls for benefits to begin in the third year, and to be up-to-speed by the end of that year. Projected additional profits resulting from better and more timely sales information are estimated to be $50,000 in the first year of operation and are expected to peak at $120,000 in the second year of operation, and then to follow the gradually declining pattern shown in the table at the end of this box.

Project life is expected to be 10 years from project inception, at which time the proposed system will be obsolete for this division and will have to be replaced. It is estimated, however, that the software can be sold to a smaller division of PSI and will thus have a salvage value of $35,000. PSI has a 12 percent hurdle rate for capital investments and expects the rate of inflation to be about 3 percent over the life of the project. Assuming that the initial expenditure occurs at the beginning of the year and that all other receipts and expenditures occur as lump sums at the end of the year, we can prepare the Net Present Value analysis for the project as shown in the table below. The Net Present Value of the project is positive and, thus, the project can be accepted. (The project would have been rejected if the hurdle rate were 14 percent.) Just for the intellectual exercise, note that the total inflow for the project is $759,000, or $75,900 per year on average for the 10 year project. The required investment is $315,000 (ignoring the biennial overhaul charges). Assuming 10 year, straight line depreciation, or $31,500 per year, the payback period would be:

PB

$315, 000 $75, 900 31, 500

2.9

A project with this payback period would probably be considered quite desirable.

2.3

TYPES OF PROJECT SELECTION MODELS

53

Internal Rate of Return If we have a set of expected cash inflows and cash outflows, the internal rate of return is the discount rate that equates the present values of the two sets of flows. If At is an expected cash outflow in the period t and Rt is the expected inflow for the period t, the internal rate of return is the value of k that satisfies the following equation (note that the A0 will be positive in this formulation of the problem): A0

A1 / (1

k)

A2 / (1

k )2

...

An / (1

k )n

R1 / (1 k ) R2 / (1 . . . Rn / (1 k )n

k )2

The value of k is found by trial and error. Profitability Index Also known as the benefit–cost ratio, the profitability index is the net present value of all future expected cash flows divided by the initial cash investment. (Some firms do not discount the cash flows in making this calculation.) If this ratio is greater than 1.0, the project may be accepted. Other Profitability Models There are a great many variations of the models just described. These variations fall into three general categories: (1) those that subdivide net cash flow into the elements that comprise the net flow; (2) those that include specific terms to introduce risk (or uncertainty, which is treated as risk) into the evaluation; and (3) those that extend the analysis to consider effects that the project might have on other projects or activities in the organization. Several comments are in order about all the profit-profitability numeric models. First, let us consider their advantages: 1. 2. 3. 4.

The undiscounted models are simple to use and understand. All use readily available accounting data to determine the cash flows. Model output is in terms familiar to business decision makers. With a few exceptions, model output is on an “absolute” profit/profitability scale and allows “absolute” go/no-go decisions. 5. Some profit models can be amended to account for project risk. The disadvantages of these models are the following: 1. These models ignore all nonmonetary factors except risk. 2. Models that do not include discounting ignore the timing of the cash flows and the time–value of money. 3. Models that reduce cash flows to their present value are strongly biased toward the short run. 4. Payback-type models ignore cash flows beyond the payback period. 5. The internal rate of return model can result in multiple solutions. 6. All are sensitive to errors in the input data for the early years of the project. 7. All discounting models are nonlinear, and the effects of changes (or errors) in the variables or parameters are generally not obvious to most decision makers. 8. All these models depend for input on a determination of cash flows, but it is not clear exactly how the concept of cash flow is properly defined for the purpose of evaluating projects. A complete discussion of profit/profitability models can be found in any standard work on financial management—see Ross et al. (2008), for example. In general, the net present value models are preferred to the internal rate of return models. Despite wide use, financial models rarely include nonfinancial outcomes in their benefits and costs. In a discussion of the financial value of adopting project management (that is, selecting as a project the use

54

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

of project management) in a firm, Githens (1998) notes that traditional financial models “simply cannot capture the complexity and value-added of today’s process-oriented firm.” The commonly seen phrase “return on investment,” or ROI, does not denote any specific method of calculation. It usually involves NPV or internal rate of return (IRR) calculations, but we have seen it used in reference to undiscounted rate of return models and (incorrectly) payback period models. In our experience, the payback period model, occasionally using discounted cash flows, is one of the most commonly used models for evaluating projects and other investment opportunities. Managers generally feel that insistence on short payout periods tends to minimize the risks associated with outstanding monies over the passage of time. While this is certainly logical, we prefer evaluation methods that discount cash flows and deal with uncertainty more directly by considering specific risks. Using the payback period as a cash-budgeting tool aside, its primary virtue is its simplicity.

Numeric Models: Real Options The real options project selection model was developed based on a notion well known in financial markets. When a firm invests in something, such as conducting a joint venture with another firm, it foregoes the value of alternative future investments. Economists refer to the value of an opportunity foregone as the “opportunity cost” of the investment made. But making such an investment often gives the firm the option to do something in the future that it could not have done without making the investment, like buying out the other firm’s share of the business if the venture is profitable, or selling out to the other firm. The concept of a real option is that the investment leads to opportunities that would not have been available otherwise. It is not unknown for firms and other organizations to invest in an alternative that, in and of itself is not profitable or beneficial, but opens options for the future that may have great promise, such as:

• • • • •

Learning about a new technology Gaining access to potential new customers Obtaining the right to bid on a lucrative follow-on contract Improving the firm’s competitive strength Being able to offer profitable maintenance, repair, or service on new equipment

During the computerization boom of the 1980s and 1990s, many firms ignored the value of real options in investing in advanced technology. Their project selection evaluation process compared the costs, risks, and supposed benefits of these technologies against the value of waiting a bit longer for less risky (or more advanced) technology at a possibly reduced price (from higher volumes). This seemed to make sense—they could use the money now for other investments and avoid the risk of investing in new technologies that might not pay off. But within months their knowledge of advanced technologies was obsolete, while their sales and profits had collapsed because all their competitors had invested in the technology. They made two errors in their thinking: (1) that they could stay on the leading knowledge edge of technology without gaining experience using these technologies, and (2) that the market environment would continue as it had. It is always imperative to consider the real options of an investment and never assume that things will continue as they have in the past if you don’t make the investment. The real options approach acts to reduce both technological and commercial risk. For a full explanation of the method and its use as a strategic selection tool, see Luehrman (1998a and 1998b). An interesting application of real options as a project selection tool for pharmaceutical R & D projects is described by Jacob et al. (2003). Real options combined with Monte Carlo simulation is compared with alternative selection/assessment methods by Doctor et al. (2001).

2.3

TYPES OF PROJECT SELECTION MODELS

55

Project Management in Practice Project Selection for Spent Nuclear Fuel Cleanup

Fuel slug packaging system developed to transport and store fuel capsules.

To help the Department of Energy’s Hanford Nuclear Fuel Site with facility shutdown, decommissioning, and site cleanup, Westinghouse Hanford Co. reorganized for “projectization.” The major project in this overall task was the site cleanup of 2,100 metric tons of degraded spent nuclear fuel slugs submerged beneath 16 feet of water (as a radiation shield) in two rectangular, 25-footdeep, half-football field–sized basins. Of the over 105,000 slugs, about 6,000 were severely damaged or corroded and leaking radiation into the basin water. The 40-year old basins, located only 400 yards from Washington State’s pristine Columbia River, had an original 20-year design life and were in very poor condition, experiencing major leaks as early as the late 1970s. Operating and attempting to maintain these “accidents waiting to happen” cost $100,000 a day. To address this problem, Westinghouse Hanford went to the site’s stakeholders—the media, activists, regulators, oversight groups, three Indian tribes, government leaders, Congress, and Hanford employees—to determine acceptable options for dealing with this immense problem. It required five months of public discussion for the stakeholders to understand

the issues and regain their trust in Hanford. Another two months were required to develop four project options as follows: 1. Better encapsulate the fuel and leave it in the basins. 2. Place the fuel in wet storage elsewhere at Hanford. 3. Place the fuel in dry storage at Hanford. 4. Ship the fuel overseas for reprocessing. Following three months of evaluation, the third option was selected and an environmental impact statement (EIS) begun, which required eleven more months to complete (yet half the normal EIS completion time). The project was completed three years ahead of the original schedule, thereby saving taxpayers $350 million. Also, the cost of maintaining the fuel is expected to drop to only $3,000 per day. Source: J. C. Fulton, “Complex Problem . . . Simple Concepts . . . Transformed Organization,” PM Network, Vol. 10.

56

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

Numeric Models: Scoring In an attempt to overcome some of the disadvantages of profitability models, particularly their focus on a single decision criterion, a number of evaluation/selection models that use multiple criteria to evaluate a project have been developed. Such models vary widely in their complexity and information requirements. The examples discussed illustrate some of the different types of numeric scoring models. Unweighted 0–1 Factor Model A set of relevant factors is selected by management and then usually listed in a preprinted form. One or more raters score the project on each factor, depending on whether or not it qualifies for an individual criterion. The raters are chosen by senior managers, for the most part from the rolls of senior management. The criteria for choice are (1) a clear understanding of organizational goals and (2) a good knowledge of the firm’s potential project portfolio. Figure 2-2 shows an example of the rating sheet for an unweighted, 0–1 factor model. The columns of Figure 2-2 are summed and those projects with a sufficient number of qualifying factors may be selected. The main advantage of such a model is that it uses several criteria in the decision process. The major disadvantages are that it assumes all criteria are of equal importance and it allows for no gradation of the degree to which a specific project meets the various criteria. Unweighted Factor Scoring Model The second disadvantage of the 0–1 factor model can be dealt with by constructing a simple linear measure of the degree to which the project being evaluated meets each of the criteria contained in the list. The x marks in Figure 2-2

Project _________________________________________________________________________ Rater ____________________________________ Date _________________________________

No increase in energy requirements Potential market size, dollars Potential market share, percent No new facility required No new technical expertise required No decrease in quality of final product Ability to manage project with current personnel No requirement for reorganization Impact on work force safety Impact on environmental standards Profitability Rate of return more than 15% after tax Estimated annual profits more than $250,000 Time to break-even less than 3 years Need for external consultants Consistency with current line of business Inpact on company image With customers With our industry Totals Figure 2-2

Qualifies x x x x

x x x x x x x x x x x x x 12

Sample project evaluation form.

Does Not Qualify

5

2.3

TYPES OF PROJECT SELECTION MODELS

57

would be replaced by numbers. Often a five-point scale is used, where 5 is very good, 4 is good, 3 is fair, 2 is poor, 1 is very poor. (Three-, seven-, and 10-point scales are also common.) The second column of Figure 2-2 would not be needed. The column of scores is summed, and those projects with a total score exceeding some critical value are selected. A variant of this selection process might choose the highest-scoring projects (still assuming they are all above some critical score) until the estimated costs of the set of projects equaled the resource limit. However, the criticism that the criteria are all assumed to be of equal importance still holds. The use of a discrete numeric scale to represent the degree to which a criterion is satisfied is widely accepted. To construct such measures for project evaluation, we proceed in the following manner. Select a criterion, say, “estimated annual profits in dollars.” For this criterion, determine five ranges of performance so that a typical project, chosen at random, would have a roughly equal chance of being in any one of the five performance ranges. (Another way of describing this condition is: Take a large number of projects that were selected for support in the past, regardless of whether they were actually successful or not, and create five levels of predicted performance so that about one-fifth of the projects fall into each level.) This procedure will usually create unequal ranges, which may offend our sense of symmetry but need not concern us otherwise. It ensures that each criterion performance measure utilizes the full scale of possible values, a desirable characteristic for performance measures. Consider the following two simple examples. Using the criterion just mentioned, “estimated annual profits in dollars,” we might construct the following scale:

As suggested, these ranges might have been chosen so that about 20 percent of the projects considered for funding would fall into each of the five ranges. The criterion “no decrease in quality of the final product” would have to be restated to be scored on a five-point scale, perhaps as follows:

This scale is an example of scoring cells that represent opinion rather than objective (even if “estimated”) fact, as was the case in the profit scale. Weighted Factor Scoring Model When numeric weights reflecting the relative importance of each individual factor are added, we have a weighted factor scoring model. In general, it takes the form

58

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION n

∑s w

Si

ij

j

j 1

where Si the total score of the ith project, sij the score of the ith project on the jth criterion, and wj the weight of the jth criterion. The weights, wj, may be generated by any technique that is acceptable to the organization’s policy makers. There are several techniques available to generate such numbers, but the most effective and most widely used is the Delphi technique. The Delphi technique was developed by Brown and Dalkey of the Rand Corporation during the 1950s and 1960s (Dalkey, 1969). It is a technique for developing numeric values that are equivalent to subjective, verbal measures of relative value. Another popular and quite similar approach is the Analytic Hierarchy Process, developed by Saaty (1990). For an extensive example involving finance, sales, and purchasing, see pages 306–316 of Turban et al. (1994). This example also illustrates the use of Expert Choice®, a software package to facilitate the application of the Analytic Hierarchy Process. Meade et al. (2002) developed a more general form of Saaty’s AHP. They call it the Analytic Network Process, and their paper includes an example of its application to evaluation of multiple R & D projects. (Which reminds us, once more, to caution those who include “technological risk” when evaluating projects. The probability of technical success for any project is 1.0 if there is no limit on time and/or budget. Any estimate of technical success should be accompanied by time and cost constraints, or it is meaningless.) Finally, the use of experts to develop weightings is nicely demonstrated by Jolly (2003) who applies the technique to the development of weights to a technology portfolio. When numeric weights have been generated, it is helpful (but not necessary) to scale the weights so that 0 ≤ wj ≤ 1

j

1, 2, 3, . . . , n

n

∑w

j

1

j 1

The weight of each criterion can be interpreted as the “percent of the total weight accorded to that particular criterion.” A special caveat is in order. It is quite possible with this type of model to include a large number of criteria. It is not particularly difficult to develop scoring scales and weights, and the ease of gathering and processing the required information makes it tempting to include marginally relevant criteria along with the obviously important items. Resist this temptation! After the important factors have been weighted, there usually is little residual weight to be distributed among the remaining elements. The result is that the evaluation is simply insensitive to major differences in the scores on trivial criteria. A good rule of thumb is to discard elements with weights less than 0.02 or 0.03. (If elements are discarded, and if you wish 兺wj 1, the weights must be rescaled to 1.0.) As with any linear model, the user should be aware that the elements in the model are assumed to be independent. This presents no particular problems for these scoring models because they are used to make estimates in a “steady-state” system, and we are not concerned with transitions between states.

2.3

TYPES OF PROJECT SELECTION MODELS

59

Gettin’ Wheels Rather than using an example in which actual projects are selected for funding with a weighted factor scoring model (hereafter “scoring model”) that would require tediously long descriptions of the projects, we can demonstrate the use of the model in a simple, common problem that many readers will have faced—the choice of an automobile for purchase. This problem is nicely suited to use of the scoring model because the purchaser is trying to satisfy multiple objectives in making the purchase and is typically faced with several different cars from which to choose. Our model must have the following elements: 1. A set of criteria on which to judge the value of any alternative; 2. A numeric estimate of the relative importance (i.e., the “weight”) of each criterion in the set; and 3. Scales by which to measure or score the performance or contribution–to–value of each alternative on each criterion. The criteria weights and measures of performance must be numeric in form, but this does not mean that they must be either “objective” or “quantitative.” Criteria weights, obviously, are subjective by their nature, being an expression of what the decision maker thinks is important. The development of performance scales is more easily dealt with in the context of our example, and we will develop them shortly. Assume that we have chosen the criteria and weights shown in Table A to be used in our evaluations.* The weights represent the relative importance of the criteria measured on a 10-point scale. The numbers in parentheses show the proportion of the total weight carried by each criterion. (They add to only .99 due to rounding.) Raw weights work just as well for decision making as their percentage counterparts, but the latter are usually preferred because they are a constant reminder to the decision maker of the impact of each of the criteria. Prior to consideration of performance standards and sources of information for the criteria we have chosen, *The criteria and weights were picked arbitrarily for this example. Because this is typically an individual or family decision, techniques like Delphi or the analytic hierarchy process are not required.

Table A A Criteria and Weights for Automobile and Weights Purchase Purchase Appearance Braking Comfort Cost, operating Cost, original Handling Reliability Total

4 3 7 5 10 7

(.10) (.07) (.17) (-12) (.24) (.17)

5

(.12)

41

.99

Table B Automobile Automobile Selection Selection Criteria, Criteria, Measures and and Data Sources Sources Appearance Braking

Subjective judgment, personal Distance in feet, 6(M) mph, automotive magazine"

Comfort

Subjective judgment, 30 min. road test

Cost, operating Cost, original Handling

Annual insurance cost plus fuel cost'' Dealer cost, auto-cosi service' Average speed through standard slalom, automotive magazine" Score on Consumer Reports, "Frequencyof-Repair" data (average of 2 previous years)

Reliability

"Many automotive periodicals conduct standardized performance tests of new cars, *Annual fuel cost is calculated as ( 17,500 mi/DOE ave. mpg) $4.259/gal. 1 There are several sources for dealer-cost data (e.g., AAA, which provides a stable database on which to estimate the price of each alternative).

we must ask, “Are there any characteristics that must be present (or absent) in a candidate automobile for it to be acceptable?” Assume, for this example, that to be acceptable, an alternative must not be painted green, must have air conditioning, must be able to carry at least four adults, must have at least 10 cubic feet of luggage space, and must be priced less than $34,000. If an alternative violates any of these conditions, it is immediately rejected. For each criterion, we need some way of measuring the estimated performance of each alternative. In this case, we might adopt the measures shown in Table B.

60

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

Appearance Braking Comfort Cost, operating* Cost, original* Handling Reliability

Ugh 165 Bad $2.5 $32.5 45 Worst

Poor 165–150 Poor $2.1–2.5 $26–32.5 45–49.5 Poor

Adequate 150–140 Adequate $1.9–2.1 $21–26 49.5–55 Adequate

Good 140–130 Good $1.6–1.9 $17–21 55–59 Good

WOW 130 Excellent $1.6 $17 59 Excellent

*Cost data in $1000s

Figure A Performance measures and equivalent scores for selection of an automobile.

than the Sporticar 100, it rates only about 0.13 points or 4 percent above the NuevoEcon. Note that if we overrated the Ritzy by one point on comfort or handling, or if we underrated the NuevoEcon by one point on either of these criteria, the result would have been reversed. (We assume that the original cost data are accurate.) With the scores this close, we might want to evaluate these two cars by additional criteria (e.g., ease of carrying children, status, safety features like dual airbags or ABS) prior to making a firm decision. All in all, if the decision maker has well-delineated objectives, and can determine how specific kinds of performance contribute to those criteria, and finally, can measure those kinds of performance for each of the alternative courses of action, then the scoring model is a powerful and flexible tool. To the extent that criteria are not carefully defined, performance is not well linked to the criteria, and is carelessly or wrongly measured, the scoring model rests on a faulty foundation and is merely a convenient path to error.

Our purpose is to transform a measure of the degree to which an alternative meets a criterion into a score, the sij, that is a general measure of the utility or value of the alternative with respect to that criterion. Note that this requires us to define the criterion precisely, as well as to specify a source for the information. Figure A shows the scores for each criterion transformed to a 5-point scale, which will suffice for our ratings. Using the performance scores shown in Figure A, we can evaluate the cars we have identified as our alternatives: the Leviathan 8, the NuevoEcon, the Maxivan, the Sporticar 100, and the Ritzy 300. Each car is scored on each criterion according to the categories shown in Figure A. Then each score is multiplied by the criterion weight and the result is entered into the appropriate box in Figure B. Last, the results for each alternative are summed to represent the weighted score. According to this set of measures, we prefer the Ritzy 300, but while it is a clear winner over the Leviathan 8 and the Maxivan, and scores about 8 percent better

Leviathan 8 NuevoEcon Maxivan Sporticar 100 Ritzy 300

3 0.10 0.30 3 0.10 0.30 2 0.10 0.20 5 0.10 0.50 4 0.10 0.40

1 0.07 0.07 3 0.07 0.21 1 0.07 0.07 4 0.07 0.28 5 0.07 0.35

4 0.17 0.68 2 0.17 0.34 4 0.17 0.68 3 0.17 0.51 5 0.17 0.85

2 0.12 0.24 5 0.12 0.60 4 0.12 0.48 2 0.12 0.24 2 0.12 0.24

Figure B Scores for alternative cars on selection criteria.

1 0.24 0.24 4 0.24 0.96 3 0.24 0.72 2 0.24 0.48 1 0.24 0.24

2 0.17 0.34 2 0.17 0.34 1 0.17 0.17 5 0.17 0.85 4 0.17 0.68

3 0.12 0.36 4 0.12 0.48 3 0.12 0.36 2 0.12 0.24 5 0.12 0.60

2.23 3.23 2.68 3.10 3.36

2.3

TYPES OF PROJECT SELECTION MODELS

61

It is useful to note that if one uses a weighted scoring model to aid in project selection, the model can also serve as an aid to project improvement. For any given criterion, the difference between the criterion’s score and the highest possible score on that criterion, multiplied by the weight of the criterion, is a measure of the potential improvement in the project score that would result were the project’s performance on that criterion sufficiently improved. It may be that such improvement is not feasible or is more costly than the improvement warrants. On the other hand, such an analysis of each project yields a valuable statement of the comparative benefits of project improvements. Viewing a project in this way is a type of sensitivity analysis. We examine the degree to which a project’s score is sensitive to attempts to improve it—usually by adding resources. We will use sensitivity analysis several times in this book. It is a powerful managerial technique. It is not particularly difficult to computerize a weighted scoring model by creating a template on Excel® or one of the other standard computer spreadsheets. In Chapter 13 we discuss an example of a computerized scoring model used for the project termination decision. The model is, in fact, a project selection model. The logic of using a “selection” model for the termination decision is straightforward: Given the time and resources required to take a project from its current state to completion, should we make the investment? A “Yes” answer to that question “selects” for funding the partially completed project from the set of all partially finished and not-yet-started projects. As was the case with profitability models, scoring models have their own characteristic advantages and disadvantages. The advantages are: 1. These models allow multiple criteria to be used for evaluation and decision making, including profit/profitability models and both tangible and intangible criteria. 2. They are structurally simple and therefore easy to understand and use. 3. They are a direct reflection of managerial policy. 4. They are easily altered to accommodate changes in the environment or managerial policy. 5. Weighted scoring models allow for the fact that some criteria are more important than others. 6. These models allow easy sensitivity analysis. The trade-offs between the several criteria are readily observable. The disadvantages are the following: 1. The output of a scoring model is strictly a relative measure. Project scores do not represent the value or “utility” associated with a project and thus do not directly indicate whether or not the project should be supported. 2. In general, scoring models are linear in form and the elements of such models are assumed to be independent. 3. The ease of use of these models is conducive to the inclusion of a large number of criteria, most of which have such small weights that they have little impact on the total project score. 4. Unweighted scoring models assume all criteria are of equal importance, which is almost certainly contrary to fact. 5. To the extent that profit/profitability is included as an element in the scoring model, this element has the advantages and disadvantages noted earlier for the profitability models themselves.

Numeric Models: Window-of-Opportunity Analysis In the early stages of new product development, one may know little more than the fact that the potential product seems technically feasible. Just because one can develop and/or install

62

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

a new technology does not necessarily imply that the new technology is worth implementing, or will be economically profitable. Fundamentally, the decision to invest in the development of a new process or product depends on an estimate of cash flows and other benefits expected to result if the innovation is successful—a difficult problem at best. The traditional approach has been to implement the technology in question (or a pilot version of it) and then test it to see if it qualifies as useful and economic. This is often a wasteful process because it assumes the innovation will be successful—a condition only occasionally met in practice. Given some idea for a new product or process, we can invert this traditional approach by attempting to determine the cost, timing, and performance specifications that must be met by this new technology before any R & D is undertaken. (This is called the windowof-opportunity for the innovation.) The method for conducting such an analysis is as follows. Given a potential production process innovation, for example, the current production process is analyzed in detail and any element of that process that might be affected by the innovation is noted. Baseline data on the current process are collected (e.g., its cycle time, its cost) and the effect of the innovation is estimated relative to (usually some fraction or multiple of) the baseline system. Having thus estimated the economic impact of the innovation, the decision of whether or not to undertake the development project is much simpler. For an example of such an approach see Evans et al. (1985) and Mantel et al. (1985).

Numeric Models: Discovery-Driven Planning Like the window-of-opportunity analysis, discovery-driven planning (McGrath et al., 1995; Rice et al., 2008) also reverses the expensive and risky traditional approach of trying out the technology to determine its benefits. This approach funds enough of the project to determine if the initial assumptions concerning costs, benefits, etc. were accurate. When the funds are gone, the assumptions are reevaluated to determine what to do next. The idea isn’t to implement the project but rather to learn about the project. The assumptions about the project are written down and analyzed carefully to determine two aspects about them: (1) which are the critical assumptions that will make or break the desirability of the project, and (2) how much will it cost to test each of the assumptions. The high-priority, dealkiller assumptions that will cost the least then are ranked at the top, with the lesser and more expensive assumptions following. If a critical assumption proves to be invalid, management must rethink its strategy and the project. This process is not just a one-time exercise, however; the process continues as the stages of the project are executed so that at any point in the project, management can step in and terminate it if conditions change and the project looks less promising. And conditions are always changing: the economy gets worse, the market moves toward or away from the promise of the project, a key team member of the project leaves the company, the strategy of the organization changes with a new executive, a new government regulation impacts the project, and so on. Project failure is more often management’s failure to consider an important problem or question than it is a technical failure within the project.

Choosing a Project Selection Model Selecting the type of model to aid the evaluation/selection process depends on the philosophy and wishes of management. Liberatore et al. (1983) conducted a survey of 40 high-level staff persons from 29 Fortune 500 firms. Eighty percent of their respondents report the use of one or more financial models for R & D project decision making. Although their sample is small and nonrandom, their findings are quite consistent with the present authors’ experience. Swanson (2011) reports on an airline that previously considered only ROI in prioritizing projects but now also considers strategic contributions, resource limitations, and non-numeric factors such as regulatory mandates and operating necessities. Other organizations are considering the real options their projects offer.

2.3

TYPES OF PROJECT SELECTION MODELS

63

We strongly favor weighted scoring models for three fundamental reasons. First, they allow the multiple objectives of all organizations to be reflected in the important decision about which projects will be supported and which will be rejected. Second, scoring models are easily adapted to changes in managerial philosophy or changes in the environment. Third, they do not suffer from the bias toward the short run that is inherent in profitability models that discount future cash flows. This is not a prejudice against discounting and most certainly does not argue against the inclusion of profits/profitability as an important factor in selection, but rather it is an argument against the exclusion of nonfinancial factors that may require a longer-run view of the costs and benefits of a project. For a powerful statement of this point, see Hayes et al. (1980). It is also interesting to note that Liberatore et al. (1983, p. 969) found that firms with a significant amount of contract research funded from outside the organization used scoring models for project screening much more frequently than firms with negligible levels of outside funding. It was also found that firms with significant levels of outside funding were much less likely to use a payback period model, presumably to reduce their risk. The structure of a weighted scoring model is quite straightforward. Its virtues are many. Nonetheless, the actual use of scoring models is not as easy as it might seem. Decision makers are forced to make difficult choices and they are not always comfortable doing so. They are forced to reduce often vague feelings to quite specific words or numbers. Multiattribute, multiperson decision making is not simple. [For an interesting discussion of this process, see Irving et al. (1988).] The use of any project selection model assumes that the decision-making procedure takes place in a reasonably rational organizational environment. Such is not always the case. In some organizations, project selection seems to be the result of a political process, and sometimes involves questionable ethics, complete with winners and losers (Baker et al., 1995). In others, the organization is so rigid in its approach to decision making that it attempts to reduce all decisions to an algorithmic proceeding in which predetermined programs make choices so that humans have minimal involvement—and responsibility. Here too, Saaty’s (1990) Analytic Hierarchy Process can lend rationality to a sometimes irrational process. Whether managers are familiar with accounting systems or not, it is useful to reflect on the methods and assumptions used in the preparation of accounting data. Among the most crucial are the following: 1. Accountants live in a linear world. With few exceptions, cost and revenue data are assumed to vary linearly with associated changes in inputs and outputs. 2. The accounting system often provides cost-revenue information that is derived from standard cost analyses and equally standardized assumptions regarding revenues. These standards may or may not accurately represent the cost-revenue structure of the physical system they purport to represent. 3. The data furnished by the accounting system may or may not include overhead costs. In most cases, the decision maker is concerned solely with cost-revenue elements that will be changed as a result of the project under consideration. Incremental analysis is called for, and great care should be exercised when using pro forma data in decision problems. Remember that the assignment of overhead cost is always arbitrary. The accounting system is the richest source of information in the organization, and it should be used—but with great care and understanding. 4. Warning! A great many organizations utilize project cost data as the primary, and the only routine measure of project performance. In Chapter 1 we emphasized that projects should be measured on three dimensions, time, cost, and scope. Without including information on the schedule and the physical completion of work, cost measurements have no useful meaning. We will repeat this warning throughout this book.

64

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

Finally, no matter what method is used for project selection, as time goes by the selection model’s inputs must be constantly updated. The world does not stand still—things change! What was a promising project yesterday may be a loser today—and yesterday’s loser may be today’s winner.

2.4

RISK CONSIDERATIONS IN PROJECT SELECTION

PMBOK Guide Chapter 11

In our previous discussion of factors to consider when selecting projects, we emphasized costs and benefits, with only a side reference to the inherent uncertainty associated with both of these, though benefits are usually more uncertain than costs. However, both are uncertain, and can be greater or less than expected. In the case of being worse than expected, the organization is exposed to some, perhaps substantial, level of risk. There are many more ways of dealing with project risk besides using a shorter payback period. Although our major discussion of techniques to handle risk will come in Chapters 6 and 7 when we discuss project activity and budget planning, the topic is highly relevant to project selection as well, and we will briefly comment on it here. PMI (2011) reports that risk management is used significantly more by high-performing project organizations than low-performing organizations. During the past several years, increasing attention has been paid to the subject of managing some of the risks inherent in most projects. The subject first appeared in PMI’s 1987 edition of PMBOK (PMI, 2008). For the most part, risk has been interpreted as being unsure about project task durations and/or costs, but uncertainty plagues all aspects of the work on projects and is present in all stages of project life cycles. The impact of imperfect knowledge on the way a project is organized and on its budget and schedule will be discussed in the chapters devoted to those subjects. In the real world of project management, it has been common to deal with estimates of task durations, costs, etc. as if the information were known with certainty. In fact, a great majority of all decisions made in the course of managing a project are actually made under conditions of uncertainty. However, we can still make some estimates about the probabilities of various outcomes. If we use appropriate methods for doing this, we can apply what knowledge we have to solving project decision problems. We will not always be correct, but we will be doing the best we can. Such estimates are called “subjective probabilities,” and are dealt with in most elementary courses on probability and statistics. While such probabilities are no more than guesses, they can be processed just as empirically determined probabilities are. In the world of project management, a best guess is always better than no information at all. Then it is possible to examine some of the effects of uncertainty on project selection. At times, an organization may wish to evaluate a project about which there is little information. R & D projects sometimes fall into this general class. But even in the comparative mysteries of R & D activities, the level of uncertainty about the outcomes of R & D is not beyond analysis. As we noted earlier, there is actually not much uncertainty about whether a product, process, or service can be developed, but there can be considerable uncertainty about when it will be developed and at what cost. As they are with R & D projects, time and cost are also often uncertain in other types of projects. When the organization undertakes projects in which it has little or no recent experience—for example, investment in an unfamiliar business, engaging in international trade, and a myriad of other projects common enough to organizations, in general, but uncommon to any single organization—there are three distinct areas of uncertainty. First, there is uncertainty about the timing of the project and the cash flows it is expected to generate. Second, though not as common as generally believed, there may be uncertainty about the direct outcomes of

2.5

THE PROJECT PORTFOLIO PROCESS (PPP)

65

the project—that is, what it will accomplish. Third, there is uncertainty about the side effects of the project—its unforeseen consequences. Typically, we try to reduce such uncertainty by the preparation of pro forma documents. Pro forma profit and loss statements and break-even charts are examples of such documents. The results, however, are not very satisfactory unless the amount of uncertainty is reflected in the data that go into the documents. When relationships between inputs and outputs in the projects are complex, Monte Carlo simulation (Meredith et al., 2002) can handle such uncertainty by exposing the many possible consequences of embarking on a project. With the great availability of microcomputers and user-friendly software (e.g., Crystal Ball®), simulation for assessing risk is becoming very common. A thorough discussion of methods for handling risk is coming in Chapter 6, and some simulation examples will be given in Chapters 7 and 8.

2.5

THE PROJECT PORTFOLIO PROCESS (PPP)

PMBOK Guide 1.4.1

Although up to now we have primarily talked about the selection of a project in competition with other projects, in reality organizations typically maintain a portfolio of projects, and trying to keep a proper balance among this portfolio is the real task of upper management. With limited resources, management must choose between long-term and short-term projects, safe and risky projects, manufacturing and marketing projects, and so on. To help choose between the myriad of project proposals, in competition with ongoing projects as well as each other, management needs some overarching measures to evaluate each of the projects, and those measures are commonly related to the organization’s mission, goals, and strategy. Project portfolio management is briefly defined and compared to project and program management in Chapter 1 of PMBOK®. We will assume here that the organization has already identified its mission, goals, and strategy—by using some formal analytic method such as SWOT analysis (strengths, weaknesses, opportunities, threats), and that these are well known throughout the organization. If this is not the case, then any attempt to tie the organization’s projects to its goals is folly and the PPP will have little value. Deloitte Consulting (McIntyre, 2006) found that only 30 percent of surveyed organizations insisted on knowing the value a project would add to the organization’s strategy before granting approval. Deloitte also identified the following eight symptoms of a misaligned portfolio:

• • • • • • • •

Many more projects than management expected Inconsistent determination of benefits, including double-counting Competing projects; no cross-comparison of projects “Interesting” projects that don’t contribute to the strategy Projects whose costs exceed their benefits Projects with much higher risks than others in the portfolio; no risk analysis of projects Lack of tracking against the plan, at least quarterly No identified “client” for many projects

If the goals and strategies have been well articulated, however, then the PPP can serve many purposes, as articulated by Swanson (2011):

• • •

To identify proposed projects that are not really projects and should be handled through other processes To prioritize the list of available projects To intentionally limit the number of overall projects being managed so the important projects get the resources and attention they need

66

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

• • • • • • • • •

To identify the real options that each project offers

To identify projects that best fit the organization’s goals and strategy To identify projects that support multiple organizational goals and cross-reinforce other important projects To identify co-dependent projects To eliminate projects that incur excessive risk and/or cost To eliminate projects that bypassed a formal selection process and may not provide benefits corresponding to their risks and/or costs To keep from overloading the organization’s resource availability To balance the resources with the needs To balance short-, medium-, and long-term returns

Project Management in Practice Using a Project Portfolio to Achieve 100% On-Time Delivery at Decor Cabinet Company

Décor Cabinets, a custom cabinet maker in Canada, adopted the strategic goal of 100 percent on-time delivery of their cabinets to achieve long-term customer loyalty and create added value that enhances their profitability. Having such a clear objective helped them assemble a project portfolio uniquely focused on their goal, although it also meant declining some seemingly profitable project ideas requested by customers. However, if demand increased for the

requested products, it could have had a serious negative impact on their delivery goals. It was difficult to resist pressure from different areas of the company to support these kinds of projects: “You can easily lose focus.” the CEO admitted. “Sometimes when ROI drives all decision-making you miss the bigger picture.” Source: S. F. Gale, “The Bottom Line,” PM Network, Vol. 21.

2.5

THE PROJECT PORTFOLIO PROCESS (PPP)

67

The PPP attempts to link the organization’s projects directly to the goals and strategy of the organization. This occurs not only in the project’s initiation and planning phases, but also throughout the life cycle of the projects as they are managed and eventually brought to completion. In the reading “From Experience: Linking Projects to Strategy” at the end of this chapter, Hewlett-Packard, a firm that is highly dependent on successful new-product projects, found that through their version of PPP they could reduce their portfolio of projects by about twothirds. This resulted in better funding and executing those projects that were most strategically important to the company and thereby substantially improving the chances of project success. Thus, the PPP is also a means for monitoring and controlling the organization’s strategic projects. On occasion, and particularly during recessions and difficult economic times, this will mean shutting down projects prior to their completion because their risks have become excessive, their costs have escalated out of line with their expected benefits, another (or a new) project does a better job of supporting the goals, or any variety of similar reasons. It should be noted that a significant portion of the administration of this process could be managed by the Project Management Office, a concept to be discussed in Chapter 5. The steps in this process generally follow those described in Longman et al. (1999) and Englund et al. (1999).

Step 1: Establish a Project Council The main purpose of the project council is to establish and articulate a strategic direction for those projects spanning internal or external boundaries of the organization, such as cross-departmental or joint venture. Thus, senior managers must play a major role in this council. Without the commitment of senior management, the PPP will be incapable of achieving its main objectives. The council will also be responsible for allocating funds to those projects that support the organization’s goals and controlling the allocation of resources and skills to the projects. In addition to senior management, others who should be members of the project council are:

• • • • •

the project managers of major projects the head of the Project Management Office, if one exists particularly relevant general managers those who can identify key opportunities and risks facing the organization anyone who can derail the progress of the PPP later on in the process

Step 2: Identify Project Categories and Criteria In this step, various project categories are identified so the mix of projects funded by the organization will be spread appropriately across those areas making major contributions to the organization’s goals. In addition, within each category, criteria are established to discriminate between very good and even better projects. The criteria are also weighted to reflect their relative importance. Identifying separate categories not only facilitates achievement of multiple organizational goals (e.g., long term, short term, internal, external, tactical, strategic) but also keeps projects from competing with each other on inappropriate categories. The first task in this step is to list the goals of each existing and proposed project: What is the mission, or purpose, of this project? Relating these to the organization’s goals and strategies should allow the council to identify a variety of categories that are important to achieving the organization’s goals. Some of these were noted above, but another way to position some of the projects (particularly product/service development projects) is in terms of their extent of product and process changes.

68

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

Wheelwright et al. (1992) have developed a matrix called the aggregate project plan illustrating these changes, as shown in Figure 2-3. Based on the extent of product change and process change, they identified four separate categories of projects: 1. Derivative projects. These are projects with objectives or deliverables that are only incrementally different in both product and process from existing offerings. They are often meant to replace current offerings or add an extension to current offerings (lower priced version, upscale version). 2. Platform projects. The planned outputs of these projects represent major departures from existing offerings in terms of either the product/service itself or the process used to make and deliver it, or both. As such, they become “platforms” for the next generation of organizational offerings, such as a new model of automobile or a new type of insurance plan. They thus form the basis for follow-on derivative projects that attempt to extend the platform in various dimensions. 3. Breakthrough projects. Breakthrough projects typically involve a newer technology than platform projects. It may be a “disruptive” technology that is known to the industry or something proprietary that the organization has been developing over time. Examples here include the use of fiber-optic cables for data transmission, cash-balance pension plans, and hybrid gasoline-electric automobiles. 4. R&D projects. These projects are “blue-sky,” visionary endeavors oriented toward using newly developed technologies, or existing technologies in a new manner. They may also be for acquiring new knowledge, or developing new technologies themselves. The size of the projects plotted on the array indicates the size/resource needs of the project and the shape may indicate another aspect of the project, e.g., internal/external, long/medium/

Figure 2-3

An example aggregate project plan.

2.5

THE PROJECT PORTFOLIO PROCESS (PPP)

69

short term, or whatever aspect needs to be shown. The numbers indicate the order, or time frame, in which the projects are to be (or were) implemented, separated by category, if desired. The aggregate project plan can be used for many purposes:

• • • • •

To view the mix of projects within each illustrated aspect (shape) To analyze and adjust the mix of projects within each category or aspect To assess the resource demands on the organization, indicated by the size, timing, and number of projects shown To identify and adjust the gaps in the categories, aspects, sizes, and timing of the projects To identify potential career paths for developing project managers, such as team member of a derivative project, then team member of a platform project, manager of a derivative project, member of a breakthrough project, and so on

Next, the council should develop separate criteria and cost ranges for each category that determine those projects that will support the organizational strategy and goals. Example criteria might include alignment with the organization’s goals/strategy, riskiness of the project, financial return, probability of success, likelihood of achieving a breakthrough in a critical offering, appeal to a large (or new) market, impact on customer satisfaction, contribution to employee development, knowledge acquisition, and availability of staff/resources. Scales also need to be determined for each criterion to measure how different projects score on each of them. The scales on which these criteria are measured should be challenging so that the scores separate the best projects from those that are merely good. The scales should also serve as an initial screen, to start the process of winnowing out the weakest projects. Thus, they should include limits on their extremes, such as minimum rate of return (if a financial criterion is appropriate), maximum probability of technical failure given proposed budget and schedule, or minimum acceptable potential market share. Finally, the council needs to set an importance weighting for the various criteria in each category. Note that even if the same criteria apply to multiple categories, their weights might be different. For example, if a firm needs to develop high-level, skilled project managers for their strategic projects, employee development might be more important for breakthrough projects but less important for derivative projects. Also, the weights might change depending on the life cycle stage of the project. For example, early in a project’s life, strategic considerations are often most important while in the midpoint of a project, tactical considerations might be more important. The model we have described above is a “weighted, factor scoring model,” as described earlier. As noted then, there are some standard, well-known tools to help develop the weights, scales, and criteria such as the Delphi method (Dalkey, 1969), the analytic hierarchy process (AHP), (Saaty, 1980), a simplified version of AHP by Frame (1997), and even software such as Expert Choice®. For more complex situations, with large numbers of projects and/or large councils, the more sophisticated approaches are often more helpful, particularly if used with software that automatically calculates the scores and ranks the projects.

Step 3: Collect Project Data For each existing and proposed project, assemble the data appropriate to that category’s criteria. Be sure to update the data for ongoing projects and not just use the data from the previous evaluation. For cost data, use “activity based costs” (see Section 7.1) rather than incremental costs. Challenge and try to verify all data; get other people involved in validating the data, perhaps even customers (e.g., market benefit). Include the timing, both date and duration, for expected benefits and resource needs. Use the project plan, a schedule of project activities,

70

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

past experience, expert opinion, whatever is available to get a good estimate of the data. Then document any assumptions made so that they can be checked in the future as the project progresses. If the project is new, you may want to fund only enough work on the project to verify the assumptions or determine the window-of-opportunity for the proposed product or process, holding off full funding until later. Similarly, identify any projects that can be deferred to a later time period, those that must precede or follow other projects, those that support other projects or should be done in conjunction with them, those that can be outsourced, and other such special aspects of the projects. Next, use the criteria score limits to screen out the weaker projects: Have costs on existing projects escalated beyond the project’s expected benefits? Has the benefit of a project lessened because the organization’s goals have changed? Does a competitor’s new entry obviate the advantages of a project? Does a new (or old) project dominate an existing or proposed project in terms of its benefits, furtherance of organizational goals, reduced costs? Also, screen in any projects that do not require deliberation, such as projects mandated by regulations or laws, projects that are operating or competitive necessities, projects required for environmental or personnel reasons, and so on. The fewer projects that need to be compared and analyzed, the easier the work of the council.

Step 4: Assess Resource Availability Next, assess the availability of both internal and external resources, by type, department, and timing. Note that labor availability should be estimated conservatively, leaving time for vacations, personal needs, illness, holidays, and most important, regular functional (nonproject) work. After allowing for all of these things that limit labor availability, add a bit more, perhaps 10 percent, to allow for the well-known fact that human beings need occasional short breaks to rest or meet other human needs. Timing is particularly important, since project resource needs by type typically vary up to 100 percent over the life cycle of projects. Needing a normally plentiful resource at the same moment it is fully utilized elsewhere may doom an otherwise promising project. Eventually, the council will be trying to balance aggregate project resource needs over future periods with resource availabilities so timing is as important as the amount of maximum demand and availability. This is the major subject of Chapter 9.

Step 5: Reduce the Project and Criteria Set In this step, multiple screens are employed to try to narrow down the number of competing projects. As noted earlier, the first screen is each project’s support of the organization’s goals. Other possible screens might be criteria such as:

• • • • • • • • • • •

Whether the required competence exists in the organization Whether there is a market for the offering How profitable the offering is likely to be How risky the project is If there is a potential partner to help with the project If the right resources are available at the right times If the project is a good technological/knowledge fit with the organization If the project uses the organization’s strengths, or depends on its weaknesses If the project is synergistic with other important projects If the project is dominated by another existing or proposed project If the project has slipped in its desirability since the last evaluation

2.5

THE PROJECT PORTFOLIO PROCESS (PPP)

71

One way to evaluate the dominance of some projects over others, and at the same time eliminate nondifferentiating criteria, is by comparing the coefficients of variation of each of the criteria across the projects. This technique allows an analyst to maximize the variation within the project set across relevant criteria, eliminating similar projects that are dominated, and identifying criteria that, at least in this evaluation round, do not differentiate among the projects. See Raz (1997) for an example of this approach. The result of this step may involve canceling some ongoing projects or replacing them with new, more promising projects. Beware, however, of the tendency to look more favorably upon new, untested concepts than on current projects experiencing the natural problems and hurdles of any promising project.

Step 6: Prioritize the Projects within Categories Apply the scores and criterion weights to rank the projects within each category. It is acceptable to hold some hard-to-measure criteria out for subjective evaluation, such as riskiness, or development of new knowledge. Subjective evaluations can be translated from verbal to numeric terms easily by the Delphi or other methods and used in the weighted factor scoring model. It should be remembered that such criteria as riskiness are usually composite measures of a set of “risks” in different areas. The same is true of criteria like “development of new knowledge.” When checking the results of this step, however, reconsider the projects in terms of their benefits first and their resource costs second. The former are commonly more difficult to assess and a reconsideration based on more familiarity with the project profiling process and other project evaluations may suggest interchanging the priority of neighboring projects. This could be especially critical around the project cutoff point. Because the projects competing around the cutoff point are typically quite close in benefit/cost scores, there are usually no serious consequences resulting from “errors.” This is, however, an excellent problem on which to use sensitivity analysis. It is also possible at this time for the council to summarize the “returns” from the projects to the organization. However, this should be done by category, not for each project individually since different projects are offering different packages of benefits that are not comparable. For example, R & D projects will not have the expected monetary return of derivative projects; yet it would be foolish to eliminate them simply because they do not measure up on this (irrelevant, for this category) criterion.

Step 7: Select the Projects to Be Funded and Held in Reserve The first task in this step is an important one: determining the mix of projects across the various categories (and aspects, if used) and time periods. Next, be sure to leave some percent (often 10–15 percent) of the organization’s resource capacity free for new opportunities, crises in existing projects, errors in estimates, and so on. Then allocate the categorized projects in rank order to the categories according to the mix desired. It is usually a good practice to include some speculative projects in each category to allow future options, knowledge improvement, additional experience in new areas, and such. Overall, the focus should be on committing to fewer projects but with sufficient funding to allow project completion. Document why late projects were delayed and why some, if any, were defunded. One special type of delayed project mentioned earlier is sometimes called an “out-plan” project (in contrast to the selected “in-plan” projects) (Englund et al., 1999). Outplan projects are those that appear promising but are awaiting further investigation before a final decision is made about their funding, which could occur in the next PPP cycle or sooner, if they warrant the use of some of the 10–15 percent funding holdout.

72

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

The result of this step (and most of the project portfolio process) is illustrated in the Plan of Record shown in Figure 2-4. Here, the mix across categories is listed, the priorities and resource needs of each project are given, the timing (schedule) of each project over the PPP cycle (6 months assumed here) is shown (to match resource availability), the out-plan projects, if any, are shown, and the total resource needs and availabilities are listed.

Step 8: Implement the Process The first task in this final step is to make the results of the PPP widely known, including the documented reasons for project cancellations, deferrals, and non-selection as was mentioned earlier. Top management must now make their commitment to this project portfolio process totally clear by supporting the process and the results. This may require a PPP champion near the top of the organization. As project proposers come to understand the workings and importance of the PPP, their proposals will more closely fit the profile of the kinds of projects the organization wishes to fund. As this happens, it is important to note

Derivative

Figure 2-4

Plan of Record.

2.5

THE PROJECT PORTFOLIO PROCESS (PPP)

73

that the council will have to concern itself with the reliability and accuracy of proposals competing for limited funds. Senior management must fully fund the selected projects. It is neither appropriate nor ethical for senior management to undermine PPP and the council as well as strategically important projects by playing a game of arbitrarily cutting X percent from project budgets. The council needs to be wary of interpersonal or interdepartmental competition entering the scene at this point also. In some organizations, individuals with their own particular agenda will ignore committees and processes (they may be heard to argue that committees never affect anything anyway) until implementation time rolls around, and then they attempt to exercise their political power to undermine the results of others’ long labors. If this does occur, it is indicative of serious organizational problems and the PPP process will fail until the problems are corrected. Of course, the process will need to be repeated on a regular basis. The council should determine how often this should be, and to some extent it depends on the speed of change in the industry the organization is in. For some industries, quarterly analysis may be best while in slow-moving industries, yearly may be fine. Swanson (2011) warns, however, that too-frequent reprioritizing of projects can result in confusion and frustration, particularly if resources suddenly are unavailable. Finally, the process should be flexible and improved continuously. Instinct may suggest ways that the process may be altered to better match the competitive environment, or to reflect more closely the organization’s goals. The process should be changed when it is found appropriate to do so, including categories, criteria, steps, the order of tasks, and so on. We offer a final note on this subject of creating and managing a portfolio of projects. In the preceding description of portfolio building it was tacitly assumed that the projects were independent and could be dealt with individually. At times, the projects in a portfolio are not independent. Dickinson et al. (2001) describe a model developed for the Boeing Company that optimizes a portfolio of interdependent product improvement projects. The model includes risk as well as cost/benefit analysis. Before leaving the subject of project portfolios, it is important to consider the problem of decreasing the size of the organization’s investment in projects. The sharp economic downturn of 2008–09 required a great many firms to do just that, and many were simply not prepared to handle the problem. Senior management, or the project council, or the Enterprise Project Management Office, or whatever group is in charge of selecting projects for inclusion in the organization’s portfolio of project should also develop a set of criteria for removing projects from the portfolio. In an interesting short paper, Wheatley (2009) discusses this issue. He notes that such issues as the size of the expected ROI may be of less importance than the timing of cash in-and-outflows. He also notes that risk should be included as a factor in all decisions. The organization’s tolerance for risk is very likely to change during downturns. Some projects are luxuries. Others may be major drivers of future profits and growth. Some may be oriented to cost savings that could have almost immediate benefits. Even projects aimed at meeting legal mandates may have a cost that is significantly higher than the possible legal penalties if the mandates are ignored for a time. Many firms are choosing to pay the penalty instead of implementing costly federal mandates. Competitive necessity projects with low immediate returns may well outrank projects with higher returns—or they may not. Some projects can be stopped midway without doing much damage to the project’s expected success. Others cannot, and if delayed must start from scratch, or be cancelled. Developing a list of possible criteria for cutting or eliminating the funding for a project is complicated. To be useful, each item in the list should be prioritized. This is a job that demands close attention from senior management.

74

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

2.6

PROJECT BIDS AND RFPS (REQUESTS FOR PROPOSALS)*

PMBOK Guide Chapter 12

The topic of bidding on requests for proposals is highly relevant to the PMBOK knowledge area (9) of Procurement. Further discussion of procurement is included in Sections 5.2 and 6.5. Now that project selection methods have been discussed, it is appropriate to consider what documentation is needed to evaluate a project that is being considered. We have spoken about costs, benefits, risks, profits, timing, and other such matters in general terms but now we are looking at the specifics that need to be documented in response to a requested bid. The set of documents submitted for evaluation is called the project proposal, whether it is brief (a page or two) or extensive, and regardless of the formality with which it is presented. Several issues face firms preparing bid proposals, particularly firms in the aerospace, construction, defense, and consulting industries. These are: 1. 2. 3. 4.

Which projects should be bid on? How should the proposal-preparation process be organized and staffed? How much should be spent on preparing proposals for bids? How should the bid prices be set? What is the bidding strategy? Is it ethical?

Generally, these decisions are made on the basis of their overall expected values, perhaps as reflected in a scoring model. In-house proposals submitted by a firm’s personnel to that firm’s top management do not usually require the extensive treatment given to proposals submitted to outside clients or agencies such as the Department of Defense. For the Department of Defense, a proposal must be precisely structured to meet the requirements contained in the official Request for Proposal (RFP) or Request for Quotation (RFQ)—more specifically, in the Technical Proposal Requirements (TPR) that is part of the RFP or RFQ. The details of the construction and preparation of a proposal to be submitted to the government or other outside funder are beyond the scope of this book. Fortunately, the subject has been well treated by Knutson (1996a, 1996b, and 1996c), but it should be noted that customs, practices, rules, and laws concerning proposals vary from nation to nation (e.g., see Jergeas et al., 1997). We comment only on the general approach below. All bid proposals should begin with a short summary statement (an “Executive Summary”) covering the fundamental nature of the proposal in minimally technical language, as well as the general benefits that are expected. All proposals should be accompanied by a “cover letter.” Roman (1986, pp. 67–68) emphasizes that the cover letter is a key marketing document and is worthy of careful attention. In addition to the Executive Summary and the cover letter, every proposal should deal with four distinct issues: (1) the nature of the technical problem and how it is to be approached; (2) the plan for implementing the project once it has been accepted; (3) the plan for logistic support and administration of the project; and (4) a description of the group proposing to do the work, plus its past experience in similar work. The precise way in which the contents of a proposal are organized usually follows the directions found in the TPR or RFP, the stated requirements of a specific potential funder, the traditional form used by the organization issuing the proposal, or, occasionally, the whim of the writer. As is the case with most products, the highest probability of acceptance will occur when the proposal meets the expectations of the “buyer,” as to form and content. At times there is a tendency to feel that “nontechnical” projects (which usually means projects not concerned with the physical sciences or a physical product) are somehow exempt from the need to describe how the problem will

*Occasionally, particular sections will be shaded, meaning that they can be skipped without loss of continuity.

2.6

PROJECT BIDS AND RFPS (REQUESTS FOR PROPOSALS)

75

be approached and how the project will be implemented—including details such as milestones, schedules, and budgets. To deal with nontechnical projects casually is folly and casts considerable doubt on the proposer’s ability to deliver on promises. (It is all too common for projects concerned with the development of art, music, drama, and computer software, among other “nontechnical” areas, to be quite vague as to deliverables, deadlines, and costs.) On the other hand, when the proposal is aimed at another division or department of the same parent organization, the technical requirements of the proposal may be greatly relaxed, but the technical approach and implementation plan are still required—even if presented in an informal manner.

The Technical Approach The proposal begins with a general description of the problem to be addressed or project to be undertaken. If the problem is complex, the major subsystems of the problem or project are noted, together with the organization’s approach to each. The presentation is in sufficient detail that a knowledgeable reader can understand what the proposer intends to do. The general method of resolving critical problems is outlined. If there are several subsystems, the proposed methods for interfacing them are covered. In addition, any special client requirements are listed along with proposed ways of meeting them. All test and inspection procedures to assure performance, quality, reliability, and compliance with specifications are noted.

The Implementation Plan The implementation plan for the project contains estimates of the time required, the cost, and the materials used. Each major subsystem of the project is listed along with estimates of its cost. These costs are aggregated for the whole project, and totals are shown for each cost category. Hours of work and quantities of material used are shown (along with the wage rates and unit material costs). A list of all equipment costs is added, as is a list of all overhead and administrative costs. Depending on the wishes of the parent organization and the needs of the project, project task schedules (e.g., time charts, network diagrams, Gantt charts) are given for each subsystem and for the system as a whole. (See Chapter 8 for more about time charts, network diagrams, and Gantt charts.) Personnel, equipment, and resource usages are estimated on a period-by-period basis in order to ensure that resource constraints are not violated. Major milestones are indicated on the time charts. Contingency plans are specifically noted. For any facility that might be critical, load charts are prepared to make sure that the facility will be available when needed.

The Plan for Logistic Support and Administration The proposal includes a description of the ability of the proposer to supply the routine facilities, equipment, and skills needed during any project. Having the means to furnish artist’s renderings, special signs, meeting rooms, stenographic assistance, reproduction of oversized documents, computer graphics, word processing, video teleconferencing, and many other occasionally required capabilities provides a “touch of class.” Indeed, their unavailability can be irritating. Attention to detail in all aspects of project planning increases the probability of success for the project—and impresses the potential funder. It is important that the proposal contain a section explaining how the project will be administered. Of particular interest will be an explanation of how control over subcontractors will be administered, including an explanation of how proper subcontractor performance is to be insured and evaluated. The nature and timing of all progress reports, budgetary reports, audits,

76

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

and evaluations are covered, together with a description of the final documentation to be prepared for users of the proposed deliverables. Termination procedures are described, clearly indicating the disposition of project personnel, materials, and equipment at project end. A critical issue, often overlooked, that should be addressed in the administrative section of the proposal is a reasonably detailed description of how change orders will be handled and how their costs will be estimated. Change orders are a significant source of friction (and lawsuits) between the organization doing the project and the client. The client rarely understands the chaos that can be created in a project by the introduction of a seemingly simple change. To make matters worse, the group proposing the project seems to have a penchant for misleading the potential client about the ease with which “minor” changes can be adopted during the process of implementing the project. Control of change orders is covered in Chapter 11.

Past Experience All proposals are strengthened by including a section that describes the past experience of the proposing group. It contains a list of key project personnel together with their titles and qualifications. For outside clients, a full résumé for each principal should be attached to the proposal. When preparing this and the other sections of a proposal, the proposing group should remember that the basic purpose of the document is to convince a potential funder that the group and the project are worthy of support. The proposal should be written accordingly.

SUMMARY This chapter initiated our discussion of the project management process by describing procedures for strategically evaluating and selecting projects. We first described the strategic objective of using projects to help achieve the organization’s goals and strategy, and a project portfolio process to help achieve this. We then outlined some criteria for project selection models and discussed the general nature of these models. The chapter described the types of models in use and their advantages and disadvantages. Considering the degree of uncertainty associated with many projects, a section was devoted to evaluating the impact of risk and uncertainty. Concluding the discussion, some general comments were made about data requirements, the use of these models, and how to implement the project portfolio process. The final section discussed the documentation required to bid on RFPs (requests for proposals). The following specific points were made in this chapter:

The role of projects in achieving the organization’s goals and strategy is critical.

The eight-step project portfolio process is an effective way to select and manage projects that are tied to the organization’s goals.

Primary model selection criteria are realism, capability, flexibility, ease of use, and cost.

Preparatory steps in using a model include: (1) identifying the firm’s objectives; (2) weighting them relative to each other; and (3) determining the probable impacts of the project on the firm’s competitive abilities.

Project selection models can generally be classified as either numeric or nonnumeric; numeric models are further subdivided into profitability and scoring categories.

Nonnumeric models include: (1) the sacred cow; (2) the operating necessity; (3) the competitive necessity; and (4) comparative benefit.

Profitability models include standard forms such as: (1) payback period; (2) average rate of return; (3) discounted cash flow; (4) internal rate of return; and (5) profitability index.

Project management maturity measurement is a way of assessing an organization’s ability to conduct projects successfully.

Scoring models—the authors’ preference—include: (1) the unweighted 0–1 factor model; (2) the unweighted factor scoring model; (3) the weighted factor scoring model; and (4) the constrained weighted factor scoring model.

Project proposals generally consist of a number of sections: (1) the technical approach; (2) the implementation plan; (3) the plan for logistic support and administration; and (4) past experience.

In the next chapter we consider the selection of the appropriate manager for a project and what characteristics are most helpful for such a position. We also address the issue of the project manager’s special role, and the demands and responsibilities of this critical position.

QUESTIONS

77

GLOSSARY Decision Support System A computer package and data base to aid managers in making decisions. It may include simulation programs, mathematical programming routines, and decision rules. Delphi A formalized method for transforming the opinions of a group of individuals into quantitative measures that can be aggregated to use in decision making. Expert System A computer package that captures the knowledge of recognized experts in an area and can make inferences about a problem based on decision rules and data input to the package. Maturity The sophistication and experience of an organization in managing multiple projects. Model A way of looking at reality, usually for the purpose of abstracting and simplifying it, to make it understandable in a particular context. Network A group of items connected by some common mechanism.

Portfolio A group or set of projects with varying characteristics. Pro forma Projected or anticipated, usually applied to financial data such as balance sheets and income statements. Programming An algorithmic methodology for solving a particular type of complex problem, usually conducted on a computer. Project portfolio process An eight-step procedure for selecting, implementing, and reviewing projects that will help an organization achieve its strategic goals. Simulation A technique for emulating a process, usually conducted a considerable number of times to understand the process better and measure its outcomes under different policies.

QUESTIONS Material Review Questions

1. What are the four parts of a technical proposal? 2. By what criteria do you think managers judge selection models? What criteria should they use? 3. Contrast the competitive necessity model with the operating necessity model. What are the advantages and disadvantages of each? 4. What is a sacred cow? Give some examples. 5. Give an example of a Q-Sort process for project selection. 6. What are some of the limitations of project selection models? 7. Contrast the real options selection approach with profitability models.

8. How does the discounted cash flow method answer some of the criticisms of the payback period and average rate of return methods? 9. What are some advantages and disadvantages of the profit/profitability numeric models? 10. What is the desired result of applying the project portfolio process? What do firms usually find happens? 11. Describe the discovery-driven planning approach. 12. Describe the eight-step project portfolio process. 13. What does the term “project management maturity” mean? 14. Where do most firms fall on the maturity scale?

Class Discussion Questions

15. Which of the many purposes of the project portfolio process are most important to a firm with a low project management maturity? Which to a firm with high maturity? 16. On what basis does the real options model select projects? 17. What is the real difference between profitability and scoring models? Describe a model that could fit both categories. 18. Contrast the window-of-opportunity approach with discovery-driven planning.

19. Discuss how the following project selection models are used in real-world applications. (a) Capital investment with discounted cash flow. (b) Simulation models. 20. Why do you think managers underutilize project selection models? 21. Would uncertainty models be classified as profitability models, scoring models, or some other type of model? 22. Is project management maturity focused on doing better on multiple projects or single projects?

78

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

23. Are there certain types of projects that are better suited for nonnumeric selection methods as opposed to numeric ones? 24. Identify some of the ethical issues that can arise in a bid response to an RFP. 25. What important comparisons does the aggregate project plan in Figure 2-3 allow? 26. What does the plan of record illustrate that the aggregate project plan does not? 27. If sustainability focuses on long-run profitability, why is it classified as a “non-numeric” model? Implementing Strategy through Projects at Blue Cross/Blue Shield

28. Is the new project management approach to implementing strategy bottom-up or top-down? 29. What is the role of projects and their management in this new process? That is, wouldn’t a functional approach have worked just as well? 30. What other benefits might you expect from a system such as this?

Project Selection for Spent Nuclear Fuel Cleanup

31. Why did it take five months to explain the problem to the stakeholders? 32. Why do you think the stakeholders no longer trusted the authorities? 33. What might have been the problems with options 1, 2, and 4? 34. How is option 3 a solution? Using a Project Portfolio to Achieve 100% On-Time Delivery at Décor Cabinets

35. Might it not make sense to include a least a few of the more promising new product projects in their portfolio? 36. If ROI isn’t the big picture, what do you think is? Taipei 101: Refitted as World’s Tallest Sustainable Building

37. Why did the owners pick such a big building for sustainability refitting? 38. What aspect of the tenant’s habits and routines relates to sustainability, as opposed to “green?”

PROBLEMS 1. Two new Internet site projects are proposed to a young start-up company. Project A will cost $250,000 to implement and is expected to have annual net cash flows of $75,000. Project B will cost $150,000 to implement and should generate annual net cash flows of $52,000. The company is very concerned about their cash flow. Using the payback period, which project is better, from a cash flow standpoint? 2. Sean, a new graduate at a telecommunications firm, faces the following problem his first day at the firm: What is the average rate of return for a project that costs $200,000 to implement and has an average annual profit of $30,000? 3. A four-year financial project has net cash flows of $20,000; $25,000; $30,000; and $50,000 in the next four years. It will cost $75,000 to implement the project. If the required rate of return is 0.2, conduct a discounted cash flow calculation to determine the NPV. 4. What would happen to the NPV of the above project if the inflation rate was expected to be 4 percent in each of the next four years? 5. Calculate the profitability index for Problem 3. For Problem 4. 6. A four-year financial project has estimates of net cash flows shown in the following table:

Year

Net Cash Flow

1

$20,000

2

25,000

3

30,000

4

35,000

It will cost $65,000 to implement the project, all of which must be invested at the beginning of the project. After the fourth year, the project will have no residual value. Using the most likely estimates of cash flows, conduct a discounted cash flow calculation assuming a 20 percent hurdle rate with no inflation. (You may use either Excel® or a paper-and-pencil calculation.) What is the discounted profitability index of the project? 7. Use a weighted score model to choose between three methods (A, B, C) of financing the acquisition of a major competitor. The relative weights for each criterion are shown in the following table as are the scores for each location on each criterion. A score of 1 represents unfavorable, 2 satisfactory, and 3 favorable.

INCIDENTS FOR DISCUSSION

8. Develop a spreadsheet for Problem 7. (a) What would your recommendation be if the weight for the implementation risks went down to 10 and the weight of cultural differences went up to 25? (b) Suppose instead that method A received a score of 3 for implementation risks. Would your recommendation change under these circumstances? (c) The vice president of finance has looked at your original scoring model and feels that tax considerations should be included in the model with a weight of 15. In addition, the VP has scored the methods on tax considerations as follows: method A received a score of 3, method B received a score of 2, and method C received a score of 1. How would this additional information affect your recommendation? 9. Nina is trying to decide in which of four shopping centers to locate her new boutique. Some locations attract a higher class of clientele than others, some are in an indoor mall, some have a much greater customer

79

traffic volume than others, and, of course, rent varies considerably from one location to another. Because of the nature of her store, she has decided that the class of clientele is the most important consideration, the higher the better. Following this, however, she must pay attention to her expenses and rent is a major item, probably 90 percent as important as clientele. An indoor, temperature-controlled mall is a big help, however, for stores such as hers where 70 percent of sales are from passersby slowly strolling and window shopping. Thus, she rates this as about 95 percent as important as rent. Last, a higher traffic volume of shoppers means more potential sales; she thus rates this factor as 80 percent as important as rent. As an aid in visualizing her location alternatives, she has constructed the following table. A “good” is scored as 3, “fair” as 2, and “poor” as 1. Use a weighted score model to help Nina come to a decision.

10. Referring to Problem 11, develop a spreadsheet to help Nina select a location for her boutique. Suppose Nina is able to negotiate a lower rent at location 3 and thus raise its ranking to “good.” How does this affect the overall rankings of the four locations?

INCIDENTS FOR DISCUSSION Portillo, Inc.

Portillo, Inc. is a manufacturer of small household appliances and cooking utensils. Working with Johanna Portillo, the CEO of the firm, her executive team has developed a scoring model to analyze and select new items to be added to the product line. The model is also used to select old items to be dropped from the line. It employs both objective and subjective estimates of scores for the financial and nonfinancial elements that make up the model. The model is used by a Drop/Add Committee she appointed. Ms. Portillo is pleased with the construct of the model and feels that it includes all of the factors relevant to the drop/add decision. She is also comfortable with the factor weights developed by her executives. Following a review of the past year’s meetings of the Drop/Add Committee, Ms. Portillo discovered that several

managers made significant errors when estimating costs and benefits of many projects. After a careful study of the estimates, she noticed that the sponsors of a product seemed to overestimate its benefits and underestimate its costs. It also appeared that other managers might be underestimating benefits and overestimating costs. She was not sure about her suspicions and wondered how to find out if her notions were correct. Even if they were correct, she wondered what to do about it. Questions: How can Ms. Portillo find out if her suspicions are correct? What are her options if her idea is supported? L & M Power

In the next two years, a large municipal gas company must begin constructing new gas storage facilities to accommodate the Federal Energy Regulatory Commission’s Order

80

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

636 deregulating the gas industry. The vice-president in charge of the new project believes there are two options. One option is an underground deep storage facility (UDSF) and the other is a liquified natural gas facility (LNGF). The vice-president has developed a project selection model and will use it in presenting the project to the president. For the models she has gathered the following information: Initial Cost UDSF $10,000,000 LNGF

25,000,000

Since the vice-president’s background is in finance, she believes the best model to use is a financial one, net present value analysis. Questions: Would you use this model? Why or why not? Base your answer on the five criteria developed by Souder and evaluate this model in terms of the criteria.

Operating Cost / Expected Salvage Cu. Ft. Life Value $0.004 0.002

20 years 15

10% 5

CONTINUING INTEGRATIVE CLASS PROJECT The task for the class here is to select an appropriate project for the course. Consideration should be given to the fixed end-of-term deadline, the limited monetary but large personnel resources available, the irrelevance of financial returns, and the availability of contacts and good project possibilities outside the classroom. As indicated in Chapter 1, there are often many excellent projects on a college campus, such as in the residence halls, the library, the cafeteria,

the medical care office, and so on. When evaluating these situations for potential projects, consider factors such as whether the class has a good inside contact to sponsor the project, whether data will be easily accessible for the class, how many students the organization or department can handle at a time, how extensive the project is, how clear the problem/opportunity is, when they will need an answer, and other such important issues.

BIBLIOGRAPHY Åstebro, T. “Key Success Factors for Technological Entrepreneurs’ R & D Projects.” IEEE Transactions on Engineering Management, August 2004. Baker, B. “The Fall of the Firefly: An Assessment of a Failed Project Strategy.” Project Management Journal, September 2002. Baker, B., and R. Menon. “Politics and Project Performance: The Fourth Dimension of Project Management.” PM Network, November 1995. Booz, Allen, and Hamilton, Inc. Management of New Products. New York: Booz, Allen, and Hamilton, Inc., 1966. Cicmil, S., and D. Hodgson. ”New Possibilities for Project Management Theory: A Critical Judgement.” Project Management Journal, December 2006. Cleland, D. I., and W. R. King. Project Management Handbook. New York: Van Nostrand-Reinhold, 1983. Dalkey, N. C. The Delphi Method: An Experimental Study of Group Opinion (RM-5888-PR). Santa Monica, CA: The Rand Corporation, June 1969. Dickinson, M. W., A. C. Thornton, and S. Graves. “Technology Portfolio Management: Optimizing Interdependent Projects over Multiple Time Periods.” IEEE Transactions on Engineering Management, November 2001.

Dinsmore, P. C., “How Grown-Up Is Your Organization?” PM Network, June 1998. Doctor, R. N., D. P. Newton, and A. Pearson. “Managing Uncertainty in Research and Development.” Technovation, February 2001. Englund, R. L., and R. J. Graham. “From Experience: Linking Projects to Strategy.” Journal of Product Innovation Management, Vol. 16, No. 1, 1999. Evans, J. R., and S. J. Mantel, Jr. “A New Approach to the Evaluation of Process Innovations.” Technovation, October 1985. Frame, J. D. The New Project Management: Tools for an Age of Rapid Change, Corporate Reengineering, and Other Business Realities. San Francisco: Jossey-Bass, 1997. Gale, S. F. “The Real Deal.” PM Network, December 2009. Githens, G. “Financial Models, Right Questions, Good Decision.” PM Network, July 1998. Hayes, R., and W. J. Abernathy. “Managing Our Way to Economic Decline.” Harvard Business Review, July–August 1980. Helin, A. F., and W. E. Souder. “Experimental Test of a Q-Sort Procedure for Prioritizing R & D Projects.”

BIBLIOGRAPHY

IEEE Transactions on Engineering Management, November 1974. Ibbs, C. W., and Y. H. Kwak. “Assessing Project Management Maturity.” Project Management Journal, March 2000. Irving, R. H., and D. W. Conrath. “The Social Context of Multiperson, Multiattribute Decision-making.” IEEE Transactions on Systems, Man, and Cybernetics, May–June 1988.

81

Meade, L. M., and A. Presley. “R & D Project Selection Using the Analytic Network Process.” IEEE Transactions on Engineering Management, February 2002. Meredith, J. “The Implementation of Computer Based Systems.” Journal of Operations Management, October 1981. Meredith, J. R., S. M. Shafer, and E. Turban. Quantitative Business Modeling. Cincinnati, OH: Southwestern, 2002.

Jacob, W. F., and Y. H. Kwak. “In Search of Innovative Techniques to Evaluate Pharmaceutical R & D Projects.” Technovation, April 2003.

Pennypacker, J. S., and K. P. Grant. “Project Management Maturity: An Industry Benchmark.” Project Management Journal, March 2003.

Jergeas, G. F., and V. G. Cooke. “Law of Tender Applied to Request for Proposal Process.” Project Management Journal, December 1997.

Project Management Institute. A Guide to the Project Management Body of Knowledge, 4th ed. Newtown Square, PA: Project Management Institute, 2008.

Jolly, D. “The Issue of Weightings in Technology Portfolio Management.” Technovation, May 2003.

Project Management Institute. “Survey Reveals How Organizations Succeed.” PMI Today, February 2011. Remy, R. “Adding Focus to Improvement Efforts with PM3.” PM Network, July 1997. Rice, M. P., G. C. O’Connor, and R. Pierantozzi. “Implementing a Learning Plan to Counter Project Uncertainty.” Sloan Management Review, Winter 2008. Roman, D. D. Managing Projects: A Systems Approach. New York: Elsevier, 1986. Ross, S. A., R. W. Westerfield, and B. D. Jordan. Fundamentals of Corporate Finance, 8th ed. New York: Irwin/ McGraw-Hill, 2008. Saaty, T. S. Decision for Leaders: The Analytic Hierarchy Process. Pittsburgh: University of Pittsburgh, 1990. Simon, H. The New Science of Management Decisions, rev. ed. Englewood Cliffs, NJ: Prentice Hall, 1977. Souder, W. E. “Utility and Perceived Acceptability of R & D Project Selection Models.” Management Science, August 1973. Souder, W. E. “Project Evaluation and Selection,” in D. I. Cleland and W. R. King, eds., Project Management Handbook. New York: Van Nostrand Reinhold, 1983. Swanson, S. A. “All Things Considered.” PM Network, February 2011. Thomas, J., C. L. Delisle, K. Jugdev, and P. Buckle. “Mission Possible: Selling Project Management to Senior Executives.” PM Network, January 2001. Turban, E., and J. R. Meredith. Fundamentals of Management Science, 6th ed. Homewood, IL: Irwin, 1994. Wheatley, M., “Making the Cut.” PM Network, June 2009. Wheelwright, S. C., and K. B. Clark. “Creating Project Plans to Focus Product Development.” Harvard Business Review, March–April 1992.

Knutson, J. “Proposal Management: Analyzing Business Opportunities.” PM Network, January 1996a. Knutson, J. “Proposal Management: Generating Winning Proposals, Part 1.” PM Network, February 1996b. Knutson, J. “Proposal Management: Generating Winning Proposals, Part 2.” PM Network, March 1996c. KPMG, “Global IT Project Management.” , 2005. Liberatore, M. J., and G. J. Titus. “The Practice of Management Science in R & D Project Management.” Management Science, August 1983. Longman, A., D. Sandahl, and W. Speir. “Preventing Project Proliferation.” PM Network, July 1999. Lubianiker, S. “Opening the Book on the Open Maturity Model.” PM Network, March 2000. Luehrman, T. A. “Investment Opportunities as Real Options: Getting Started on the Numbers.” Harvard Business Review, July–August 1998a. Luehrman, T. A. “Strategy as a Portfolio of Real Options.” Harvard Business Review, September–October 1998b. Mantel, S. J., Jr., J. R. Evans, and V. A. Tipnis. “Decision Analysis for New Process Technology,” in B. V. Dean, ed., Project Management: Methods and Studies. Amsterdam: North-Holland, 1985. Matzler, K., and H. H. Hinterhuber. “How to Make Product Development Projects More Successful by Integrating Kano’s Model of Customer Satisfaction into Quality Function Deployment.” Technovation, January 1998. McGrath, R. G., and I. MacMillan. “Discovery-Driven Planning.” Harvard Business Review, July–August 1995. McIntyre, J. “The Right Fit,” PM Network, November. 2006.

82

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

The following case concerns a European firm trying to choose between almost a dozen capital investment projects being championed by different executives in the firm. However, there are many more projects available for funding than there are funds available to implement them, so the set must be narrowed down to the most valuable and important to the firm. Financial, strategic, and other data are given concerning the projects in order to facilitate the analysis needed to make a final investment recommendation to the Board of Directors.

C

A

S

E

PAN-EUROPA FOODS S.A.* C. Opitz and R. F. Bruner

It was early January, and the senior-management committee of Pan-Europa Foods was to meet to draw up the firm’s capital budget for the new year. Up for consideration were 11 major projects that totaled over €208 million (euros). Unfortunately, the board of directors had imposed a spending limit of only €80 million; even so, investment at that rate would represent a major increase in the firm’s asset base of €656 million. Thus the challenge for the senior managers of Pan-Europa was to allocate funds among a range of compelling projects: new-product introduction, acquisition, market expansion, efficiency improvements, preventive maintenance, safety, and pollution control. The Company Pan-Europa Foods, headquartered in Brussels, Belgium, was a multinational producer of high-quality ice cream, yogurt, bottled water, and fruit juices. Its products were sold throughout Scandinavia, Britain, Belgium, the Netherlands, Luxembourg, western Germany, and northern France. (See Exhibit 1 for a map of the company’s marketing region.) The company was founded in 1924 by Theo Verdin, a Belgian farmer, as an offshoot of his dairy business. Through keen attention to product development, and shrewd marketing, the business grew steadily over the years. The company went public in 1979 and by 1993 was listed for trading on the London, Frankfurt, and Brussels exchanges. Last year Pan-Europa had sales of almost €1.1 billion. Ice cream accounted for 60 percent of the company’s revenues; yogurt, which was introduced in 1982, *Reprinted with permission. Copyright Darden Graduate Business School Foundation, Charlottesville, Virginia.

contributed about 20 percent. The remaining 20 percent of sales was divided equally between bottled water and fruit juices. Pan-Europa’s flagship brand name was “Rolly,” which was represented by a fat, dancing bear in farmers’ clothing. Ice cream, the company’s leading product, had a loyal base of customers who sought out its high butterfat content, large chunks of chocolate, fruit, nuts, and wide range of original flavors. Recently, Pan-Europa sales had been static (see Exhibit 2), which management attributed to low population growth in northern Europe and market saturation in some areas. Outside observers, however, faulted recent failures in new-product introductions. Most members of management wanted to expand the company’s market presence and introduce more new products to boost sales. These managers hoped that increased market presence and sales would improve the company’s market value. Pan-Europa’s stock was currently at eight times earnings, just below book value. This price/earnings ratio was below the trading multiples of comparable companies, but it gave little value to the company’s brands. Resource Allocation The capital budget at Pan-Europa was prepared annually by a committee of senior managers who then presented it for approval by the board of directors. The committee consisted of five managing directors, the président directeur-général (PDG), and the finance director. Typically, the PDG solicited investment proposals from the managing directors. The proposals included a brief project description, a financial analysis, and a discussion of strategic or other qualitative considerations. As a matter of policy, investment proposals at PanEuropa were subjected to two financial tests, payback

83

CASE

EXHIBIT 1

Pan-Europa Foods S. A. Nations Where Pan-Europa Competed

Note: The shaded area in this map reveals the principal distribution region of Pan-Europa’s products. Important facilities are indicated by the following figures: 1. Headquarters, Brussels, Belgium 2. Plant, Antwerp, Belgium 3. Plant, Strasbourg, France 4. Plant, Nuremberg, Germany 5. Plant, Hamburg, Germany

6. Plant, Copenhagen, Denmark 7. Plant, Svald, Sweden 8. Plant, Nelly-on-Mersey, England 9. Plant, Caen, France 10. Plant, Melun, France

and internal rate of return (IRR). The tests, or hurdles, had been established by the management committee and varied according to the type of project:

EXHIBIT 2

Summary of Financial Results (all values in € millions except per-share amounts)

Gross sales Net income Earnings per share Dividends Total assets Shareholders’ equity (book value) Shareholders’ equity (market value)

The most recent estimated weighted-average cost of capital (WACC) for Pan-Europa was 10.5 percent. In describing the capital-budgeting process, the finance director,

1,076 51 0.75 20 477 182

1,072 49 0.72 20 580 206

1,074 37 0.54 20 656 235

453

400

229

Trudi Lauf, said, “We use the sliding scale of IRR tests as a way of recognizing differences in risk among the various

84

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

types of projects. Where the company takes more risk, we should earn more return. The payback test signals that we are not prepared to wait for long to achieve that return.” Ownership and the Sentiment of Creditors and Investors Pan-Europa’s 12-member board of directors included three members of the Verdin family, four members of management, and five outside directors who were prominent managers or public figures in northern Europe. Members of the Verdin family combined owned 20 percent of Pan-Europa’s shares outstanding, and company executives owned 10 percent of the shares. Venus Asset Management, a mutual-fund management company in London, held 12 percent. Banque du Bruges et des Pays Bas held 9 percent and had one representative on the board of directors. The remaining 49 percent of the firm’s shares were widely held. The firm’s shares traded in London, Brussels, and Frankfurt. At a debt-to-equity ratio of 125 percent, Pan-Europa was leveraged much more highly than its peers in the European consumer-foods industry. Management had relied on debt financing significantly in the past few years to sustain the firm’s capital spending and dividends during a period of price wars initiated by Pan-Europa. Now, with the price wars finished, Pan-Europa’s bankers (led by Banque du Bruges) strongly urged an aggressive program of debt reduction. In any event, they were not prepared to finance increases in leverage beyond the current level. The president of Banque du Bruges had remarked at a recent board meeting, Restoring some strength to the right-hand side of the balance sheet should now be a first priority. Any expansion of assets should be financed from the cash flow after debt amortization until the debt ratio returns to a more prudent level. If there are crucial investments that cannot be funded this way, then we should cut the dividend! At a price-to-earnings ratio of eight times, shares of Pan-Europa common stock were priced below the average multiples of peer companies and the average multiples of all companies on the exchanges where Pan-Europa was traded. This was attributable to the recent price wars, which had suppressed the company’s profitability, and to the well-known recent failure of the company to seize significant market share with a new product line of flavored mineral water. Since last year, all of the major securities houses had been

issuing “sell” recommendations to investors in PanEuropa shares. Venus Asset Management in London had quietly accumulated shares during this period, however, in the expectation of a turnaround in the firm’s performance. At the most recent board meeting, the senior managing director of Venus gave a presentation in which he said, Cutting the dividend is unthinkable, as it would signal a lack of faith in your own future. Selling new shares of stock at this depressed price level is also unthinkable, as it would impose unacceptable dilution on your current shareholders. Your equity investors expect an improvement in performance. If that improvement is not forthcoming, or worse, if investors’ hopes are dashed, your shares might fall into the hands of raiders like Carlo de Benedetti or the Flick brothers.1 At the conclusion of the most recent meeting of the directors, the board voted unanimously to limit capital spending in next year to €80 million. Members of the Senior Management Committee The capital budget would be prepared by seven senior managers of Pan-Europa. For consideration, each project had to be sponsored by one of the managers present. Usually the decision process included a period of discussion followed by a vote on two to four alternative capital budgets. The various executives were well known to each other: Wilhelmina Verdin (Belgian), PDG, age 57. Granddaughter of the founder and spokesperson on the board of directors for the Verdin family’s interests. Worked for the company her entire career, with significant experience in brand management. Elected “European Marketer of the Year” in 1982 for successfully introducing low-fat yogurt and ice cream, the first major roll-out of this type of product. Eager to position the company for longterm growth but cautious in the wake of recent difficulties. Trudi Lauf (Swiss), finance director, age 51. Hired from Nestlé to modernize financial controls and systems. Had been a vocal proponent of reducing

1

De Benedetti of Milan and the Flick brothers of Munich were leaders of prominent hostile-takeover attempts in recent years.

CASE

leverage on the balance sheet. Also had voiced the concerns and frustrations of stockholders. Heinz Klink (German), managing director for Distribution, age 49. Oversaw the transportation, warehousing, and order-fulfillment activities in the company. Spoilage, transport costs, stock-outs, and control systems were perennial challenges. Maarten Leyden (Dutch), managing director for Production and Purchasing, age 59. Managed production operations at the company’s 14 plants. Engineer by training. Tough negotiator, especially with unions and suppliers. A fanatic about production-cost control. Had voiced doubts about the sincerity of creditors’ and investors’ commitment to the firm. Marco Ponti (Italian), managing director for Sales, age 45. Oversaw the field sales force of 250 representatives and planned changes in geographical sales coverage. The most vocal proponent of rapid expansion on the senior-management committee. Saw several opportunities for ways to improve geographical positioning. Hired from Unilever to revitalize the sales organization, which he successfully accomplished. Fabienne Morin (French), managing director for Marketing, age 41. Responsible for marketing research, new-product development, advertising, and, in general, brand management. The primary advocate of the recent price war, which, although financially difficult, realized solid gains in market share. Perceived a “window of opportunity” for product and market expansion and tended to support growth-oriented projects. Nigel Humbolt (British), managing director for Strategic Planning, age 47. Hired two years previously from

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Replacement and expansion of the truck A new plant Expansion of a plant Development and introduction of new artificially sweetened yogurt and ice cream Plant automation and conveyor systems Effluent water treatment at four plants Market expansion eastward Market expansion southward Development and roll-out of snack foods Networked, computer-based inventory-control system for warehouses and field representatives Acquisition of a leading schnapps brand and associated facilities

a well-known consulting firm to set up a strategicplanning staff for Pan-Europa. Known for asking difficult and challenging questions about Pan-Europa’s core business, its maturity, and profitability. Supported initiatives aimed at growth and market share. Had presented the most aggressive proposals in 1992, none of which were accepted. Becoming frustrated with what he perceived to be his lack of influence in the organization. The Expenditure Proposals The forthcoming meeting would entertain the following proposals (see summary table also): 1. Replacement and expansion of the truck fleet. Heinz Klink proposed to purchase 100 new refrigerated tractor-trailer trucks, 50 this year and another 50 next year. By doing so, the company could sell 60 old, fully depreciated trucks over the two years for a total of €1.2 million. The purchase would expand the fleet by 40 trucks within two years. Each of the new trailers would be larger than the old trailers and afford a 15 percent increase in cubic meters of goods hauled on each trip. The new tractors would also be more fuel and maintenance efficient. The increase in number of trucks would permit more flexible scheduling and more efficient routing and servicing of the fleet than at present and would cut delivery times and, therefore, possibly inventories. It would also allow more frequent deliveries to the company’s major markets, which would reduce the loss of sales caused by stock-outs. Finally, expanding the fleet would support geographical expansion over the long term. As shown in Exhibit 3, the total net investment in trucks of € 20 million and the Expenditure (€ millions)

Project fleet

85

Sponsoring

Manager

22 30 10 15

Klink, Distribution Leyden, Production Ley den, Production Morin, Marketing

14 4 20 20 18 15

Leyden. Production Leyden, Production Ponti, Sales Ponti, Sales Morin, Marketing Klink, Distribution

40

Humbolt, Strategic Planning

23.75 6 5 11.3% 10.0% 1.3% 0.99 1.87 0.30

(30.00) 2.00 5.00 5.50 6.00 6.25 6.50 6.75 5.00 5.25 5.50

The effluent treatment program is not included in this exhibit.

7.70 6 4 7.8% 8.0% 0.2% 1.92 0.13 0.02

(11.40) (7.90) 3.00 3.50 4.00 4.50 5.00 7.00

25.00 5.00

7.25 6 5 11.2% 10.0% 1.2% 0.28 0.55 0.09

(10.00) 1.25 1.50 1.75 2.00 2.25 2.50 1.50 1.50 1.50 1.50

10.00

14.00

22.50 7 6 17.3% 12.0% 5.3% 5.21 3.88 0.69

(5.00) (5.00) (5.00) 3.00 3.00 4.00 4.50 5.00 5.50 6.00 6.50 5.25 6 4 8.7% 8.0% 0.7% 0.87 0.32 0.06

(14.00) 2.75 2.75 2.75 2.75 2.75 2.75 2.75

37.50 5 6 21.4% 12.0% 9.4% 11.99 9.90 1.75

(20.00) 3.50 4.00 4.50 5.00 5.50 6.00 6.50 7.00 7.50 8.00 32.50 6 6 18.8% 12.0% 6.8% 9.00 7.08 1.25

(20.00) 3.00 3.50 4.00 4.50 5.00 5.50 6.00 6.50 7.00 7.50

20.00 20.00 EXPECTED FREE CASH FLOWS (note 4)

15.00

28.50 5 6 20.5% 12.0% 8.5% 8.95 7.31 1.29

(18.00) 3.00 4.00 4.50 5.00 5.00 5.00 5.00 5.00 5.00 5.00

15.00 3.00

4.00 3 4 16.2% 8.0% 8.2% 1.16 1.78 0.69

(12.00) 5.50 5.50 5.00

15.00

134.00 5 6 28.7% 12.0% 16.7% 47.97 41.43 7.33

(15.00) (20.00) 5.00 9.00 11.00 13.00 15.00 17.00 19.00 21.00 59.00

30.00 10.00

Franchisees would gradually take over the burden of carrying receivables and inventory.

6

€15 million would be spent in the first year, 20 million in the second, and 5 million in the third.

Free cash flow incremental profit or cost savings after taxes depreciation investment in fixed assets and working capital.

5

This reflects €11 million spent both initially and at the end of year 1.

4

3

The equivalent annuity of a project is that level annual payment over 10 years that yields a net present value equal to the NPV at the minimum required rate of return for that project. Annuity corrects for differences in duration among various projects. For instance, project 5 lasts only 7 years and has an NPV of 0.32 million; a 10-year stream of annual cash flows of 0.05 million, discounted at 8.0 percent (the required rate of return) also yields an NPV of 0.32 million. In ranking projects on the basis of equivalent annuity, bigger annuities create more investor wealth than smaller annuities.

2

1

0 1 2 3 4 5 6 7 8 9 10

Year

20.00 2.00

Free Cash Flows and Analysis of Proposed Projects 1 (all values in € millions)

Undiscounted Sum Payback (years) Maximum Payback Accepted IRR Minimum Accepted ROR Spread NPV at Corp. WACC (10.5%) NPV at Minimum ROR Equivalent Annuity (note 2)

Investment Property Working Capital

EXHIBIT 3

86 CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

CASE

increase in working capital to support added maintenance, fuel, payroll, and inventories of € 2 million was expected to yield total cost savings and added sales potential of €7.7 million over the next seven years. The resulting IRR was estimated to be 7.8 percent, marginally below the minimum 8 percent required return on efficiency projects. Some of the managers wondered if this project would be more properly classified as “efficiency” than “expansion.” 2. A new plant. Maarten Leyden noted that PanEuropa’s yogurt and ice-cream sales in the southeastern region of the company’s market were about to exceed the capacity of its Melun, France, manufacturing and packaging plant. At present, some of the demand was being met by shipments from the company’s newest, most efficient facility, located in Strasbourg, France. Shipping costs over that distance were high, however, and some sales were undoubtedly being lost when the marketing effort could not be supported by delivery. Leyden proposed that a new manufacturing and packaging plant be built in Dijon, France, just at the current southern edge of Pan-Europa’s marketing region, to take the burden off the Melun and Strasbourg plants. The cost of this plant would be €25 million and would entail €5 million for working capital. The €14 million worth of equipment would be amortized over seven years, and the plant over ten years. Through an increase in sales and depreciation, and the decrease in delivery costs, the plant was expected to yield after-tax cash flows totaling €23.75 million and an IRR of 11.3 percent over the next ten years. This project would be classified as a market extension. 3. Expansion of a plant. In addition to the need for greater production capacity in Pan-Europa’s southeastern region, its Nuremberg, Germany, plant had reached full capacity. This situation made the scheduling of routine equipment maintenance difficult, which, in turn, created production-scheduling and deadline problems. This plant was one of two highly automated facilities that produced Pan-Europa’s entire line of bottled water, mineral water, and fruit juices. The Nuremberg plant supplied central and western Europe. (The other plant, near Copenhagen, Denmark, supplied Pan-Europa’s northern European markets.) The Nuremberg plant’s capacity could be expanded by 20 percent for €10 million. The equipment (€7 million) would be depreciated over seven years, and the plant over ten years. The increased capacity was expected to result in additional production of up to €1.5 million per year, yielding an IRR of 11.2 percent. This project would be classified as a market extension.

87

4. Development and introduction of new artificially sweetened yogurt and ice cream. Fabienne Morin noted that recent developments in the synthesis of artificial sweeteners were showing promise of significant cost savings to food and beverage producers as well as stimulating growing demand for low-calorie products. The challenge was to create the right flavor to complement or enhance the other ingredients. For ice-cream manufacturers, the difficulty lay in creating a balance that would result in the same flavor as was obtained when using natural sweeteners; artificial sweeteners might, of course, create a superior taste. €15 million would be needed to commercialize a yogurt line that had received promising results in laboratory tests. This cost included acquiring specialized production facilities, working capital, and the cost of the initial product introduction. The overall IRR was estimated to be 17.3 percent. Morin stressed that the proposal, although highly uncertain in terms of actual results, could be viewed as a means of protecting present market share, because other high-quality ice-cream producers carrying out the same research might introduce these products; if the Rolly brand did not carry an artificially sweetened line and its competitors did, the Rolly brand might suffer. Morin also noted the parallels between innovating with artificial sweeteners and the company’s past success in introducing low-fat products. This project would be classed in the new-product category of investments. 5. Plant automation and conveyor systems. Maarten Leyden also requested €14 million to increase automation of the production lines at six of the company’s older plants. The result would be improved throughput speed and reduced accidents, spillage, and production tie-ups. The last two plants the company had built included conveyer systems that eliminated the need for any heavy lifting by employees. The systems reduced the chance of injury to employees; at the six older plants, the company had sustained an average of 75 missed worker-days per year per plant in the last two years because of muscle injuries sustained in heavy lifting. At an average hourly wage of €14.00 per hour, over €150,000 per year was thus lost, and the possibility always existed of more serious injuries and lawsuits. Overall cost savings and depreciation totaling €2.75 million per year for the project were expected to yield an IRR of 8.7 percent. This project would be classed in the efficiency category. 6. Effluent water treatment at four plants. PanEuropa preprocessed a variety of fresh fruits at its Melun

88

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

and Strasbourg plants. One of the first stages of processing involved cleaning the fruit to remove dirt and pesticides. The dirty water was simply sent down the drain and into the Seine or Rhine rivers. Recent European Community directives called for any waste water containing even slight traces of poisonous chemicals to be treated at the sources and gave companies four years to comply. As an environmentally oriented project, this proposal fell outside the normal financial tests of project attractiveness. Leyden noted, however, that the water-treatment equipment could be purchased today for €4 million; he speculated that the same equipment would cost €10 million in four years when immediate conversion became mandatory. In the intervening time, the company would run the risks that European Community regulators would shorten the compliance time or that the company’s pollution record would become public and impair the image of the company in the eyes of the consumer. This project would be classed in the environmental category. 7. and 8. Market expansions eastward and southward. Marco Ponti recommended that the company expand its market eastward to include eastern Germany, Poland, Czechoslovakia, and Austria and/or southward to include southern France, Switzerland, Italy, and Spain. He believed the time was right to expand sales of ice cream, and perhaps yogurt, geographically. In theory, the company could sustain expansions in both directions simultaneously, but practically, Ponti doubted that the sales and distribution organizations could sustain both expansions at once. Each alternative geographical expansion had its benefits and risks. If the company expanded eastward, it could reach a large population with a great appetite for frozen dairy products, but it would also face more competition from local and regional ice cream manufacturers. Moreover, consumers in eastern Germany, Poland, and Czechoslovakia did not have the purchasing power that consumers did to the south. The eastward expansion would have to be supplied from plants in Nuremberg, Strasbourg, and Hamburg. Looking southward, the tables were turned: more purchasing power and less competition but also a smaller consumer appetite for ice cream and yogurt. A southward expansion would require building consumer demand for premium-quality yogurt and ice cream. If neither of the plant proposals (i.e., proposals 2 and 3) were accepted, then the southward expansion would need to be supplied from plants in Melun, Strasbourg, and Rouen. The initial cost of either proposal was €20 million of working capital. The bulk of this project’s costs was

expected to involve the financing of distributorships, but over the ten-year forecast period, the distributors would gradually take over the burden of carrying receivables and inventory. Both expansion proposals assumed the rental of suitable warehouse and distribution facilities. The after-tax cash flows were expected to total €37.5 million for eastward expansion and €32.5 million for southward expansion. Marco Ponti pointed out that eastward expansion meant a higher possible IRR but that moving southward was a less risky proposition. The projected IRRs were 21.4 percent and 18.8 percent for eastern and southern expansion, respectively. These projects would be classed in the new market category. 9. Development and roll-out of snack foods. Fabienne Morin suggested that the company use the excess capacity at its Antwerp spice- and nut-processing facility to produce a line of dried fruits to be test-marketed in Belgium, Britain, and the Netherlands. She noted the strength of the Rolly brand in those countries and the success of other food and beverage companies that had expanded into snack-food production. She argued that Pan-Europa’s reputation for wholesome, quality products would be enhanced by a line of dried fruits and that name association with the new product would probably even lead to increased sales of the company’s other products among health-conscious consumers. Equipment and working-capital investments were expected to total €15 million and €3 million, respectively, for this project. The equipment would be depreciated over seven years. Assuming the test market was successful, cash flows from the project would be able to support further plant expansions in other strategic locations. The IRR was expected to be 20.5 percent, well above the required return of 12 percent for newproduct projects. 10. Networked, computer-based inventory-control system for warehouses and field representatives. Heinz Klink had pressed for three years unsuccessfully for a state-of-the-art computer-based inventory-control system that would link field sales representatives, distributors, drivers, warehouses, and even possibly retailers. The benefits of such a system would be shortening delays in ordering and order processing, better control of inventory, reduction of spoilage, and faster recognition of changes in demand at the customer level. Klink was reluctant to quantify these benefits, because they could range between modest and quite large amounts. This year, for the first time, he presented a cash-flow forecast, however, that reflected an initial outlay of

QUESTIONS

€12 million for the system, followed by €3 million in the next year for ancillary equipment. The inflows reflected depreciation tax shields, tax credits, cost reductions in warehousing, and reduced inventory. He forecasted these benefits to last for only three years. Even so, the project’s IRR was estimated to be 16.2 percent. This project would be classed in the efficiency category of proposals. 11. Acquisition of a leading schnapps brand and associated facilities. Nigel Humbolt had advocated making diversifying acquisitions in an effort to move beyond the company’s mature core business but doing so in a way that exploited the company’s skills in brand management. He had explored six possible related industries, in the general field of consumer packaged goods, and determined that cordials and liqueurs offered unusual opportunities for real growth and, at the same time, market protection through branding. He had identified four small producers of well-established brands of liqueurs as acquisition candidates. Following

89

exploratory talks with each, he had determined that only one company could be purchased in the near future, namely, the leading private European manufacturer of schnapps, located in Munich. The proposal was expensive: €15 million to buy the company and €25 million to renovate the company’s facilities completely while simultaneously expanding distribution to new geographical markets.2 The expected returns were high: after-tax cash flows were projected to be €134 million, yielding an IRR of 28.7 percent. This project would be classed in the new-product category of proposals. Conclusion Each member of the management committee was expected to come to the meeting prepared to present and defend a proposal for the allocation of Pan-Europa’s capital budget of €80 million. Exhibit 3 summarizes the various projects in terms of their free cash flows and the investment-performance criteria.

QUESTIONS 1. Strategically, what must Pan-Europa do to keep from becoming the victim of a hostile takeover? What rows/ categories in Exhibit 2 will thus become critically important this coming year? What should Pan-Europa do now that they have won the price war? Who should lead the way for Pan-Europa? 2. Using NPV, conduct a straight financial analysis of the investment alternatives and rank the projects. Which NPV of the three should be used? Why? Suggest a way to evaluate the effluent project. 3. What aspects of the projects might invalidate the ranking you just derived? How should we correct for each investment’s time value of money, unequal lifetimes, riskiness, and size? 4. Reconsider the projects in terms of: • are any “must do” projects of the nonnumeric type? • what elements of the projects might imply greater or lesser riskiness?

might there be any synergies or conflicts between the projects? • do any of the projects have nonquantitative benefits or costs that should be considered in an evaluation? 5. Considering all the above, what screens/factors might you suggest to narrow down the set of most desirable projects? What criteria would you use to evaluate the projects on these various factors? Do any of the projects fail to pass these screens due to their extreme values on some of the factors? 6. Divide the projects into the four Project Profile Process categories of incremental, platform, breakthrough, and R&D. Draw an aggregate project plan and array the projects on the chart. 7. Based on all the above, which projects should the management committee recommend to the Board of Directors?

The following reading describes the approach Hewlett-Packard uses to select and monitor its projects for relevance to the firm’s strategic goals. The article describes the behavioral aspects of the process as well as many of the technical tools, such as the aggregate project plan, the plan of record, and the software aids they employed. In addition, the authors give tips and identify pitfalls in the process so anyone else implementing their approach will know what problems to watch out for. Exhibit 3 shows negative cash flows amounting to only €35 million. The difference between this amount and the €40 million requested is a positive operating cash flow of €5 million in year 1 expected from the normal course of business. 2

90

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

D I R E C T E D

R E A D I N G

FROM EXPERIENCE: LINKING PROJECTS TO STRATEGY* R. L. Englund and R. J. Graham Growth in organizations typically results from successful projects that generate new products, services, or procedures. Managers are increasingly concerned about getting better results from the projects under way in their organizations and in getting better cross-organizational cooperation. One of the most vocal complaints of project managers is that projects appear almost randomly. The projects seem unlinked to a coherent strategy, and people are unaware of the total number and scope of projects. As a result, people feel they are working at cross-purposes, on too many unneeded projects, and on too many projects generally. Selecting projects for their strategic emphasis helps resolve such feelings and is a corner anchor in putting together the pieces of a puzzle that create an environment for successful projects [6]. This article covers a series of steps for linking projects to strategy. These steps constitute a process that can be applied to any endeavor. Included throughout are suggestions for action as well as guidelines to navigate many pitfalls along the path. Process tools help illustrate ways to prioritize projects. The lessons learned are from consulting with many firms over a long time period and from personal experiences in applying the lessons within Hewlett-Packard Company (HP), a $40 billion plus company where two thirds of its revenue derives from products introduced within the past 2 years.

The Importance of Upper Management Teamwork Developing cooperation across an organization requires that upper managers take a systems approach to projects. That means they look at projects as a system of interrelated activities that combine to achieve a common goal. The common goal is to fulfill the overall strategy of the organization. Usually all projects draw from one resource pool, so they interrelate as they share the same resources. Thus, the system of projects is itself a project, with the smaller projects being the activities that lead to the larger project (organizational) goal. Any lack of upper management teamwork reverberates throughout the organization. If upper managers do not model desired behaviors, there is little hope that the rest of the organization can do it for them. Any lack of upper

management cooperation will surely be reflected in the behavior of project teams, and there is little chance that project managers alone can resolve the problems that arise. A council concept is one mechanism used at HP to establish a strategic direction for projects spanning organizational boundaries. A council may be permanent or temporary, assembled to solve strategic issues. As a result, a council typically will involve upper managers. Usually its role is to set directions, manage multiple projects or a set of projects, and aid in cross-organizational issue resolution. Several of these council-like activities become evident through the examples in this article. Employing a comprehensive and systematic approach illustrates the vast and important influence of upper management teamwork on project success. Increasingly evident are companies who initiate portfolio selection committees. We suggest that organizations begin by developing councils to work with project managers and to implement strategy. These councils exercise leadership by articulating a vision, discussing it with the project managers, asking them their concerns about and needs for implementing the strategy, listening carefully to them, and showing them respect so they become engaged in the process. In this way, upper managers and project managers develop the joint vision that is so necessary for implementation of strategy.

Process for Project Selection and Prioritization Once the upper management team is established, they can follow a process to select sets of projects that achieve organizational goals. They are then ideally positioned to implement consistent priorities across all departments. Figure 1 represents a mental model of a way to structure this process. Outputs from the four steps interrelate in a true systems approach. This model comes from experience in researching and applying a thorough approach to all the issues encountered in a complex organization. It is both simple in concept and complex in richness. The authors use the model both as an educational tool and to facilitate management teams through the process. What the Organization Should Do and How to Know When You Are Doing It. First, identify who is leading the

*Reprinted from Journal of Product Innovation Management with permission. Copyright Elsevier Science Publishers.

DIRECTED READING

91

Figure 1 A systematic approach to selecting projects. process and who should be on the management team. More time spent here putting together a “mission impossible” team pays dividends later by getting up-front involvement of the people who will be affected by the decisions that will be made. Take care not to overlook any key-but-not-so-visible players who later may speak up and jeopardize the plan. This team may consist solely of upper managers or may include project managers, a general manager, and possibly a customer. Include representation of those who can best address the key opportunities and risks facing the organization. Ideally they control the resources and are empowered to make decisions on all projects. The leader needs to get explicit commitment from all these people to participate actively in the process and to use the resulting plan when making related decisions. Be aware that behavioral issues become super urgent. This process hits close to home and may have a severe impact on projects that people care personally about. Uncertainty and doubt are created if management does not tread carefully and pay attention to people concerns. The team begins by listing all projects proposed and under way in the organization. Many times this step is a revelation in itself. A usual reaction is, “I didn’t realize we had so many projects going on.” The intent is to survey the field of work and begin the organizing effort, so avoid going into detailed discussion about specific projects at this point. The team clarifies or develops the goals expected from projects. Be careful not to get constrained through considering only current capabilities. Many teams get sidetracked by statements such as “We don’t know how to do that,” effectively curtailing discussion on whether the organization ought to pursue the goal and develop or acquire the capability. Rather, the discussions at this stage center around organizational purpose, vision, and mission. This is a crucial step that determines if the rest of the project selection process can be successful. In the authors’ experience, those organizations with clear, convincing, and compelling visions about what they should be doing move ahead rapidly. Any lack of understanding or commitment to the vision by a member

of the team leads to frustration, wheel spinning, and eventual disintegration of the whole process. This pattern is so prevalent that clarity of the goal or strategy is applied as a filter before agreeing to facilitate teams through the process. Organize the projects into categories that will later make it easier to facilitate a decision-making process. Wheelwright and Clark [14] suggest using grids where the axes are the extent of product change and the extent of process change. Some organizations use market segments. The benefit to this effort is that seeing all projects and possible projects on a continuum allows checking for completeness, gaps, opportunities, and compliance with strategy. This might also be a good time to encourage “out-of-the-box” thinking about new ways to organize the work. Use creative discussion sessions to capture ideas about core competences, competitive advantage, and the like to determine a set of categories most effective for the organization. For example, the categories might be: Evolutionary or derivative—sustaining, incremental, enhancing. Platform—next generation, highly leveraged; and Revolutionary or breakthrough—new core product, process, or business. The actual products in Figure 2 were introduced to the market over time in alphabetical order and positioning shown. Although the figure represents a retrospective view, it illustrates a successful strategy of sequencing projects and products. There is a balanced mix of breakthrough products, such as A, followed by enhancements, B through E, before moving on to new platforms, F through H, and eventually developing a new architecture and product family with L. At the time, this strategy was improvisational [1]; it now represents a learning opportunity for planning new portfolios. No one area of the grid is overpopulated, and where large projects exist there are not too many of them. Another reason to organize projects into these “strategic buckets” is to better realize what business(es) the organization is in. Almost every group the authors work with get

92

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

Figure 2 Bubble diagram of a product grid for one HP division. Size of bubble size of project. caught in the “tyranny of the OR” instead of embracing the “genius of the AND” [2]. In trying to do too many projects and facing the need to make tradeoffs among them, the decision becomes this OR that. In reality, most organizations need a balanced portfolio that creates complete solutions for their customers. They need to do this AND that. The way to achieve this goal is to set limits on the size of each category and then focus efforts on selecting the best set of projects within each category. The collective set of categories becomes the desired mix, a way of framing the work of the organization. The ideal percentage that constitutes the size of each category can be determined from the collective wisdom of the team or perhaps through experimentation. The organization can learn the right mix over time but only if it makes a concerted effort to do so. Within each category, determine criteria that can assess the “goodness”—quality or best fit—of choices for the plan. A criterion is a standard on which a comparative judgment or decision may be based. Because the types of projects and the objectives within categories may be quite different, develop unique criteria for each category or have a core set of criteria that can be modified. Many teams never get to the point of developing or clarifying criteria, and they usually want to discuss projects before agreeing on criteria; reversing the order is much more effective. Several works on research and development project selection [8, 9, 12] provide a robust set of criteria for consideration. Examples include strategic positioning, probability of success, market size, and availability of staff. Most important is to identify the criteria that are of greatest significance to the organization; fewer are better. However, teams usually need to brainstorm many criteria before focusing on the few. The role of each criterion is to help compare projects, not specify them. Select criteria that can measurably compare how projects support the organizational strategy. For example, one criterion may be degree of impact on HP business as interpreted by a general manager. On a scaling

model from 1 to 10, small impact scores a 2, strong a 6, critical to the success of one business an 8, and critical to the success of multiple businesses a 10. Most likely all proposed projects meet meaningful specifications and provide value to the organization. The task is to develop tough criteria to select the best of the best. Some organizations use narratives to describe how each project contributes to the vision; others use numerical scores on whether one project is equal, moderate, or strongly better than another. It is also helpful to set thresholds or limits for projects that will be considered for the plan. These help to screen out projects so that later prioritization efforts can focus on fewer projects. Writing a thorough description of each criterion helps ensure understanding of the intent and expectations of data that must be supplied to fulfill it. One team of three or four people at HP spent 5 days working only on the criteria they were to use for decision-making. And this was only the beginning; they next involved customers in the same discussion before reaching consensus and beginning to evaluate choices. An “Aha” occurred when people found they were wrong to assume that everyone meant the same thing by terms such as packaging; some used wider definitions than others did, and the misunderstanding only surfaced through group discussion. Asked if the selection process ever failed the team, its leader replied, “If the results didn’t make sense, it was usually because the criteria weren’t well defined.” Unfortunately, most teams do not exhibit the same patience and discipline that allowed this team to be successful. Before moving to the next step, the team should establish relative importance among criteria. Assign a weighting factor for each criterion. All criteria are important but some more so than others. The example in Figure 3 is the result of one team’s brainstorming session that ultimately led to selecting four criteria. Breakout groups subsequently defined each criterion with subcriteria. They also devised scoring methods to apply the criteria. Collectively they then determined the respective weighting or importance of each

DIRECTED READING

Customer Satisfaction (28%) • Improves service levels • Results in more consistent and accurate information/transactions • Helps ensure services are delivered as expected

Employee Satisfaction (7%) • Improves employee knowledge • Increases employee efficiency or effectiveness • Improves work/life balance promised • Positive impact to employee survey • Helps balance workload

Business Value (46%) • Achieves results that are critical for a specific window of opportunity • Minimizes risk for implementation and ongoing sustainability • Improves integration and relationships with partners • Provides a positive ROI in 2 yrs • Aligns with business goals

Process Effectiveness (19%) • Enables employees to do things right the first time • Increases the use of technology for service delivery • Reduces manual work and non-value added activities • Increases employee self-sufficiency

Figure 3

93

Sample criteria and weighting, plus subcriteria, developed by one HP team.

criterion (see the Process Tools section for how they did this). Unlike threshold criteria that “gate” whether a project is go or no-go, all projects have to satisfy selection criteria to some extent. Weighting of criteria is the technique that can optimize and determine the best of the best. Another “Aha” that helped teams get through the hurdle to develop effective criteria is when they realized the task at this point is “weighting, not gating.” It is the authors’ experience that criteria, while universally desired, are usually lacking or not formalized. One benefit of effective criteria is the shaping effect it has on behavior in the organization. When people know how projects will be scored, they tend to shape proposals in positive ways to meet the criteria better. A pitfall is when people play games to establish criteria that support personal agendas. Then it is up to the leader to identify and question these tactics. Remind people to support the greater good of the organization. Significant effort could be devoted to the behavioral aspects that become relevant when deciding upon criteria; suffice to say, be warned that this is a touchy area to approach with sensitivity and persuasiveness.

What the Organization Can Do. The next step for the team is to gather data on all projects. Use similar factors when describing each project in order to ease the evaluation process. Engage people in extensive analysis and debate to get agreement on the major characteristics for each project. This is a time to ask basic questions about product and project types and how they contribute to a diversified set of projects. Reexamine customer needs, future trends, commercial opportunities, and new markets. The person consolidating the data should challenge assertions about benefits

and costs instead of accepting assumptions that may have been put together casually. It is important for each member of the team to assess the quality of the data, looking closely at sources and the techniques for gathering the data. When putting cost figures together, consider using activity-based costing models instead of traditional models based on parts, direct labor, and overhead. Activity-based costing includes the communications, relationship building, and indirect labor costs that usually are required to make a project successful. The team needs to constantly apply screening criteria to reduce the number of projects that will be analyzed in detail. Identify existing projects that can be canceled, downscaled, or reconceived because their resource consumption exceeds initial expectations, costs of materials are higher than expected, or a competitive entry to the market changed the rules of the game. The screening process helps eliminate projects that require extensive resources but are not justified by current business strategies; maybe the projects were conceived based on old paradigms about the business. The team can save discussion time by identifying must-do projects or ones that require simple go/no-go decisions, such as legal, personnel, or environmental projects. These fall right through the screens and into the allocation process. Determine if some projects can be postponed until others are complete or until new resources or funding become available. Can project deliverables be obtained from a supplier or subcontractor rather than internally? Involve customers in discussions. The team constantly tests project proposals for alignment with organizational goals. It is not necessary to constrain the process by using the same criteria across all categories of projects. In fact,

94

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

some teams found that different criteria for each category of projects was more effective. Also, consider adjusting the weighting of criteria as projects move through their life cycles. Kumar et al. [7] documented research showing that the most significant variable for initial screening of projects is the extent to which “project objectives fit the organization’s global corporate philosophy and strategy.” Other factors, such as available science and technology, become significant later during the commercial evaluation stage. A big “Aha” experienced by some teams when confronted with this data is that they usually did it the other way around. That explains why they got into trouble—by focusing on technology or financial factors before determining the link to strategic goals. Cooper (and others before him) report that top-performing companies do not use financial methods for portfolio planning. Rather, they use strategic portfolio management methods where strategy decides project selection [3]. This lesson is still a hotly debated one, especially for those who cling to net present value as the single most important criterion. The difficulty lies in relying upon forecast numbers that are inherently fictitious. The authors’ experience is that teams get much better results tapping their collective wisdom about the merits of each project based upon tangible assessments against strategic goals. Using computed financial numbers more often leads to arguments about computation methods and reliability of the data, resulting in unproductive team dynamics. The next part of gathering data is to estimate the time and resources required for each potential and existing project. Get the data from past projects, statistical projections, or simulations. The HP Project Management Initiative particularly stresses in its organizational initiatives to get accurate bottom-up project data from work breakdown structures and schedules. Reconcile this data with top-down project goals. Document assumptions so that resource requirements can be revisited if there are changes to the basis for an assumption. For new or unknown projects, make a best estimate, focusing first on the investigation phase with the intent to fund only enough work to determine feasibility. The team can revisit the estimates when more information becomes available. Constantly improve estimation accuracy over time by tracking actuals with estimated task durations. Next, the team identifies the resource capacity both within and outside the organization that will be available to do projects. Balance project with nonproject work by using realistic numbers for resource availability, taking into account other projects, vacations, meetings, personal appointments, and other interruptions. Tip: a wise planner consumes no more than about 50% of a person’s available time. One assessment about the quality of projects in a portfolio is to look at the rejects. In a story attributed to HP founder Bill Hewlett, he once established a single metric for how he would evaluate a portfolio manager’s performance. He asked to see only the rejects. He reasoned that if

the rejects looked good, then the projects that were accepted must be excellent. All the actions in this step of the process are intended to screen many possible projects to find the critical few. The team may take a path through multiple screens or take multiple passes through screens with different criteria to come up with a short list of viable projects. Figure 4 represents one scenario where Screen 1 is a coarse screen that checks for impact on the strategic goal. Subsequent screens apply other criteria when more data are available. Any number of screens may be applied, up to the number n, until the team is satisfied that the remaining projects relate to compelling business needs. These steps actually save time because the next section on analysis can get quite extensive if all possible projects go through it. It usually is necessary to go through several validation cycles before finishing the next step: the upper management team proposes project objectives, project teams provide preliminary estimates based on scope, schedule, and resources back to management, management is not happy with this response and makes adjustments, and so on. This exercise in due diligence is a healthy negotiation process that results in more realistic projects getting through the funnel.

Analyze and Decide on Projects. The next step is to compare estimated resource requirements with available resources. A spreadsheet is useful to depict allocation of resources according to project priority. Part of the analysis is qualitative: Consider the opportunity costs of committing to short-term, opportunistic, or poorly conceived projects that take resources away from

Figure 4 Application of criteria screens during a funneling process eliminates the trivial many projects from the critical few that the organization can realistically complete.

DIRECTED READING

future prospects that may be a better fit strategically. Also, avoid selecting “glamorous” new ideas over addressing the tough issues from ongoing projects. Some people lack the stamina to deal with the details of implementation and so are ready to jump to a new solution at the slightest glimmer of hope from the latest technology. This is a recipe for disaster. Also, be careful to balance the important projects rather than giving in to urgent, but not so important, demands. Documenting all the findings and supportive data using a common set of descriptive factors makes it easier to compare similar factors across projects. Use a “project charter” form or a template where all information about each project, its sponsors, and key characteristics is recorded. The team can now prioritize the remaining projects. Focus on project benefits before costs; that way the merits of each project get full consideration. Later include costs to determine the greatest value for the money. Compute overall return from the set of projects, not from individual projects, because some projects may have greater strategic than monetary value. Requiring each and every project to promise a high financial return actually diminishes cooperation across an organization. Also, optimize return over time and continuity or uniformity of revenue from the projects. Some future projects must be funded early to ensure a revenue stream when current projects taper off. Using previously agreed-upon criteria and weighting factors, the team compares each project with every other one within a category. Repeat the process for each criterion. See the discussion and example later in this article about using an analytical hierarchy process (AHP) to facilitate this step. Consider using software to compute results—an ordered list of projects within each category. A pitfall to avoid that engenders fear among the team is showing one list that prioritizes all projects from top to bottom. People get concerned when their project is on the line. It is not fair to compare internal development projects with high grossing products; keep them separated and within their respective categories. Finally, the team is ready to decide which projects to pursue. Be prepared to do fewer projects and to commit complete resources required by projects that are selected. Decide on a mix of projects consistent with business strategy, such as 50% platform projects, 20% derivative projects, 10% breakthrough projects, and 10% partnerships. Note that these total only 90%; taking some lessons from financial portfolio management, diversify the set of projects by investing in some speculative projects. The team may not be sure which markets or technologies will grow, so buy an “option” and make a small investment to investigate the possibilities. Include experimental projects. It is also important to leave a small percent of development capacity uncommitted to take advantage of unexpected opportunities and to deal with crises when they arise.

95

Wheelwright and Clark [14] cite an organization that reduced the number of its development projects from 30 to 11: “The changes led to some impressive gains . . . as commercial development productivity improved by a factor of three. Fewer products meant more actual work got done, and more work meant more products.” Addressing an internal project management conference, an HP Executive Vice President emphasized the need to focus on doing fewer projects, especially those that are large and complex: “We have to be very selective. You can manage cross-organizational complex programs if you don’t have very many. If you have a lot of them with our culture, it just won’t work. First of all, we need to pick those opportunities very, very selectively. We need to then manage them aggressively across the company. That means have joint teams work together, strong project management and leadership, constant reviews, a framework, a vision, a strong owner—all those things that make a program and project successful.” Subsequently, a number of organizations sought help from the HP Project Management Initiative to systematically reduce 120 projects down to 30. Another organization went from 50 projects down to 17. It appears counter-intuitive, but by prioritizing and more carefully selecting projects, organizations actually get more projects completed. Figure 5 illustrates a document that captures the output of this process. Record projects that are fully funded in an aggregate project plan (in-plan). In a separate section or another document, list projects for future consideration (out-plan); also capture and communicate reasons for delaying or not funding projects. The plan of record (POR) is both a process and a tool used by some organizations at HP to keep track of the total list of projects. It lists all projects under way or under consideration by the entity. If a project is funded and has resources assigned, it has achieved in-plan status. Projects below the cutoff line of available resources or that have not yet achieved priority status are on the out-plan. The figure also categorizes the projects and specifies the desired mix. Project managers at HP describe one benefit of the POR process as identifying gaps between required and actual resources. For flexible changes, the process gets all people into the communications loop. If people want to add something, the management team has to decide what should be deleted. The process helps two divisions that work together agree on one prioritized list instead of two. They utilize direct electronic connections for bottom-up entry of projects and resources by all project managers into a centralized administration point.

Implement the Plan. No job is complete until it is acted upon. The team needs to “evangelize” all others in the organization to use the aggregate project plan or POR to guide people who plan work, make decisions, and execute projects. Although it may be countercultural to do so, do not starve

Figure 5

An example plan of record showing the mix of projects in priority order and the time line for each project.

96 CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

DIRECTED READING

committed projects of the resources they need. The team or the responsible upper managers need to enforce the plan by fully staffing committed projects; that now becomes possible because fewer projects are happening simultaneously. Also, use the plan to identify opportunities for leverage across projects or for process reengineering. Match people skills to project categories to tap their strengths and areas for contribution. The team or a program management office needs to maintain the plan in a central place, such as a project office or online. Make it known to, and accessible by, all people in the organization doing projects, subject to confidentiality requirements. All the work to this point may go for naught if the process, the steps, and the results are not widely communicated. The same people who develop the plan are also the ones who can best update it periodically, perhaps quarterly or as changes occur. Use tools such as an online shared database to gather data directly from project managers about resources needed for each project. This system can be used both to gather data when developing the plan and to update it. View the plan as a “living document” that accurately reflects current realities. The challenge for HP and many companies is to “master both adaptive innovation and consistent execution . . . again and again and again . . . in the context of relentless change. . . . Staying on top means remaining poised on the edges of chaos and time . . . These edges are places of adaptive behavior. They are also unstable. This instability means that managers have to work at staying on the edge” [1]. The advice is clear: the plan is indispensable as a strategic guideline, but don’t fall in love with it! Be prepared to adapt it and to communicate the changes.

Process Tools One tool that can assist in the decision-making process is the AHP [10]. Because of the interactions among many factors affecting a complex decision, it is essential to identify the important factors and the degree that they affect each other before a clear decision can be made. The AHP helps structure a complex situation, identify its criteria and other intangible or concrete factors, measure the interactions among them in a simple way, and synthesize all the information to obtain priorities. The priorities then can be used in a benefit-to-cost determination to decide which projects to select. The AHP organizes feelings and intuition alongside logic in a structured approach to decision-making—helpful in complex situations where it is difficult to comprehend multiple variables together. An individual or team focuses on one criterion at a time and applies it step by step across alternatives. A number of sites across HP find value in using AHP. In another example, a team got together to choose among a set of services they will offer to customers. More choices were available than the organization had capacity to support. After defining organizational strategy or product

97

goals, the first task was to identify which criteria to enter into the decision-making process. After give-and-take discussion, they decided that the criteria were customer satisfaction, business value, process effectiveness, and employee satisfaction. Next, the criteria were ranked according to priority by making pairwise comparisons between them. Which is the more desirable criterion and by how much, customer satisfaction or business value? Process effectiveness or employee satisfaction? Business value or process effectiveness? These questions were asked about all possible pairs. Each potential project or service then was scored underneath each criterion, and decisions were made about which projects to include in the portfolio, based upon existing resources. This team went on to create a POR similar to Figure 5. A detailed explanation for computing the priority scores and the final rank ordering list can be quite complex, involving eigenvalues and eigenvectors, so it is much easier to get a software package (Expert Choice [4]) that does the computations. As an alternative, a spreadsheet could be constructed to normalize the numbers. This process appears complex and analytical but is easy when the software handles the computations, and the management team concentrates on the comparisons. It is thorough in guiding the team to consider all criteria, both emotional and logical, and to apply them to all projects. One team rejected the process as too analytical, so be aware that it does not work for everyone. The key benefit in doing this process is the improved quality of dialogue that occurs among the management team members. In facilitating a number of teams at HP through this process, each one achieved far more progress than they thought possible. People admit that they become addicted to the AHP process. They immediately buy the software. The systematic approach is feasible whether selecting products for a product line, projects that comprise a portfolio, or the best supplier or candidate for a job. In reality, the discussions are more valuable than the analysis. The process in this case provides the discipline that makes the dialogue happen. Frame [5] offers an alternative “poor man’s hierarchy.” He puts selection criteria along the side as well as across the top of a grid. If the criterion on the side is preferred to the one on the top, put a 1 in the cell. If the criterion on top is preferred, put a 0 in the cell. Diagonals are blanked out where criteria would be compared to themselves. Below the diagonal, put the opposite value from corresponding cells above the diagonal. Then add up the numbers across the rows to get total scores, which provide a rank order. One team at HP modified this process to replace the 1s and 0s with an actual count of how 18 people voted in each pairwise comparison of alternatives. Again, they added up the rows and normalized the results for a priority order and weighted ranking (Figure 6).

98

CHAPTER 2 / STRATEGIC MANAGEMENT AND PROJECT SELECTION

Total Votes

%

50

46

15

30

28

***

14

21

19

4

***

7

7

Business

Customer

Technology

Employee

Business

***

16

16

18

Customer

2

***

13

Technology

2

5

Employee

3

Figure 6

A simplified hierarchy used by one HP team to weight criteria.

This simplified hierarchy is especially helpful for weighting criteria. It can be used for prioritizing projects when applied to one criterion at a time. It becomes bulky and less useful when applied to multiple projects over multiple criteria.

Barriers to Implementation Now for a reality check. The model depicted in this article is thorough, and it integrates objective and subjective data. When all is said and done, however, people may throw out the results and make a different decision. Sometimes the reason is a hunch, an instinct, or simply a desire to try something different. Sometimes people have a pet project and use the process to justify its existence, or a hidden agenda may be at play—perhaps the need to maneuver among colleagues, trading projects for favors. Politics at this stage cannot be ignored, nor are they likely to disappear. It is imperative for leaders to become skilled in the political process. Any attempt at leading change in how an organization links projects to strategy is bound to meet resistance. The concept receives almost unanimous intellectual support. Implementing it into the heart and soul of all people in the organization is another story. It goes against the cultural norms in many organizations and conjures up all kinds of resistance if the values it espouses are not the norm in that organization. The path is full of pitfalls, especially if information is presented carelessly or perceived as final when it is work in process. Some people resist because the process is too analytical. Some want decision-making to be purely interactive, intuitive, or the purview of a few people. A complete process cannot be forced upon people if the organization has more immediate concerns or unresolved issues. Resistance occurs when there is no strategy, the strategy is unclear, or people are uncomfortable with the strategy. Work on the process may come to a standstill when people realize how much work is involved to fully link projects to strategy. If the pain is not great enough with the status quo, people are not going to be ready to change.

And if people sense that the leader does not authentically believe in the elements, such as the goals, the process, or the tools, they are hesitant to follow with any enthusiasm. When the leader lacks integrity and exhibits incongruity between words and actions, people may go through the motions but do not exert an effort that achieves meaningful results.

Enablers for Effective Implementation It is possible to lead people through this change process if the leader asks many questions, listens to the concerns of all people involved, and seeks to build support so that people feel they have an active role in developing the process [9]. A flexible process works better than a rigid one. Cultivate “champions” who have the credibility and fortitude to carry the process across the organization. Believe that change is possible. When the effort appears too massive, one approach is to go after the low-hanging fruit. Start with one of the more pressing issues and use the general concepts of this model to address it. Still have a vision for what the organization ultimately can achieve but understand that patience and pacing are necessary to get there. Consider also that this process is hierarchical—it can be applied singularly or collectively, up or down the organization. For people who get frustrated when all linkages are not present, the authors urge teams and individuals to “just do it.” Small changes in initial conditions have enormous consequences. Eventually successes or small wins are noticed. The practices start to permeate an organization. This can happen in the middle, move up, and then over to other organizations. Incidentally, a corporate group like HP’s Project Management Initiative helps facilitate this transformation. We do this by acting as a conduit for success stories and best practices. Over the long run, we believe that organizations that follow a process similar to the one described increase their odds for greater success. This happens because teams of people following a systematic process and using convincing

DIRECTED READING

data to support their arguments more often produce better results than individuals. Their projects have more visibility, and the quality of dialogue and decision-making improve. The power of using criteria that are tightly linked with strategy and known by everyone in the organization is the mitigating effect it has to guide behavior in constructive ways. Having a process means it can be replicated and improved over time until it is optimized. It also means other people can learn the process and coach others, thereby creating a learning organization. References 1. Brown, S. L., and K. M. Eisenhardt. Competing on the Edge: Strategy as Structured Chaos. Boston: Harvard Business School Press, 1998. 2. Collins, J. C. and J. I. Porras. Built to Last: Successful Habits of Visionary Companies. New York: HarperCollins, 1994. 3. Cooper, R. G., S. J. Edgett, and E. J. Kleinschmidt. Portfolio Management for New Products. Reading, MA: Addison-Wesley, 1998. 4. “Expert Choice,” Pittsburgh, PA: Expert Choice Inc. (see www.expertchoice.com). 5. Frame, J. D. The New Project Management: Tools for an Age of Rapid Change, Corporate Reengineering, and Other Business Realities. San Francisco: JosseyBass Publishers, 1994. 6. Graham, Robert J. and Randall L. Englund. Creating an Environment for Successful Projects: The Quest to Manage Project Management. San Francisco: JosseyBass Publishers, 1997. 7. Kumar, V., et al. “To Terminate or Not an Ongoing R&D Project: A Managerial Dilemma.” IEEE Transactions on Engineering Management 279 (1996). 8. Martino, J. R & D Project Selection. New York: Wiley, 1995. 9. O’Toole, J. Leading Change: Overcoming the Ideology of Comfort and the Tyranny of Custom. San Francisco: Jossey-Bass Publishers, 1995.

99

10. Saaty, T. L. Decision Making for Leaders. Pittsburgh, PA: RWS, 1990. 11. Stacey, R. D. Managing the Unknowable: Strategic Boundaries Between Order and Chaos in Organizations. San Francisco: Jossey-Bass Publishers, 1992, p. 62. 12. Turtle, Q. C. Implementing Concurrent Project Management. Englewood Cliffs, NJ: Prentice Hall, 1994. 13. Westney, R. E. Computerized Management of Multiple Small Projects. New York: Dekker, 1992. 14. Wheelwright, S., and K. Clark. “Creating Project Plans to Focus Product Development.” Harvard Business Review, March–April (1992).

Questions 1. Why are successful projects so important to HewlettPackard? 2. How far should an evaluation team go in trying to quantify project contributions to the firm’s mission or goals? What is the role of financial selection criteria in HP’s project selection process? 3. Considerable attention is paid to the measures HP uses to evaluate its projects. Is the aim of carefully defining these measures to simplify the project selection process or something else? 4. What do the aggregate project plan and the plan of record illustrate to upper management? 5. When should out-plan projects be reconsidered for inclusion? 6. What was your impression of the impact that HP’s project selection process had on the number of projects underway? How do you expect HP would score on project management maturity? 7. How did the new project selection process handle nonnumeric type projects? Risk? How did this new process alter new project proposals at HP?

This page intentionally left blank

C

H

A

P

T

E

R

3 The Project Manager

PMBOK Guide 1.6, 4.3, 9

Chapters 3 and 4 discuss topics relevant to PMBOK knowledge area 6, Human Resource Management. In the last chapter, we described how projects are evaluated and selected for development. Before more progress can be made, a project manager (PM) must be appointed. Not only is the appointment of a PM (the project “leader”) important to initiate any project, but the PM is probably the major resource input to the project compared to the team, the capital, the materials, and any other inputs—hence our extensive discussion here. As the leader, this person will take responsibility for planning, implementing, and completing the project, beginning with the job of getting things started. Actually, the way to get things started is to hold a meeting. We will delay discussion of the initial project meeting, however, until Chapter 5 because it is the first step in the process of planning the project.

DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.

The PM can be chosen and installed as soon as the project is selected for funding or at any earlier point that seems desirable to senior management. If the PM is appointed prior to project selection or if the PM originated the project, several of the usual start-up tasks are simplified. On occasion, a PM is chosen late in the project life cycle, usually to replace another PM who is leaving the project for other work. For example, a large agricultural products firm regularly uses a senior scientist as PM until the project’s technical problems are solved and the product has been tested. Then it replaces the scientist with a middle manager from the marketing side of the firm as marketing becomes the focal point of the project. (The transition is difficult and, according to firm spokespeople, the results are sometimes unsatisfactory.)

101

102

CHAPTER 3 / THE PROJECT MANAGER

Usually, a senior manager briefs the PM on the project so that the PM can understand where it fits in the general scheme of things in the parent organization, and its priority relative to other projects in the system and to the routine work of the organization. The PM’s first set of tasks is typically to prepare a preliminary budget and schedule, to help select people to serve on the project team, to get to know the client (either internal or external), to make sure that the proper facilities are available, to ensure that any supplies required early in the project life are available when needed, and to take care of the routine details necessary to get the project moving. As people are added to the project, plans and schedules are refined. The details of managing the project through its entire life cycle are spelled out, even to the point of planning for project termination when the work is finally completed. Mechanisms are developed to facilitate communication between the PM and top management, the functional areas, and the client. As plans develop still further, the PM holds meetings and briefings to ensure that all those who will affect or be affected by the project are prepared in advance for the demands they will have to meet as the project is implemented. In this chapter we discuss the unique nature of project management and some of the ways project management differs from functional management. Our emphasis is on the role and responsibilities of the PM. We concentrate on the demands placed on the PM, particularly on those unique to project management. For example, consider the differences in the challenges faced by the project manager who must add a security/privacy segment in a software program and those faced by the PM who must design and implement a global database for an international chemical firm. We then identify the skills required by the project manager and link them to the nature of the task faced by the PM. It is best to describe the PM’s job relative to some assumptions about the nature of projects and the organization within which the project must function. We assume that the parent firm is functionally organized and is conducting many projects simultaneously with its ongoing, routine operations. We also assume a fairly large firm, a project that has some technical components, with an output to be delivered to an “arms-length” customer. Clearly, not all, and possibly even not most, projects operate under these circumstances, but these are the most demanding and we address the most difficult problems a PM might have to face. Smaller, simpler projects may not require the tools we will present here, but the PM for these projects should be aware that such tools exist. Thus far, we have had in mind a PM with reasonably normal skills, and operating under reasonably normal circumstances. In the last sections of this chapter, we will discuss a major complication for project managers—managing a project being carried out in a multicultural environment. We emphasize the word multicultural, a word that is not synonymous with (but includes) projects whose member organizations and geographical locations may transcend national boundaries. In fact, it is not the differences in national boundaries that matter; it is differences in cultures. Moreover, it is not merely the differences in cultures that matter, it is also differences between the environments within which the projects are conducted— economic, political, legal, and sociotechnical environments. In this chapter, two conditions receive special attention. Both have a profound effect on the outcome of the project, and neither is under the complete control of the PM—though the PM can greatly influence both by dealing with the conditions early in the project life. The first of these concerns the degree to which the project has the support of top management. If that support is strong and reasonably unqualified, the project has a much better chance of success (Pinto et al., 1989; Zimmerer et al., 1998). The second condition concerns the general orientation of the project team members. If they are highly oriented toward their individual, functional disciplines, as opposed to the project itself, project success is threatened. If, on the other hand, they are oriented toward

3.1 PROJECT MANAGEMENT AND THE PROJECT MANAGER

103

the project (that is, problem oriented rather than discipline oriented), the likelihood of success is much greater. As Thomas Hughes (1998) writes about the SAGE and Atlas projects: “Teams of engineers, technicians, and scientists polarized around problems rather than disciplines. As a result, new discipline-transcending organizational forms . . . presided over system-building projects rather than discipline-bound departments. The transdisciplinary team approach is still considered front-edge management almost half a century later.”

3.1

PROJECT MANAGEMENT AND THE PROJECT MANAGER

The Functional Manager versus the Project Manager The best way to explain the unique role of the PM is to contrast it with that of a functional manager in charge of one of a firm’s functional departments such as marketing, engineering, or finance (see Figure 3-1). Such department heads are usually specialists in the areas they manage. Being specialists, they are analytically oriented and they know something of the details of each operation for which they are responsible. When a technically difficult task is required of their departments, they know how to analyze and attack it. As functional managers, they are administratively responsible for deciding how something will be done, who will do it, and what resources will be devoted to accomplish the task. A PM generally starts his or her career as a specialist in some field who is blithely informed by a senior manager that he or she is being promoted to the position of Project Manager on the Whizbang Project. The PM must now metamorphose from technical caterpillar into generalist butterfly. (For an excellent set of instructions for the transformation, see Matson (1998).) The PM, new or experienced, must oversee many functional areas, each with its own specialists (see Figure 3-2). Therefore, what is required is an ability to put many pieces of a task together to form a coherent whole—that is, the project manager should be more skilled at synthesis, whereas the functional manager should be more skilled at analysis. The functional manager uses the analytic approach and the PM uses the systems approach. The analytic method focuses on breaking the components of a system into smaller and smaller elements. We are not saying that this is wrong, it is merely inadequate for understanding a complex system. Regardless of the dissector’s skill or the degree to which, say, a frog is dissected, the dissection allows only a partial understanding of the total animal “frog.” The

Vice-president marketing

Agency director

Sales

Marketing research

Marketing services

Group administration

Figure 3-1 Functional management organization chart: marketing department of an insurance company.

Project manager

Finance

Figure 3-2

Engineering

Contracts

Planning

Manufacturing

Procurement

Quality

Project management organization showing typical responsibilities of a project manager.

104

CHAPTER 3 / THE PROJECT MANAGER

systems approach maintains that to understand a component, we must understand the system of which the component is a part. And to understand the system, we must understand the environment (or larger system) of which it is a part. Adoption of the systems approach is crucial for the project manager. Consider, if you will, the problem of managing a project devoted to the development of software that will create and maintain a database, and to undertake this task without knowing anything about the decision support system in which the database will be used, or the operating system of the computers that will contain the DSS, or the purposes for which the information in the database will be used, and so forth. Our comparison between the PM and the functional manager reveals another crucial difference between the two. The functional manager is a direct, technical supervisor. The project manager is a facilitator and generalist. These simple statements, while true, are misleading. Both require specialized technical knowledge. The functional manager’s knowledge must be in the technology of the process being managed. The PM should be competent in the science of project management (Sahlin, 1998; Zimmerer et al., 1998), but this is not sufficient. In our opinion, there is strong evidence that the PM should be both generalist and facilitator and have a reasonably high level of technical competence in the science of the project. Three major questions face PMs in their task of synthesis: What needs to be done, when must it be done (if the project is not to be late), and how are the resources required to do the job to be obtained? In spite of the fact that the PM is responsible for the project, the functional managers will probably make some of the fundamental and critical project decisions. For example, they usually select the people who will actually do the work required to carry out the project. They may also develop the technological design detailing how some tasks will be accomplished. And they frequently influence the precise deployment of the project’s resources. This separation of powers between functional and project managers, which may aid in the successful completion of the project, is also a source of considerable “discomfort” for both. Note here that the PM is responsible for organizing, staffing, budgeting, directing, planning, and controlling the project. In other words, the PM “manages” it, but the functional managers may affect the choice of technology to be used by the project and the specific individuals who will do the work. (It is not uncommon, however, for the PM to negotiate with functional managers about the assignment of special individuals to carry out certain project work.) Arguments about the logic or illogic of such an arrangement will fall on deaf ears. The PM cannot allow the functional manager to usurp control of the project. If this happens, work on the project is likely to become secondary to the work of the functional group and the project will suffer. But the functional manager cannot allow the PM to take over authority for technical decisions in the functional area or to control the assignment of functional area personnel. At times, a senior manager (often the PM’s immediate superior) will, in effect, take over the PM’s job by exercising extremely close supervision over every action the PM takes, or will actually tell the PM precisely what to do. All of the powers normally delegated to the PM are withdrawn and the PM’s boss runs the project. This condition is known as micromanagement. It stamps out any creativity or initiative from the PM or project workers, frustrates almost everyone connected with the project, and generally ensures mediocre performance, if not failure. To be frank, we do not know how to cure or prevent micromanagement. It is practiced by individuals who have so little trust in their co-workers that they must control everything. Our considered advice to PMs who are micromanaged is to request a transfer. At the other end of the spectrum, the relationship between the PM, the functional managers, the project team, and the PM’s superior may be characterized as “collegial,” and the organization may be populated by talented people. In such organizations conflict is minimized, cooperation is the norm, no one is terribly concerned with who gets the credit, and the likelihood of success is high. We will have more to say later in this chapter and in other chapters about building and maintaining teams. Effective teams tend to operate in a collegial

3.1 PROJECT MANAGEMENT AND THE PROJECT MANAGER

105

mode. It is worth noting, however, that collegiality without talent leads to failure—even if the project team smiles a lot while failing.

The Project Manager’s Responsibilities The PM’s responsibilities are broad and fall primarily into three separate areas: responsibility to the parent organization, responsibility to the project and the client, and responsibility to the members of the project team. Responsibilities to the firm itself include proper conservation of resources, timely and accurate project communications, and the careful, competent management of the project. It is very important to keep senior management of the parent organization fully informed about the project’s status, cost, timing, and prospects. Senior managers should be warned about likely future problems. The PM should note the chances of running over budget or being late, as well as methods available to reduce the likelihood of these dread events. Reports must be accurate and timely if the PM is to maintain credibility, protect the parent firm from high risk, and allow senior management to intercede where needed. Above all, the PM must never allow senior management to be surprised! The PM’s responsibility to the project and client is met by ensuring that the integrity of the project is preserved in spite of the conflicting demands made by the many parties who have legitimate interests in the project. The manager must deal with the engineering department when it resists a change advised by marketing, which is responding to a suggestion that emanated from the client. In the meantime, contract administration says the client has no right to request changes without the submission of a formal Request for Change order. Manufacturing says that the argument is irrelevant because marketing’s suggestion cannot be incorporated into the project without a complete redesign. The PM is in the middle of this turmoil. The PM must sort out understanding from misunderstanding, soothe ruffled feathers, balance petty rivalries, and cater to the demands of the client. One should, of course, remember that none of these strenuous activities relieves the PM of the responsibility of keeping the project on time, within budget, and up to specifications. In Chapter 5 it will become evident that it is very common for the PM to have no direct subordinates in spite of the fact that several, perhaps many, people “work for him/her” on the project. These people form what we have been referring to as the “project team.” In spite of the strange circumstance where people are said to work for someone who is not their boss, the PM’s relationship to the team may be considerably closer than one might expect, particularly when individuals are assigned to spend much or all of their time working on the project. The project manager’s responsibilities to members of the project team are dictated by the finite nature of the project itself and the specialized nature of the team. Because the project is, by definition, a temporary entity and must come to an end, the PM must be concerned with the future of the people who serve on the team. If the PM does not get involved in helping project workers with the transition back to their functional homes or to new projects, then as the project nears completion, project workers will pay more and more attention to protecting their own future careers and less to completing the project on time. One final note on this subject. If we have made the process of project management seem orderly and rational, we apologize. If any single descriptor could be used to characterize project management, the adjective would be “messy.” In an excellent article that should be read by anyone interested in understanding the reality of management, Kotter (1982) has shown that general managers are less organized, less formal, and less structured than college students are led to believe. The same is undoubtedly true of project managers. This fundamental lack of organization and structure makes it all the more important that PMs implement good planning and organizational skills where possible, or the chaos becomes unmanageable.

106

CHAPTER 3 / THE PROJECT MANAGER

PM Career Paths

PMBOK Guide

Many firms have a wide variety of types and sizes of projects in progress simultaneously. Of these, it is typical to find that many are not large enough or sufficiently complex to require a full-time manager. Quite a few project managers are in charge of several projects simultaneously. The firm may be planning and building a new factory (three years), undertaking several dozen R & D projects (one to seven years), improving the landscape surrounding its factory in Mussent Point (two months), considering the acquisition of another firm (six months), upgrading the equipment in its thiotimolene plant (two years), buying art works produced by artists in each city in which the firm operates for display in corporate offices (one year), planning the annual stockholders’ meeting (three months), and doing a large number of other things, many of which are organized as projects. Who manages these projects? Where does the company find people competent to manage such a wide variety of projects? In Chapter 1, we referred to the professionalization and rapid growth of project management, to PMBOK (the project management body of knowledge), as well as to the development of college and university-level courses and degree programs available in the field. Although the percentage of PMs who are academically trained is increasing rapidly, many current project managers have no college-level training in the field. A rapidly growing number of private consulting firms offer instruction in project management as well as programs preparing individuals for the PMI’s examination for certification as Project Management Professionals (PMPs–see Chapter 1 Appendix). The great number of fairly small, short-term projects being carried out, when managed by an experienced PM, serve a purpose beyond the output of the projects themselves. They provide an excellent training ground for new project managers who frequently begin their preparation with involvement in some major aspect of a small project. A number of firms, Procter & Gamble for one, often take management trainees and give them some project-management responsibility; for instance, the guidance of a new cosmetic through test procedures to ensure that it is not toxic to users. Such experience serves to teach trainees many things, not the least of which are the importance of an organized plan for reaching an objective, of “follow-through,” of negotiation with one’s co-workers, and of sensitivity to the political realities of organizational life. The skills and experiences gained from managing a project, even a small one, are a scaled-down version of what it is like to run a full-sized organization. Thus, projects provide an excellent growth environment for future executives and for developing managerial skills. The career path of a PM often starts with participation in small projects, and later in larger projects, until the person is given command over small and then larger projects. For example, the path could be tooling manager for small Project U, project engineer for larger Project V, manufacturing manager for large Project W, deputy project manager for large Project X, project manager for small Project Y, and project manager for large Project Z. The actual establishment of multiple career paths to the top of organizations is more talked about than acted on. Wishful thinking aside, with a very few notable exceptions,* we know of no specific career paths that can take project managers to CEO positions. In a great many firms, however, experience as a PM is seen as a desirable (sometimes mandatory) step on the way up the corporate ladder. The logic of such a view is obvious. The capability of a PM to meet the demands of senior management positions is clearly evidenced by the PM’s

*For example, Eli Lilly and Co., the pharmaceutical firm, finds that projects involving new drugs often last 8–12 years. No PM would be willing to manage a project that long without the opportunity for promotion. Lilly, therefore, has established a career path for their PMs that potentially leads to the top of the firm. They already had career paths progressing through “administration” or “R & D” to the top and have clearly demonstrated the reality of both paths.

3.1 PROJECT MANAGEMENT AND THE PROJECT MANAGER

107

ability to achieve the project’s goals without the need for explicit authority while operating in an environment typified by uncertainty, if not chaos. The recent global recession and accompanying unemployment has put pressure on the project management profession as much as any other profession. Recent comments in the media (e.g., Zupek, 2010) seem to indicate that “the days of a ‘generic’ project manager are numbered” and that firms are now looking for PMs who have “specific experience and understand the nuts and bolts” of the technology or project being implemented. As a result, it’s important that PMs not only continue to develop their project management skills and gain their PMP® certifications, but keep themselves trained in the latest technologies. If true, then it would appear that gaining a wide range of experience would also be more likely to win a job or promotion than gaining depth in one particular area.

Project Management in Practice The Project Management Career Path at AT&T

2006

As a result of the many changes in the phone industry, AT&T realized that the old ways of doing business would not be competitive in the new market they now faced and decided to reengineer their whole process of providing technology to the market. They decided that organizing by project management would give them better control over their business and bring them a competitive advantage. Thus, they set the goal of becoming the leader in project management in the industry. AT&T had previously used project managers in many of its activities but in a significantly different way. For instance, it was more a project coordination responsibility that could be successfully completed through achieving the activities on a task list. However, the position was of low status and seen as only a temporary activity serving to carry someone on to a better functional manager position. Thus, the reward for doing a good job was to move into a functional position and get out of project management. AT&T realized it would have to change the whole nature of the project management role, and the entire structure of the organization as well, if it were to be successful in this strategy. They needed to develop

professional project managers, plus a support system to maintain their abilities and careers in project management. The managerial mentality of two or three years on a project and then moving on to a functional job had to be changed to an attitude of professional pride in project management and staying in the field for the remainder of their careers. Equally important, the organizational mentality of admiring heroic rescues of projects in trouble had to be replaced with admiration for doing a competent job from the beginning and time after time. The reorganization for project management was a major project in itself, including the areas of candidate selection, education and training, compensation, career development, organizational restructuring, and methods development. In terms of organizational structure, a National Project Management (NPM) organization was created at the corporate level, reporting to the service operating vice-president. Reporting to the director of NPM were three project directors spread across the United States, a systems support organization, and a methods and support staff. Program managers, project managers, and their subordinates reported to the project directors. This

108

CHAPTER 3 / THE PROJECT MANAGER

structure provided an integrated, self-contained project management group. The project management career path now consists of:

• • • • • •

Trainee: a six-month position to learn about project management. Cost Analysis/Schedule Engineer: a 6–18 month team position reporting to a project manager. Site Manager: a 6–12 month position responsible for a large site and reporting to a program manager. Small Project Manager: sole responsibility for a $1M to $3M revenue project. Project Manager: responsible for $3M to $25M projects. Program Manager: responsible for multiyear projects and programs over $25M.

Candidates for the project manager career track are selected from AT&T’s Leadership Continuity Plan, a

3.2

program to identify the people with the most potential to progress to middle and senior management levels of responsibility, as well as from career people within the organization. Particular skills sought are interpersonal leadership skills; oral and written communication skills; a presidential, big-picture perspective; political sensitivity; delegating, problem-solver orientation; optimistic, can-do attitude; planner mentality; kaizen (continuous improvement) spirit; and administrative, in-charge credibility. AT&T’s Project Management organization now includes a staff in Denver and groups of project managers in the major cities throughout the nation. These groups now manage over $500 million in projects, ranging in size from $1M to $92M. The project management approach is deemed the most capable in the field, setting the pace for AT&T’s competitors. Source: D. Ono, “Implementing Project Management in AT&T’s Business Communications System,” PM Network,Vol. 4.

SPECIAL DEMANDS ON THE PROJECT MANAGER A number of demands are unique to the management of projects, and the success of the PM depends to a large extent on how capably they are handled. These special demands can be categorized under the following headings.

Acquiring Adequate Resources It was noted earlier that the resources initially budgeted for a project are frequently insufficient to the task. In part, this is due to the natural optimism of the project proposers about how much can be accomplished with relatively few resources. Sometimes, it is caused by a deliberate, unethical understatement of resource requirements to ensure that a project is accepted for funding. At times it is caused by the great uncertainty associated with a project. Many details of resource purchase and usage are deferred until the project manager knows specifically what resources will be required and when. For instance, there is no point in purchasing a centrifuge now if in nine months we will know exactly what type of centrifuge will be most useful. The good PM knows there are resource trade-offs that need to be taken into consideration. A skilled machinist can make do with unsophisticated machinery to construct needed parts, but a beginning machinist cannot. Subcontracting can make up for an inadequate number of computer programmers, but subcontractors will have to be carefully instructed in the needs of the contractor, which is costly and may cause delays. Crises occur that require special resources not usually provided to the project manager. All these problems produce glitches in the otherwise smooth progress of the project. To deal with these glitches, the PM must scramble, elicit aid, work late, wheedle, threaten, or do whatever seems necessary to keep the project on schedule. On occasion, the additional

3.2

SPECIAL DEMANDS ON THE PROJECT MANAGER

109

Project Management in Practice A Surprise “Director of Storm Logistics” for Katrina

One day, Melvin Wilson was simply a marketing manager for small 1250-employee Mississippi Power in Gulfport, Mississippi. But the next day, after Hurricane Katrina hit New Orleans and Gulfport, he was suddenly the firm’s “Director of Storm Logistics,” responsible for restoring power to 195,000 customers within 12 days. Although Mississippi Power’s primary storm center at headquarters was knocked out, they had a backup storm center 5 miles inland. However, when Wilson got there, the cars were floating in the parking lot, so he moved his small group in charge to a third location, an old service office without electricity or running water. In spite of the phone lines being down, the group managed to get word of their needs to the outside world and within days, 11,000 repairmen from 24 states and Canada came to help. To support the 11,000 workers, the group needed housing, beds, food, clean water, showers, laundry, bulldozers, 5000 trucks, 140,000 gallons of fuel each day, 8000 tetanus shots, and hundreds of other such items. Directing such a massive project as the restoration of power was far beyond the experience of little Mississippi Power’s group, but they succeeded, and the power was restored to every customer who could handle it within 12 days. Source: D. Cauchon, “The Little Company That Could,” USA Today, 2005.

required resources simply alter the project’s cost-benefit ratio to the point that the project is no longer cost-effective. Obviously, the PM attempts to avoid these situations, but some of what happens is beyond the PM’s control. The problems of time and budget are aggravated in the presence of a phenomenon that has been long suspected but only proved in the mid-1980s (Gagnon, 1982; Gagnon et al., 1987). The individual who has the responsibility for performing and completing a task sometimes overestimates the time and cost required. That individual’s immediate supervisor often discounts the worker’s pessimism but, in so doing, may underestimate the time and cost. Moving up the management hierarchy, each successive level frequently lowers the time and cost estimates again, becoming more optimistic about the ability of those working for them to do with less— or, perhaps, more forgetful about what things were like when they worked at such jobs. The authors have informally observed—and listened to complaints about—such doings in a variety of organizations. We suspect they reflect the superior’s natural tendency to provide challenging

110

CHAPTER 3 / THE PROJECT MANAGER

work for subordinates and the desire to have it completed efficiently. The mere recognition of this phenomenon does not prevent it. Complaints to upper-level managers are usually met with a hearty laugh, a pat on the back, and a verbal comment such as, “I know you can do it. You’re my best project manager, and you can. . . .” We will consider the doubtful ethics in over/understating resource requirements and project schedules along with other ethical problems in Section 3.3. Another issue may complicate the problem of resource acquisition for the PM. Project and functional managers alike perceive the availability of resources to be strictly limited and thus a strict “win-lose” proposition. Under these conditions, the “winners” may be those managers who have solid political connections with top management. Often, there are times in the life of any project when success or survival may depend on the PM’s “friendship” with a champion or “sponsor” high in the parent organization (Pinto et al., 1989). For example (PMI, 2005), in 1994 a Chicago-based Commemoration Committee was formed to build a four-story, $1 million monument memorializing the 150th anniversary of the Irish potato famine. However, the project manager selected depended on a church sponsor to support the project, but in 1999 the church sponsor who championed the project had moved on to another city and the church thus stopped supporting the project. This illustrates the difficulty of a long, multiyear effort when the sponsor leaves.

Acquiring and Motivating Personnel A major problem for the PM is the fact that most of the people needed for a project must be “borrowed” from elsewhere in the organization conducting the project. With few exceptions, they are borrowed from the functional departments. The PM must negotiate with the functional department managers for the desired personnel, and then, if successful, negotiate with the people themselves to convince them to take on these challenging temporary project assignments. Most functional managers cooperate when the PM comes seeking good people for the project, but the cooperative spirit has its limits. The PM will be asking for the services of the two types of people most needed and prized by the functional manager: first, individuals with scarce but necessary skills and, second, top producers. Both the PM and functional manager are fully aware that the PM does not want a “has-been,” a “never-was,” or a “never-will-be.” Perceptions about the capabilities of individuals may differ, but the PM is usually trying to borrow precisely those people the functional manager would most like to keep. A second issue may reduce the willingness of the functional manager to cooperate with the PM’s quest for quality people. At times, the functional manager may perceive the project as more glamorous than his or her function and hence a potent source of managerial glory. The functional manager may thus be a bit jealous or suspicious of the PM, a person who may have little interest in the routine work of the functional area even if it is the bread and butter of the organization. On its surface, the task of motivating good people to join the project does not appear to be difficult, because the kind of people who are most desired as members of a project team are those naturally attracted by the challenge and variety inherent in project work. The subordinate who is being seduced to leave the steady life of the functional area for the glamour of a project can be gently reminded that the functional manager retains control of personnel evaluation, salary, and promotion for those people lent out to projects. (A few exceptions to these general rules will be discussed in Chapter 5.) There may even be comments about how easy it is to lose favor or be forgotten when one is “out of sight.” Unless the PM can hire outsiders with proven ability, it is not easy to gather competent people; but having gathered them, they must be motivated to work. Because the functional manager controls pay and promotion, the PM cannot promise much beyond the challenge of the work itself. Fortunately, as Herzberg (1968) has argued, that is often sufficient (also see Pinto et al., 1989) since many of the project personnel are professionals and experts in their respective specialties. A story has it that when asked “How do you motivate astronauts?” a representative of NASA responded, “We don’t motivate them, but, boy, are we careful about whom we select.”

3.2

SPECIAL DEMANDS ON THE PROJECT MANAGER

111

The issue of motivating people to join and work creatively for a project is closely related to the kind of people who are invited to join. The most effective team members have some common characteristics. A list of the most important of these follows, but only the first is typically considered during the usual selection process. 1. High-quality technical skills Team members should be able to solve most of the technical problems of a project without recourse to outside assistance. Even if the relevant functional department has furnished technical specialists to the project, the exact way technology is applied usually requires adaptation by the project team. 2. Political, and general, sensitivity It is obvious that the PM requires political skills of a high order. Though it is less obvious, project team members also need to be sensitive to organizational politics and similar matters outside their realm of normal interaction. Project success is dependent on support from senior management in the parent organization. This support depends on the preservation of a delicate balance of power between projects and functional units, and between the projects themselves. The balance can be upset by individuals who demand their own way or are otherwise insensitive to political and organization needs and constraints external to the project. 3. Strong problem orientation Research conducted by Pill (1971), more than 25 years before Hughes’s (1998) work, has shown that the chances for successful completion of a multidisciplinary project are greatly increased if project team members are problem-oriented rather than discipline-oriented, as noted earlier. Pill indicates that problem-oriented people tend to learn and adopt whatever problem-solving techniques appear helpful, but discipline-oriented individuals tend to view the problem through the eyes of their discipline, ignoring aspects of the problem that do not lie within the narrow confines of their educational expertise. 4. Strong goal orientation Projects do not provide a comfortable work environment for individuals whose focus is on activity rather than on results. Work flow is rarely even, and for professionals a 60-hour week is common, as are periods when there seems to be little to do. “Clock watchers” will not be successful team members. 5. High self-esteem As we noted earlier, a prime law for projects (and one that applies equally well to the entire organization) is: Never let the boss be surprised. Projects can rapidly get into deep trouble if team members hide their failures, or even a significant risk of failure, from the PM. Of course, the PM must be aware that “shooting the messenger who brings bad news” will immediately stop the flow of any negative information. Individuals on the team should have sufficiently high levels of self-esteem that they are not threatened by acknowledgment of their own errors, or by pointing out possible problems caused by the work of others.

Dealing with Obstacles “What I need is a list of specific unknown problems that we will encounter.”* Anonymous manager

*The authors received this and several other “Management Quotes” in an e-mail communication. They were reported to be entries in a magazine contest and supposedly came from “real-life managers.” They have been set in a distinctive box so they will be easy to recognize. We list other such quotes in similar boxes, but without credit and without repeating this footnote.

112

CHAPTER 3 / THE PROJECT MANAGER

One characteristic of any project is its uniqueness, and this characteristic means that the PM will have to face and overcome a series of crises. These crises, such as changes in the required project scope (better known as “scope creep”), affect not only the project but the PM as well, and his or her ability to make trade-offs to keep the project on track, a topic discussed further below. From the beginning of the project to its termination, crises appear without warning. The better the planning, the fewer the crises, but no amount of planning can take account of the myriad of changes that can and do occur in the project’s environment. The successful PM is a fire fighter by avocation. At the inception of the project, the “fires” tend to be associated with resources. The technical plans to accomplish the project have been translated into a budget and schedule and forwarded up the managerial hierarchy or sent to the client for approval. In an earlier section we noted that some of the budget and schedule is pared away at each successive step up the hierarchy. Each time this happens, the budget and schedule cuts must be translated into changes in the technical plans. Test procedures may be shortened, suppliers’ lead times may be cut. The required cost and schedule adjustments are made, a nip here and a tuck there. To the people affected, these may well be crises. As we will note in Chapter 7, an obvious cure for these crises is to “pad” the budget when it is originally submitted. This is unethical, a bad idea, and generally creates more serious problems than it solves. To be useful, experience must be generalized and organized. Managing a project is much like managing a business. Business firms often develop special routines for dealing with various types of fires. Human resource departments help put out “people fires” just as engineering helps deal with “mechanical fires.” Fire-fighting, to be optimally effective, should be organized so that fires are detected and recognized as early as possible. As the Reading at the end of this chapter emphatically notes, what clearly differentiates successful PMs from their counterparts is their problem finding ability. This allows the fires to be assigned to project team members who specialize in dealing with specific types of fires. Although this procedure does not eliminate crises, it does reduce the pain of dealing with them. This emphasis on the need for fire-fighting raises another issue worth a brief comment. Some individuals thrive on dealing with crises. They have been referred to as “adrenalin junkies.” If a PM finds such people fighting fires in her or his project, the PM should be aware that she or he may have found an arsonist. The wise PM will keep a careful eye on those who appear to be addicted to the excitement of crises. As the project nears completion, obstacles tend to be clustered around two issues: first, last-minute schedule and technical changes, and second, a series of problems that have as their source the uncertainty surrounding what happens to members of the project team when the project is completed. These two types of problems are very different from one another, as well as from the problems that faced the PM earlier in the life cycle of the project. The way to deal with last-minute schedule and technical changes is “the best you can.” Beyond knowing that such changes will occur and will be disruptive to the project, there is little the PM can do except be prepared to “scramble.” Coping with the uncertainty surrounding what happens at the end of a project is a different matter. The issue will be covered at greater length in Chapter 13, but it deserves mention here because it is certainly an obstacle that the PM must overcome. The key to solving such problems is communication. The PM should make open communications between the PM and team members first priority. The notion of “open communications” requires that emotions, feelings, worries, and anxieties be communicated, as well as factual messages.

Making Project Goal Trade-offs The PM must make trade-offs between the project goals of cost, time, and scope and, of course, the ancillary goals. The PM must also make trade-offs between project progress and

3.2

SPECIAL DEMANDS ON THE PROJECT MANAGER

113

process—that is, between the technical and managerial functions. The first set of trade-offs is required by the need to preserve some balance between the project time, cost, and scope goals. Conventional wisdom had it that the precise nature of the trade-offs varied depending on the stage of the project life cycle. At the beginning of the life cycle, when the project is being planned, scope was felt to be the most important of the goals, with cost and schedule sacrificed to the technical requirements of the project. Following the design phase, the project builds momentum, grows, and operates at peak levels. Because it accumulates costs at the maximum rate during this period, cost was felt to take precedence over scope and schedule. Finally, as the project nears completion, schedule becomes the high-priority goal, and cost (and perhaps scope) suffers. Research (Kalu 1993) has shown that these assumptions, sensible as they seem, are not true. During the design or formation stage of the project life cycle, there is no significant difference in the importance project managers place on the three goals. It appears that the logic of this finding is based on the assumption that the project should be designed to meet all the client-set goals. If compromises must be made, each of the objectives is vulnerable. Schedule is the dominant goal during the buildup stage, being significantly more important than scope, which is in turn significantly more important than cost. Kloppenborg et al. (1990, p. 127) conjectures that this is so because scheduling commitments are made during the buildup stage. Scheduling and scope are approximately tied for primacy during the main stage of the life cycle when both are significantly more important than cost. During the final stage, phaseout, scope is significantly more important than schedule, which is significantly more important than cost. Table 3-1 shows the relative importance of each objective for each stage of the project life cycle. The second set of trade-offs concerns sacrificing smoothness of running the project team for technical progress. Near the end of the project it may be necessary to insist that various team members work on aspects of the project for which they are not well trained or which they do not enjoy, such as copying or collating the final report. The PM can get a fairly good reading on team morale by paying attention to the response to such requests. The PM also has responsibility for other types of trade-offs, ones rarely discussed in the literature of project management. If the PM directs more than one project, he or she must make trade-offs between the several projects. As noted earlier, it is critical to avoid the appearance of favoritism in such cases. Thus, we strongly recommend that when a project manager is directing two or more projects, care should be taken to ensure that the life cycles of the projects are sufficiently different that the projects will not demand the same constrained resources at the same time, thereby avoiding forced choices between projects. In addition to the trade-offs between the goals of a project, and in addition to trade-offs between projects, the PM will also be involved in making choices that require balancing the goals of the project with the goals of the firm. Such choices are common. Indeed, the necessity

Table 3-1 Relative Importance of Project Objectives during Different Stages of the Project Life Cycle Scope

114

CHAPTER 3 / THE PROJECT MANAGER

for such choices is inherent in the nature of project management. The PM’s enthusiasm about a project—a prime requirement for successful project management—can easily lead him or her to unethical decisions: (1) overstate the benefits of a project, (2) understate the probable costs of project completion, (3) ignore technical difficulties in achieving the required level of performance, and (4) make trade-off decisions that are clearly biased in favor of the project and antithetical to the goals of the parent organization. Similarly, this enthusiasm can lead the PM to take risks not justified by the likely outcomes. Finally, the PM must make trade-off decisions between the project, the firm, and his or her own career goals. Depending on the PM’s attitudes toward risk, career considerations might lead the PM to take inappropriate risks or avoid appropriate ones.

Maintaining a Balanced Outlook Sometimes it is difficult to distinguish whether a project is heading for failure or success. Indeed, what appears to be a failure at one point in the life of a project may look like success at another. The reality is that projects often run into technical problems or snags. More serious than the snags themselves can be the psychic consequences of such technical snags. The occurrence and solution of technical problems tend to cause waves of pessimism and optimism to sweep over the project staff. There is little doubt that these swings of mood can have a destructive effect on performance. The PM must cope with these alternating periods of elation and despair, and the task is not simple. Performance will be strongest when project team members are “turned on,” but not so much that they blandly assume that “everything will turn out all right in the end,” no matter what. Despair is even worse because the project is permeated with an attitude that says, “Why try when we are destined to fail?” Maintaining a balanced, positive outlook among team members is a delicate job. Setting budgets and schedules with sufficient slack to allow for Murphy’s law, but not sufficient to arouse suspicion in cost and time-conscious senior management, is also a delicate job.

Breadth of Communication

PMBOK Guide Chapter 10

Communication is considered a specific knowledge area (7) in PMBOK. The topic will be discussed further in the later sections of this chapter as well as Chapter 4. As pointed out clearly in the Reading at the end of this chapter, communication skills, especially listening and persuading, are the most important skills in successfully managing projects. As is the case with any manager, most of the PM’s time is spent communicating with the many groups interested in the project (Mintzberg, 1973). Running a project requires constant selling, reselling, and explaining the project to outsiders, top management, functional departments, clients, and a number of other such parties-at-interest to the project, as well as to members of the project team itself. The PM is the project’s liaison with the outside world, but the manager must also be available for problem solving in the lab, for crises in the field, for threatening or cajoling subcontractors, and for reducing interpersonal conflict between project team members. And all these demands may occur within the span of one day—a typical day, cynics would say. To some extent, every manager must deal with these special demands; but for a PM such demands are far more frequent and critical. As if this were not enough, there are also certain fundamental issues that the manager must understand and deal with so that the demands noted can be handled successfully. First, the PM must know why the project exists; that is, the PM must fully understand the project’s intent. The PM must have a clear definition of how success or failure is to be determined. When making trade-offs, it is easy to get off the track and strive to meet goals that were really never intended by top management.

3.2

SPECIAL DEMANDS ON THE PROJECT MANAGER

115

Second, any PM with extensive experience has managed projects that failed. As is true in every area of business we know, competent managers are rarely ruined by a single failure, but repeated failure is usually interpreted as a sign of incompetence. On occasion a PM is asked to take over an ongoing project that appears to be heading for failure. Whether or not the PM will be able to decline such a doubtful honor depends on factors unique to each situation: the PM’s relationship with the program manager, the degree of organizational desperation about the project, the PM’s seniority and track record in dealing with projects like the one in question, and other matters, not excluding the PM’s being engaged elsewhere when the “opportunity” arises. Managing successful projects is difficult enough that the PM is, in general, well advised not to volunteer for undertakings with a high probability of failure. Third, it is critical to have the support of top management (Pinto et al., 1989). If support is weak, the future of the project is clouded with uncertainty, and if it is an R & D project, it is more likely to be terminated (Green, 1995). Suppose, for example, that the marketing vice-president is not fully in support of the basic project concept. Even after all the engineering and manufacturing work has been completed, sales may not go all out to push the product. In such a case, only the chief executive officer (CEO) can force the issue, and it is very risky for a PM to seek the CEO’s assistance to override a lukewarm vice-president. If the VP acquiesces and the product fails (and what are the chances for success in such a case?), the project manager looks like a fool. If the CEO does not force the issue, then the VP has won and the project manager may be out of a job. As noted earlier, political sensitivity and acumen are mandatory attributes for the project manager. The job description for a PM should include the “construction and maintenance of alliances with the leaders of functional areas.” Fourth, the PM should build and maintain a solid information network. It is critical to know what is happening both inside and outside the project in order to head off potential problems, a major skill of successful PMs, as noted earlier. The PM must be aware of customer complaints and department head criticism, who is favorably inclined toward the project, when vendors are planning to change prices, or if a strike is looming in a supplier industry. Inadequate information can blind the PM to an incipient crisis just as excessive information can desensitize the PM to early warnings of trouble. Finally, the PM must be flexible in as many ways, with as many people, and about as many activities as possible throughout the entire life of the project. The PM’s primary mode of operation is to trade off resources and criteria accomplishment against one another. Every decision the PM makes limits the scope of future decisions, but failure to decide can stop the project in its tracks.

Project Management in Practice The Wreckmaster at a New York Subway Accident At 12:16 A.M., in late August, a 10-car subway train on the Lexington Line beneath New York City jumped the track and crashed in the subway tunnel. Damage was massive—five cars were derailed, one was cut in half, another bent in two, possibly 150 persons injured, four dead. The train ripped out steel-girder support columns used to hold up the tunnel ceiling, as well as the street above which immediately sunk a half inch. Two tracks

and a third rail had been ripped out and two signal sets, two switches, and an air compressor room destroyed. When such an emergency occurs, the New York City Transit Authority (NYCTA) immediately appoints a project master, called a “Wreckmaster,” to oversee the handling of the disaster rescue and repair activities, and make sure that operations are returned to a safe condition as soon as possible. In this case, the

116

CHAPTER 3 / THE PROJECT MANAGER

A worker looks at the wreckage of a subway car following a derailment. ((c)AP/Wide World Photos)

Street

Street

1A Cabinet

Street

Station platform

2 Compression room

Building

3

4

5

1B

6

7

8

9

10

Station platform

E 16th

E. 17th

E. 18th

Legend: Placement of derailed trains 1A Car # 1440 1B Car # 1440 2 Car # 1439

3 4

Car # 1437 Car # 1436

5 6

Car # 1435 Car # 1434

7 8

Car # 1432 Car # 1431

9 Car # 1433 10 Car # 1438

14th Street - Union Square Derailment

goal was to have the subway back to normal operation by Tuesday morning rush hour, September 3, after the three-day holiday weekend. Such disasters are handled in eight phases: Phase 1: Respond to injury—Get people out of danger, provide needed medical care, remove bodies

and ensure that no victims remain in the debris. Phase 2: Secure the area—Simultaneously with phase 1, eliminate other threats to life and property by disconnecting power, providing emergency lighting and ventilation, stopping other trains

3.2

from entering the area, and keeping nonrelevant pedestrian and vehicular traffic out. Phase 3: Initiate command facilities—Concurrent with phases 1 and 2, set up and activate command and coordination structure for all emergency activities. Phase 4: Remove debris—Collect and remove the elements and debris of the accident which would hinder rescue, clean-up, or repair. Phase 5: Remove damaged equipment—Use cranes, cutting torches, and other equipment to remove the large, major equipment. Phase 6: Facility repair—Repair the facilities as quickly as possible for continuing and normal use. Phase 7: Test—Make certain that all facilities are fully operational and safe by testing under the watchful eye of engineering, operations, and safety. Phase 8: Clean-up—Clean the premises to the best possible state to permit normal operations.

The crash was heard at NYCTA’s Union Square District 4 and about 40 transit police officers ran to assist passengers at the smoke-filled scene. Soon, officers from District 2, the Fire Department, and the Office of Emergency Management joined them. The Fire Department brought fans to help clear the smoke and steel cable to rope the wreckage to the support pillars so they could reach people still in the train cars without the roof caving in on them. Buses were dispatched to transport people to hospitals and the Red Cross provided food and drink for the injured. Some rescuers fainted from heat exhaustion as the temperature climbed to over 110 °F in the tunnel and two dozen police and fire workers were treated for injuries and smoke inhalation. Transit police officer Emanuel Bowser was riding the train when it crashed but helped people get off for more than four hours after the crash even though he had a broken arm and fingers himself. After learning about the crash, NYCTA appointed Larry Gamache, general superintendent of track operations, as Wreckmaster. Larry set up team captains to coordinate activities throughout each phase of the disaster operations. A command center was established at a nearby subway station to direct and

SPECIAL DEMANDS ON THE PROJECT MANAGER

117

coordinate the operations. Gamache formulated a mental flow chart of how work needed to proceed. Each task had to be analyzed to determine what tasks had to precede it and what tasks could be conducted concurrently with it. Gamache also initiated regular meetings for all involved parties. This kept everyone informed of what progress had been made and provided them with estimates of future progress so activities could be coordinated and sequenced. The plan was to remove the wreckage as quickly as possible from one track to allow worktrains to reach the disaster site, bringing needed materials to the site and removing debris. Since work had to continue throughout the Labor Day weekend on 12-hour shifts, facilities for the workers—food, drink, toilets—also had to be provided. Diesel trains pulled out the five cars that didn’t derail, but getting out the other five was a special problem. A new Hoersh hydraulic jacking system was brought in from another district that could lift a 44-ton car, move it sideways, and set it back down on the tracks. Using these jacks reduced by half the labor required to rerail the cars, thereby significantly expediting the recovery. As work progressed through the long weekend, it became apparent that the disaster recovery plan would meet its Tuesday morning completion goal and, in fact, trains began running again by late evening on Monday.

Lawrence Gamache, Wreckmaster Larry Gamache started at NYCTA 24 years ago as a trackworker and progressed through many managerial positions on his way to general superintendent, track operations. His experience over those years clearly qualified him for the responsibility of this assignment, particularly his involvement as field supervisor of several earlier derailments. He was also highly involved in a three-year subway reconstruction project that required extensive coordination and negotiation with other city agencies, communities, and political leaders, all the while battling inclement weather and difficult conditions—yet, the project was completed ahead of time and well under budget. This experience, too, was valuable in coordinating the activities of the many groups involved in the disaster recovery. Source: S. Nacco, “PM in Crisis Management at NYCTA: Recovering from a Major Subway Accident,” PM Network,Vol. 6.

118

CHAPTER 3 / THE PROJECT MANAGER

Negotiation In order to meet the demands of the job of project manager—acquiring adequate resources, acquiring and motivating personnel, dealing with obstacles, making project goal tradeoffs, maintaining a balanced outlook, and establishing a broad network of communication— the project manager must be a highly skilled negotiator. There is almost no aspect of the PM’s job that does not depend directly on this skill. We have noted the need for negotiation at several points in the previous pages, and we will note the need again and again in the pages that follow. The subject is so important, Chapter 4 is devoted to a discussion of the matter.

3.3

ATTRIBUTES OF EFFECTIVE PROJECT MANAGERS Selection of the project manager is one of the two or three most important decisions concerning the project. In this section, we note a few of the many skills the PM should possess in order to have a reasonable chance of success. The following is a list of some of the most popular attributes, skills, and qualities that have been sought when selecting project managers:

• • • • • • • •

A strong technical background A hard-nosed manager A mature individual Someone who is currently available Someone on good terms with senior executives A person who can keep the project team happy One who has worked in several different departments A person who can walk on (or part) the waters

These reasons for choosing a PM are not so much wrong as they are “not right.” They miss the key criterion. Above all, the best PM is the one who can get the job done! As any senior manager knows, hard workers are easy to find. What is rare is the individual whose focus is on the completion of a difficult job, a “closer.” Of all the characteristics desirable in a PM, this drive to complete the task is the most important. If we consider the earlier sections of this chapter, we can conclude that there are four major categories of skills that are required of the PM and serve as the key criteria for selection, given that the candidate has a powerful bias toward task completion. Moreover, it is not sufficient for the PM simply to possess these skills; they must also be perceived by others. The fact and the perception are both important.

Credibility The PM needs two kinds of credibility. First is technical credibility. The PM must be perceived by the client, senior executives, the functional departments, and the project team as possessing sufficient technical knowledge to direct the project. A PM with reasonable technical competence seems to be associated with project success and is seen by project team members to be a “positive” leadership characteristic (Ford et al., 1992; Zimmerer et al., 1998). (We remind the reader that “technical credibility” includes technical knowledge in such arcane fields as accounting, law, psychology, anthropology, religion, history, playwriting,

3.3

ATTRIBUTES OF EFFECTIVE PROJECT MANAGERS

119

Greek, and a host of other nonhard sciences.) The PM does not need to have a high level of expertise, know more than any individual team members (or all of them), or be able to stand toe-to-toe and intellectually slug it out with experts in the various functional areas. Quite simply, the PM has to have a reasonable understanding of the base technologies on which the project rests, must be able to explain project technology to senior management, and must be able to interpret the technical needs and wants of the client (and senior management) to the project team. Similarly, the PM must be able to hear the problems of the project team and understand them sufficiently to address them, possibly by communicating them to upper management. Second, the PM must be administratively credible. The PM has several key administrative responsibilities that must be performed with apparently effortless skill. One of these responsibilities is to the client and senior management—to keep the project on schedule and within cost and to make sure that project reports are accurate and timely. This can place the PM in an ethically awkward situation sometimes. Another responsibility is to the project team—to make sure that material, equipment, and labor are available when and where needed. Still another responsibility is to represent the interests of all stakeholders (team, management, functional departments, community, and client) to one another. The PM is truly the “person in the middle.” Finally, the PM is responsible for making the tough trade-off decisions for the project, and must be perceived as a person who has the mature judgment and courage to do so consistently.

Sensitivity The preceding pages contain many references to the PM’s need for political sensitivity. There is no point in belaboring the issue further. In addition to a good, working set of political antennae, the PM needs to sense interpersonal conflict on the project team or between team members and outsiders. Successful PMs are not conflict avoiders. Quite the opposite, they sense conflict early, then confront and deal with it before the conflict escalates into interdepartmental and intradepartmental warfare. The PM must keep project team members “cool.” This is not easy. As with any group of humans, rivalries, jealousies, friendships, and hostilities are sure to exist. The PM must persuade people to cooperate irrespective of personal feelings, to set aside personal likes and dislikes, and to focus on achieving project goals. Finally, the PM needs a sensitive set of technical sensors. It is common, unfortunately, for otherwise competent and honest team members to try to hide their failures. Individuals who cannot work under stress would be well advised to avoid project organizations. In the pressurecooker life of the project, failure is particularly threatening. Remember that we staffed the team with people who are task-oriented. Team members with this orientation may not be able to tolerate their own failures (though they are rarely as intolerant of failure in others), and may hide failure rather than admit to it. The PM must be able to sense when things are being “swept under the rug” and are not progressing properly.

Leadership, Ethics, and Management Style Leadership has been defined (Tannenbaum et al., 1957) as “interpersonal influence, exercised in situations and directed through the communication process, toward the attainment of a specified goal or goals.” Much has been written about how interpersonal influence is generated and the impact of leadership characteristics on team performance. Examples are Jiang et al. (1998); Scott et al. (1998); see also the bibliography.

120

CHAPTER 3 / THE PROJECT MANAGER

The following discussion is based on Müller and Turner (2010). Many approaches have been postulated to develop a coherent leadership theory: the trait school, the behavioral school, and the contingency school, to mention only the first three of several. Recently, the competency school has combined parts of all earlier “schools” by defining various leadership qualities with three major areas of competence; intellectual (IQ), managerial (MQ), and emotional (EQ). The leadership competencies associated with the three areas are shown in Table 3-2. It has been well established that for different types of projects to be successful, project managers need different types of skills. Müller and Turner (2010) showed that engineering (and construction) projects, IT projects, and organizational change projects all required different levels of the 15 competencies to be successful. Further, they showed that the competency levels required varied with the complexity of the project, the importance of the project, and with the type of contract under which the project was carried out. We will return to the relationship between leadership competencies, level of complexity, and project success, including project type, in later chapters. Another aspect of leadership that is important in a project manager is a strong sense of ethics. There is a considerable amount of attention to this topic in the news media these days, both good and bad, such as Enron, Lehman Brothers’ use of Repo 105 (to get debt off their balance sheet), and of course, Bernie Madoff. Though less clear, some situations raise serious ethical questions such as:

• • • •

BP’s subcontracting and safety procedures before the Gulf oil spill Goldman Sachs betting both ways on the synthetic CDO (collateralized debt obligation) it created for John Paulson to bet against the housing market protection payments made to terrorists by firms mining companies’ safety procedures

Table 3-2 Three Styles of Leadership and Fifteen Leadership Competencies. (Dulewicz et al., 2003) Area of Competence

Competency

Intellectual (IQ)

1. Critical analysis and judgment 2. Vision and imagination 3. Strategic perspective

Managerial (MQ)

4. Engaging communication 5. Managing resources 6. Empowering 7. Developing 8. Achieving

Emotional (EQ)

9. Self-awareness 10. Emotional resilience 11. Motivation 12. Sensitivity 13. Influence 14. Intuitiveness 15. Conscientiousness

3.3

ATTRIBUTES OF EFFECTIVE PROJECT MANAGERS

121

Nixon (1987) has identified some ethical missteps that are relatively common in business:

• • • • • • • • •

“wired” bids and contracts (the winner has been predetermined) “buy-in” (bidding low with the intent of cutting corners or forcing subsequent contract changes) kickbacks “covering” for team members (group cohesiveness) taking “shortcuts” (to meet deadlines or budgets) using marginal (substandard) materials compromising on safety violating standards consultant (e.g., auditors) loyalties (to employer or to client or to public)

A project manager, particularly in the public sector, may easily become embroiled in the ethics concerning such issues as pollution, public safety, industrial plant locations, the use of public lands, and so on. A Code of Ethics for project managers was created at the PMI 1982 symposium on Project Management (Ireland et al., 1982), updated and approved in 1989, again in 1995, and once more in 2006. The 2006 version of the Code resulted from extended discussions and is roughly 8 times the length of earlier versions—including appendices. It is available to anyone at the PMI website, www.PMI.org. The issue is receiving an increasing amount of attention. Anyone seriously considering a career in project management should study the new code. It focuses on behavior that will lead to a high trust level between the PM, project team members, senior management, the client, and other stakeholders. The section entitled “Honesty” should be read, reread, and read once again. We will revisit the subjects of honesty and trust in almost every chapter of this book. An “ethics audit” has also been recommended for nonprofit organizations (Schaefer et al., 1998), and we would recommend a similar audit for any firm. The extent of this subject is far beyond what we can cover here, but, fortunately, there are a number of excellent books on the topic (Barry, 1979; Blanchard et al., 1988; Pastin, 1986). A concise bibliography on business ethics is included in Robb (1996). While a great deal has been written about the leadership attributes required or desirable in a project manager, comparatively little has been written about the proper management style for a PM. Shenhar (1998) classifies projects across two dimensions and concludes that management style should be adapted to certain differences in the type of project. His dimensions are: (1) the level of technological uncertainty; and (2) the level of system complexity. As the uncertainty increases from “low tech” to “high tech,” the appropriate management style progresses from “firm, rigid, and formal” to “highly flexible.” As the system complexity increases from simple to highly complex, the style progresses from “in-house informal” to “remote and highly formal.”

Ability to Handle Stress Throughout this chapter and elsewhere in this book, we have noted that the life of the project manager is rarely serene. The PM is surrounded by conflict, often caught in an irrational management structure (described further in Chapter 5), and trapped in a high-stress occupation. Kent (2008) identifies six signs of excessive stress in the workplace; (1) inability to switchoff work issues, (2) disturbed sleep, (3) lack of pleasure in non-work related leisure activities,

122

CHAPTER 3 / THE PROJECT MANAGER

(4) difficulty concentrating or making decisions, (5) tendency to anger quickly, and (6) lack of energy. There are ways to deal with excessive stress. It is best if the organization is attuned to the problem and monitors their PMs and employees for work overload. Also, the PM should be self-aware and spot the danger signals early. Kent suggests several ways to control stress: 1. Keep a journal, taking time to reflect on the events of the day. 2. Prioritize all tasks facing you, eliminating tasks that do not really need to be done, transferring or delegating what you can, delaying low priority items, and minimizing the scope of any subtask that is not crucial to your overall task. 3. Give yourself time to unwind from high stress meetings, perhaps by taking a short walk or doing 15 minutes of exercise or meditation. Avoid meditating on the high-stress meeting. 4. Engage in after-work physical activities that take your mind off the tasks. 5. Improve your physical surroundings so they are pleasant, enjoyable, and comfortable, helping you to relax. 6. Become aware of the control you do or do not have over events. One of the great laws of living is “Do not develop anxiety about things over which you have no control!” One way PMs try to handle excess work is by “multitasking.” But as Hunsberger (2008) points out, this does not work. In fact, multitasking is a misnomer. What you are doing is switching back and forth between tasks. You lose time whenever you do this. Her advice is to divide your tasks into small steps, prioritize them on a to-do list, be proactive by tackling and completing tasks as soon as possible, and then cross them off the list. If you can’t finish in one sitting, leave notes that trigger your memory about where you were when you were interrupted. There are numerous factors in life that cause stress and project managers are as subject to them as other humans. There do, however, appear to be four major causes of stress often associated with the management of projects. First, some PMs never develop a reasonably consistent set of procedures and techniques with which to manage their work. Second, many simply have “too much on their plates.” Third, some have a high need to achieve that is consistently frustrated. Fourth, the parent organization is in the throes of major change. This book is primarily devoted to helping the PM deal with the first cause of stress. As for the second cause, we would remind the PM to include him/herself as a “resource” when planning a project. Almost all project management software packages will signal the planner when a project plan calls for a resource to be used beyond its capacity (see Chapters 9 and 10). Such signals, at least, provide PMs with some evidence with which to discuss the work load with the appropriate senior manager. Concerning the third cause of stress, Slevin (1989) points out that stress results when the demands made on an individual are greater than the person’s ability to cope with them, particularly when the person has a high need for achievement. It is axiomatic that senior managers give the toughest projects to their best project managers. It is the toughest projects that are most apt to be beset with unsolvable problems. The cure for such stress is obvious, except to the senior managers who continue the practice. Finally, in this era of restructuring and downsizing, stress from worry about one’s future is a common condition in modern organizations. Dealing with and reducing these stresses as well as the stress resulting from everyday life is beyond the scope of this book as well as the expertise of its authors. Fortunately, any bookstore will have entire sections devoted to the subject of stress and its relief.

3.3

ATTRIBUTES OF EFFECTIVE PROJECT MANAGERS

123

Project Management in Practice Growing Stress at Twitter

As Kathy Norlen, operations project manager at Twitter points out, the company is growing awfully fast. At the beginning of 2009, Twitter had 5 million registered users; twenty months later it had 125 million. Every day, another 300,000 people sign up for a new account. In its first 3½ years it sent out 10 billion tweets; in the last 5 months it sent out another 10 billion tweets. Worse, the demand ebbs and flows with great volatility and without warning, ranging from an average of 750 tweets per second to over 3000 when some exciting world event happens. The problem is to keep Twitter’s site running smoothly with all this growth and volatility of demand. Although responsible for routine applications management and hardware allocation projects, as well

as leading high-profile four-month projects such as establishing a custom-built data center near Salt Lake City, UT, when there is a database problem affecting service, Norlen says its “all hands on deck.” For these crisis situations, Twitter has established an “on-call” roster of top managers to take charge, and then, as Norlen puts it, you drop everything and get to work! It’s a chaotic environment for leading projects with “no model to follow” and no processes in place, so Norlen has to be creative and invent them, but that’s what makes being a project manager so appealing. Source: M. Wheatley, “Avoiding the Fail Whale,” PM Network, Vol. 24.

124

CHAPTER 3 / THE PROJECT MANAGER

3.4

PROBLEMS OF CULTURAL DIFFERENCES* In this section, we raise a number of issues that plague certain projects. Sometimes these projects require cooperation by individuals and groups from different countries. Sometimes they require cooperation by individuals or groups in one country, but from different industries or even from different divisions of the same firm. It is not, however, the geographical or organizational differences that matter, it is the differences in cultures. Moreover, it is not merely the differences in culture that matter, it is also differences in the environments within which projects are conducted, as we mentioned at the start of this chapter, the economic, political, legal, and sociotechnical environments. While the impacts of these dissimilarities are greatest and most visible in the case of international projects, they exist to some extent any time different organizations (including different parts of one organization) are asked to work together on a project. Throughout this book we emphasize that the PM must manage and reduce conflict between the parties-at-interest or stakeholders in a project: the project team, client, senior management, and the public. If the parties-at-interest represent different nations, industries, and firms, the conflicts and problems besetting the project are greater by an order of magnitude. “Culture” refers to the entire way of life for a group of people. It encompasses every aspect of living and has four elements that are common to all cultures: technology, institutions, language, and arts (The World Book, 1997). The technology of a culture includes such things as the tools used by people, the material things they produce and use, the way they prepare food, their skills, and their attitudes toward work. It embraces all aspects of their material lives. The institutions of a culture make up the structure of the society: the organization of the government, the nature of the family, the way in which religion is organized, the division of labor, the kind of economic system adopted, the system of education, and the way in which voluntary associations are formed and maintained. Language, another ingredient of all cultures, is always unique because it is developed in ways that meet the express needs of the culture. The translation of one culture’s language into another’s is rarely precise because words carry connotative meanings as well as denotative meanings. The English word “apple” may denote a fruit, but it also connotes health (“keeps the doctor away”), bribery (“for the teacher”), New York city, a color, a computer, a dance (late 1930s), favoritism (“of my eye”), as well as several other things. Finally, the arts or aesthetic values of a culture are as important to communication as the culture’s language. Aesthetic values dictate what is found beautiful and satisfying. If a society can be said to have “style,” it is from the culture’s aesthetic values that style has its source.

Culture and the Project A nation’s culture affects projects in many ways. One of the most obvious ways is in how people of different cultures regard time. In the United States and several other Western industrialized nations, time is highly valued as a resource (Smith et al., 1993). We say, “Time is money.” It isn’t, of course, but the expression is one way of expressing impatience with delay and lateness. Latin Americans, on the other hand, hold quite different views of time. The pace of life differs from one culture to another, just as do the values that people place on family or success. The PM conducting a construction project in South America will learn that to be half-an-hour late to a project meeting is to be “on time.” In Japan, lateness causes loss of face. In some cultures, the quality of the work is seen to be considerably more important than on-time delivery. The great value placed on time in the United States and the distaste for tardiness leads to a common perception that U.S. managers are “impatient.” *Occasionally, particular sections will be shaded, meaning that they can be skipped without loss of continuity.

3.4

PROBLEMS OF CULTURAL DIFFERENCES

125

The fundamental philosophy of staffing projects varies greatly in different cultures. In Latin America, for example, the compadre system leads a manager to give preference to relatives and friends when hiring.* U.S. managers feel that such practices are a major source of inefficiency in Latin American firms. In fact, there appears to be scant evidence that this is so. One private study of several firms in the U.S. and Latin American chemical industries indicates that the differences in management practices between U.S. and Latin American chemical firms were, in general, significantly less than the differences between the U.S. chemical firms and U.S. clothing manufacturers. The United States is, by far, the most litigious society on this planet. This does not mean that there are fewer disagreements in other societies, but rather that there is less recourse to courts of law, and, therefore, more recourse to trust and negotiation as a means of resolving conflict. Many authors have noted that trust plays an important role in business relationships (Gogal et al., 1988, for example). The impact of trust on project management, with its dependence on the ability and willingness of others to meet commitments, is clear. The importance of trust is also demonstrated by the critical role played by the compadre system in Latin America. Use of a general agreement with the extended family, as trusted suppliers to a project, for example, is a substitute for the detailed and highly explicit contracts usually required for dealing with “arms-length” suppliers in the United States. In recent years, certain types of collaboration between competitors have grown rapidly, even in the United States (Rosegger et al., 1990). In the United States, SEMATECH is a consortium of semiconductor manufacturers conducting joint research projects in the field, one example among many of collaborative efforts allowed by the National Cooperative Research Act passed in 1984. European nations have also backed research consortia; for example, between 1961 and 1983, Japan initiated more than 60 research consortia, some with more than 40 members (Lynn et al., 1988). The move to collaborative projects has also been transnational. Airbus Industries, the British-French-German-Spanish venture, operating with financial support from its several governments, has achieved outstanding success in commercial aircraft development and production. Other examples are CFM International composed of GE (USA) and Snecma (France), and International Aero Engines composed of Pratt & Whitney (USA), Rolls Royce (UK), Japan Aero Engines, MTU (Germany), and Fiat (Italy). A view almost uniformly held by other societies is that U.S. managers understand everything about technology and nothing about people (e.g., Smith et al., 1993). This view apparently originates in the desire to “get down to business,” while many foreign cultures— certainly Asian, Middle Eastern, Latin American, and southern European—value “getting to know you” as a precursor to the trust required to have satisfying business relationships. In many cultures, the manager is expected to take a personal interest in his or her subordinates’ lives, to pay calls on them, to take an interest in the successes of family members, and to hold a caring attitude. On the other hand, it is clear that U.S. project managers are being urged to value cultural diversity in ways that are often not shared by their foreign cohorts. For at least three-quarters of the world’s population, relationship comes above all else: above time, above budget, above specification. The savvy project manager knows this and knows that he or she will always be balancing, for instance, the needs of the Japanese for meeting deadlines against the Latin American tendency toward a more relaxed approach to dealing with others (Dodson, 1998). We will have much more to say about negotiation in the next chapter.

*We are quite aware that the compadre system is a system of networks of extended family members, and is far more complex than is implied in this simple example.

126

CHAPTER 3 / THE PROJECT MANAGER

For some years, management theorists have been writing about “corporate culture.” We call these “microcultures” to differentiate them from the broader national or regional cultures about which we have been writing. It is just as true, though less obvious, to observe that microcultures vary from industry to industry and from firm to firm just as cultures do from nation to nation. Sales techniques perfectly permissible in one industry, the wholesale automobile industry, for instance, would cause outrage and lawsuits in the business-machine industry. Promises have very different meanings in different areas of business. No one takes seriously the “promised” date of completion of a software application project, any more than a finish-date promise made by a home-remodeling contractor. The impact of interindustry, interfirm, and intrafirm microcultural diversity on the project manager is significant. Perhaps more than any other type of manager, the PM is dependent on commitments made by people, both inside and outside the parent organization, who owe little allegiance to the project, have little cause for loyalty to the PM, and over whom the PM has little or no de jure authority. Hence, the PM must know whose promises can be relied upon and whose cannot. In a major study of 50 transnational projects, Hauptman et al. (1996) found that the accomplishment of product development teams depended on the skill with which they handled two-way communication and cultural differences was critical to success. On the positive side, Levinson et al. (1995) spell out several steps that allow “interorganizational learning” for groups that form international alliances (see also, Fedor et al., 1996).

Project Management in Practice Success at Energo by Integrating Two Diverse Cultures A major project involving some hundreds of millions of dollars was stymied due to the cultural differences between the owner/client, a state-run Middle East developer, and the contractor, a state-run European international designer and builder of industrial and construction projects. As can be imagined, the difference in the cultures is extreme and includes religions, the role of women in society, the difference in power between managers and workers, and the style of management itself. These differences were exacerbated by the conditions surrounding the project: an isolated desert, poor communication, extremely harsh living/ working conditions, and a highly unstable legal/ political environment (taxes, regulations, restrictions, even client reorganizations) that was changing daily. The client and contractor came to realize that the two separate organizational systems created an interface, or boundary, between them that was almost impenetrable. They thus decided to try to integrate the

two systems into one unified system (see Exhibit 1). This was done methodically, with a plan being drawn up, environmental impacts recognized, restructuring of the overall organization, designing the integration, and then implementing the design. As perhaps expected, neither side’s personnel were able to give up their perspective to see the larger picture. The project managers kept working on this issue, however, watched for problems, did a lot of management-by-walking-around, and gradually, the integration began to occur, gathering speed as it went. At project termination, when all costs and engineering changes were hammered out for final payment by tough external bargaining agents (rather than by principled negotiation, typically), no agreement could be reached. Instead, the project managers were brought back and allowed to terminate the project in their own fashion. They simply continued the integration process they had used earlier and quietly phased out the successful project.

3.4

EXHIBIT 1

PROBLEMS OF CULTURAL DIFFERENCES

127

Examples of Integrative Actions.

The Project Style Characteristics Physical Counterparts working together Appearance: (teamwork) Project-related pictures, charts, and schedules on office walls Myths and We are one team with two sides Stories: Both cultures are interesting Both sides’ interests should be satisfied We trust young managers Get the job done Separate yourself from the position and stick to the problem Both project managers are good, and committed to the project Ceremonies: Gather ideas and information from all over the project organization Frequent meetings at all levels Frequent social gatherings and festivities Management Plan, organize, and control with your Style: counterparts Make decisions No finger pointing for wrong decisions, learn the lesson Quickly execute the decision If you need help, don’t hesitate to refer to your boss

Actions Tour the site with counterpart project manager daily Make your office look like a “war room” Whenever possible, let the counterparts have a joint office Organize group visits to local historical sites

From time to time, attend lower-level joint project meetings Celebrate each key event completion

Ask counterparts for joint report on an issue Recognize high-performance managers monthly

Source: D. Z. Milosevic, “Case Study: Integrating the Owner’s and the Contractor’s Project Organization,” Project Management Journal, Vol. 21.

Popular movies and television to the contrary, the intentions of foreign governments and their officials are rarely evil. Foreign governments are usually devoted to ensuring that local citizens are well-treated by invading companies, that national treasures are not disturbed, that employment for their nationals is maximized, that some profits are reinvested in the host country, that safety regulations are not violated, and that other unintended exploitations are prevented. At times, rules and regulations may result from ancient traditions—no consumption of alcoholic beverages in Islamic nations, no consumption of pork products in Israel. The job description of any PM should include responsibility for acquiring a working knowledge of the culture of any country in which he or she is to conduct a project. As far as possible, the project should be conducted in such a way that host-country norms are honored. To do so, however, will often raise problems for management of the parent firm. An unwelcome truth is that the cultures of many countries will not offer a female PM the same level of respect shown a male PM. Thus, senior management is faced with the awkward choice of violating its own policy against sex discrimination or markedly increasing the risk of project failure. The same problem may also exist with the use of a Jewish PM in an Arab country, or an Armenian PM in Turkey. In Chapter 5 we will discuss “virtual” projects, which are transfunctional and/or geographically dispersed. Multicultural projects are “virtual” by definition. In recent years,

128

CHAPTER 3 / THE PROJECT MANAGER

communication problems have been greatly eased for virtual projects through email, the Internet, conference calls, and videoconferencing (Dodson, 1998). While overused email may be a curse for project managers, it is also a blessing when frequent communication with other organizations is required. Of course, these technologies do not relieve the PM from the demands of cultural sensitivity. Though it is not electronic, the technology of negotiation is critical for the PM with a multicultural project. Dodson writes: Project management is ultimately expectation management. Effective management of expectations requires negotiation skills that eclipse more quantitative, “metrical” skills. Projects are only as successful as the degree to which the project manager is an effective negotiator. . . . We have already noted the difference in the bottom-up flow of information in American projects and the top-down flow in countries where the management style is authoritarian. Grinbergs et al. (1993) compare the managerial characteristics of Swiss and American managers/engineers of the same general age, education, and salary levels, all of whom were working on software projects. The study revealed that Swiss managers were “much more formal” with each other than Americans. This demonstrates the interaction of interpersonal style and language. Because we have emphasized planning so strongly in this book, we find the differences in the Swiss and American approaches to planning of special interest. “The U.S. respondents did not consider thorough planning and a long-term strategy as absolute prerequisites for beginning a project. . . . Though promptness is highly valued in both countries, long-term strategy is considered much more important in the Swiss company” (Grinbergs et al., 1993, p. 24). In addition to these areas, the Swiss and Americans differed in a number of other ways of import to the PM. The Swiss showed a stronger work ethic, were more resistant to change, were more risk averse, more accepting of bureaucracy, and more focused on quality. The Americans were more collegial, more willing to experiment and innovate, had a shorter time horizon, and communicated more openly. Dinsmore et al. (1993) list factors that they contend require special consideration by the PM heading a multicultural project. We have already noted some of these factors, and others are obvious: the importance of language and culture, the need to deal with the politics and politicians in the host nation, the fact that the PM may have to use indigenous staff members, the possibility of input supply and technology problems, and the need to obey local laws and customs. In addition, they note two other matters that may cause serious problems for the PM. First, there are additional risk factors such as kidnapping, disease, and faulty medical care. Of course, in many countries, project workers may face less risk from crime than in their home country as well as easier access to medical care. Second, the PM may have to provide for the physical and psychological needs of people who are transferred to the host nation and must live in a “strange land with different customs and way of life.” They refer to this as the “expatriate way of life.”

SUMMARY This chapter addressed the subject of the PM. The PM’s role in the organization and responsibilities to both the organization and the project team were discussed first. Common PM career paths were also described. Next, the unique demands typically placed on project managers were detailed and the task of selecting the PM was addressed. Last, the issue of culture and its effect on project communication and success was discussed.

The following specific points were made in the chapter. Two factors crucial to the success of the project are its support by top management and the existence of a problem orientation, rather than discipline orientation, within the team members. Compared to a functional manager, a PM is a generalist rather than a specialist, a synthesizer rather than an analyst, and a facilitator rather than a supervisor.

QUESTIONS

The PM has responsibilities to the parent organization, the project itself, and the project team. The unique demands on a PM concern seven areas:

• • • • • • •

Acquiring adequate physical resources Acquiring and motivating personnel Dealing with obstacles Making goal trade-offs Maintaining a balanced outlook in the team Communicating with all parties Negotiating

The most common characteristics of effective project team members are:

• • • •

High-quality technical skills Political sensitivity Strong problem orientation High self-esteem

To handle the variety of project demands effectively, the PM must understand the basic goals of the project, have the support of top management, build and maintain a solid

129

information network, and remain flexible about as many project aspects as possible. The best person to select as PM is the one who will get the job done. Valuable skills for the PM are technical and administrative credibility, political sensitivity, and an ability to get others to commit to the project, a skill otherwise known as leadership. Some important points concerning the impact of culture on project management are:

• • • •

Cultural elements refer to the way of life for any group of people and include technology, institutions, language, and art. The project environment includes economic, political, legal, and sociotechnical aspects. Examples of problematic cultural issues include the group’s perception of time and the manner of staffing projects. Language is a particularly critical aspect of culture for the project.

In the next chapter we consider the task of negotiating for the resources to implement the project plan and WBS, which will then complete our treatment of Part I: Project Initiation.

GLOSSARY Analytic Approach Breaking problems into their constituent parts to understand the parts better and thereby solve the problem. Benefit-Cost action.

A ratio to evaluate a proposed course of

Champion A person who spearheads an idea or action and “sells” it throughout the organization. Contingency Plan An alternative for action if the expected result fails to materialize. Culture The way of life of any group of people. Discipline An area of expertise. Environment Everything outside the system that delivers inputs or receives outputs from the system.

Facilitator A person who helps people overcome problems, either with technical issues or with other people. Functional One of the standard organization disciplines such as finance, marketing, accounting, or operations. Microculture The “corporate culture” within the organization, or even project. Systems Approach A wide-ranging, synthesizing method for addressing problems that considers multiple and interacting relationships. Commonly contrasted with the analytic approach. Technological Having to do with the methods and techniques for doing something. Trade-Off Allowing one aspect to get worse in return for another aspect getting better.

QUESTIONS Material Review Questions

1. How does the project act as a stepping-stone for the project manager’s career?

2. Name the categories of skills that should be considered in the selection of a project manager.

130

CHAPTER 3 / THE PROJECT MANAGER

3. Discuss the PM’s responsibilities toward the project team members. 4. What are the major differences between functional managers and project managers? 5. What are some of the essential characteristics of effective project team members? 6. What is the most important selection characteristic of a project manager? 7. What project goals are most important during the project life cycle stages?

8. Why must project management team members have good technical skills? 9. Describe each of the four elements of culture. 10. Identify some important types of project environments. 11. Contrast culture, microculture, and multiculture. 12. In what ways is language crucial in project management? 13. Identify the five multicultural factors requiring special consideration.

Class Discussion Questions

14. Can you think of several ways to assure “breadth of communication” in a project? Do you think “socialization” off the job helps or hinders? 15. Contrast the prime law for projects, “Never surprise the boss,” with the corporate adage “Bad news never travels up.” 16. How does a project manager, in some cases, work like a politician? 17. What are some of the conflicts that are bound to occur between parties that have legitimate interests in the project? 18. Project managers must be generalists rather than specialists. Yet, team members need to have more specialized, technical skills. Can a generalist manage a team of specialists effectively? 19. Why do you think cost drops in importance as an objective right after the formation stage? 20. Why is it more difficult to keep the project on its time and cost schedules the later the project gets in its life cycle? 21. Suppose you have a talented scientist temporarily working for you on a client contract who is due to be transferred back to her regular job. Although you could do without her efforts at this point of the contract, you happen to know that she will be laid off for lack of work at her regular job and her personal financial situation is dire. You feel it is important that her talent be kept on the company payroll, although keeping her on the contract will increase expenses unnecessarily. Is the transfer decision a business decision or an ethical one? Why? If the decision were yours to make, what would you decide? 22. How is communication through art different than through language? 23. What should a firm do when an accepted practice in a foreign country is illegal in its own country? 24. Do you agree that the trend now is to become less of a generic project manager and more of a specialist? If so,

then how do you gain a wide range of experience for that next job opportunity? The Project Management Career Path at AT&T

25. How difficult is it to change a culture where project management is perceived as of low status and something to get out of to one where project management is respected? How would you approach such a task? 26. What was the problem with the mentality of admiring heroic rescues of projects in trouble? 27. Compare the skills sought for project managers among BCS’s Leadership Continuity Plan with those listed in the chapter. The Wreckmaster at a New York Subway Accident

28. In what phase of the disaster plan does providing for alternate services probably occur? In what phase does bringing new equipment and supplies occur? 29. How much preplanning could be done for wrecks such as these in terms of disaster teams, command center locations, task sequencing, and so on? 30. What experience credentials does NYCTA look for in appointing wreckmasters? Success at Energo by Integrating Two Diverse Cultures

31. What was the key to solving this dilemma? 32. How did the two PMs implement their strategy? 33. What actions in Exhibit 1 might have been key to making this project a success? A Surprise “Director of Storm Logistics” for Katrina

34. Why do you think Wilson was appointed Director? 35. What would have been the first set of tasks Wilson would have considered after requesting help? Growing Stress at Twitter

36. Which of Kent’s 6 ways to keep stress under control do you think might work for a project manager at Twitter? 37. Would you like Norlen’s job? Why (not)? 38. Is it possible in a fast-growth company to avoid stress?

INCIDENTS FOR DISCUSSION

131

INCIDENTS FOR DISCUSSION Smithson Company

Keith Smithson is the CEO of the Smithson Company, a privately owned, medium-size computer services company. The company is 20 years old and, until recently, had experienced rapid growth. Mr. Smithson believes that the company’s recent problems are closely related to the depressed Asian economy. Brianna Smatters was hired as the director of corporate planning at Smithson six months ago. After reviewing the performance and financial statements of Smithson for the last few years, Ms. Smatters has come to the conclusion that the economic conditions are not the real problem, but rather exacerbate the real problems. She believes that in this Internet era, Smithson Company’s services are becoming obsolete but the department heads have not been able to cooperate effectively in reacting to information technology threats and opportunities. She believes that the strong functional organization impedes the kinds of action required to remedy the situation. Accordingly, she has recommended that Mr. Smithson create a new position, manager of special operations, to promote and use project management techniques. The new manager would handle several critical projects in the role of project manager. Mr. Smithson is cool to the idea. He believes that his functional departments are managed by capable professional people. Why can’t these high-level managers work together more efficiently? Perhaps a good approach would be for him to give the group some direction (what to do, when to do it, who should do it) and then put the functional manager most closely related to the problems in charge of the group. He assumes that the little push from him (Smithson) as just described would be enough to “get the project rolling.” Questions: After this explanation Ms. Smatters is more convinced than ever that a separate, nonfunctional project manager is required. Is she right? If you were Smatters, how would you sell Mr. Smithson on the idea? If a new position is created, what other changes should be made?

remove excess mucus from a patient’s airway. These rooms must also be connected to an emergency generator that automatically starts and supplies electrical current if the main electrical supply fails. Finally, pressure sensors must be connected from each ventilator unit to a sound device located in the hallway of the ventilator wing. These units sound a strident signal and cause a hallway light to flash if there is a sharp drop in the airway pressure of a ventilator patient. In addition to these power needs associated with ventilator patients, power outlets are also needed for several machines that dispense tube feedings of medicines and nutrition, and for IVs, radios, and similar entertainment devices. Each bed itself needs a power outlet as does the air mattress pump. Because all rooms are double occupancy, each room needs two full sets of the outlets. The equipment noted above is normally plugged in at all times when the patient is in his or her room. Otherwisewell patients, however, are moved daily into a “day room” equipped with a large screen TV and chairs and tables. Most patients must be moved with their portable ventilators and concentrators or bottled oxygen. Patients who are well enough, eat their meals in the day room and socialize with each other and with visitors. (The socialization is a quiet process because a large majority of the patients breathe through a tube inserted in their trachea and are unable to speak aloud.) The Senior Administrator, Steve Murphy, has decided to set up the conversion process as a project. Mr. Murphy is considering the choice of a project manager. He is trained in business, not hospital design. He feels a Registered Nurse or Licensed Practical Nurse might be an appropriate PM. He also feels that a Respiratory Therapist (RT) might be a good choice because RTs are responsible for using the major electrical equipment. Finally, he thinks that the installation and placing of all the outlets might be better handled by a representative of the electrical contractor who must carry out the major part of the room conversion. Questions: Who should Mr. Murphy choose? Defend your choice.

Newcastle Nursing and Rehabilitation Residence

International Microcircuits, Inc.

The Newcastle Nursing and Rehabilitation Residence (NNRR) is a 135-bed skilled nursing home. NNRR is considering converting a 36-bed wing of their main building for use by patients who require ventilator-assisted breathing. The rooms will be slightly smaller than optimum for ventilator patients, but just exceed the recommended minimum square footage. Enlarging the rooms is not an economic option. In the main, the conversion will require the addition of electrical wiring to power oxygen-concentrators that extract 95 percent pure oxygen from room air, portable ventilators that supply the oxygen under pressure to assist breathing, and small, motor-driven suction devices to

Megan Bedding, vice-president of sales for International Microcircuits, Inc. (IM), was delighted when IM was one of the few firms invited to enter a bid to supply a large industrial customer with their major product in a small foreign country. However, her top salesperson for that region had just called and informed her of certain “expectations” of doing business in the country: 1. Local materials representing at least 50 percent of the product’s value must be purchased in reciprocity. 2. The local politicians will expect continual significant donations to their party.

132

CHAPTER 3 / THE PROJECT MANAGER

3. Industrial customers normally receive a 40 percent “rebate” (kickback) when they purchase goods from suppliers such as IM. (IM’s profit margin is only 20 percent.)

a lot of effort would be wasted as well as a chance to get a foothold in the international market. But if she proceeded, how could these expectations be met in a legal and ethical way?

With this new information, Megan was unsure about changing or proceeding with the bid. If it was withdrawn,

Question: Devise a solution that addresses Megan’s concerns.

CONTINUING INTEGRATIVE CLASS PROJECT The task for the class now is to select a project manager. But heed the advice given in the chapter that the best PM is the one “who can get the job done,” not the one who is just “available.” This is a particularly dangerous pitfall for a class project where everyone is busy and no one had expected to be called upon to lead a major project. And resist the temptation of naming two people as co-PMs— that rarely works unless these people have a history of working well together in previous projects. With two PMs, no one knows who is responsible for what and tasks may fall through the cracks. In theory, the work of the PM should be no more, and possibly less, than the other members of the class, especially if the project is well organized

and well run. The main responsibilities of the PM (and perhaps in concert with subteam heads) are to organize the project, schedule the tasks, and stay on top of progress. However, if problems, or maybe personality feuds, crop up, the PM may find these are taking a lot more time than was expected. When a PM is finally selected, it is important for the class, and especially any subteam heads, if such exist, to give full allegiance to the PM in getting the work done and upholding the workload they agreed to handle. Bear in mind also that there will probably be one or more people in the class who will need to do more than their fair share of the work because of unexpected problems that crop up during the term.

BIBLIOGRAPHY Barry, V. Moral Issues in Business. Belmont, CA: Wadsworth, 1979. Blanchard, K., and N. V. Peale. The Power of Ethical Management. New York: Morrow, 1988. Dinsmore, P. C., and M. M. B. Codas. “Challenges in Managing International Projects.” In P. C. Dinsmore, ed., The AMA Handbook of Project Management. New York: AMACOM, 1993. Dodson, W. R. “Virtually International.” PM Network, April 1998. Dulewicz, V., and M. J. Higgs. “Design of a new instrument to assess leadership dimensions & styles.” In Henley Working Paper HWP 0311, Henley Management College, Henley-on-Thames, UK. 2003. Fedor, K. J., and W. B. Werther, Jr. “The Fourth Dimension: Creating Culturally Responsive International Alliances.” IEEE Engineering Management Review, Fall 1997, as reprinted from Organizational Dynamics, Autumn 1996. Ford, R. C., and F. S. McLaughlin. “Successful Project Teams: A Study of MIS Managers.” IEEE Transactions on Engineering Management, November 1992. Foti, R. “Today’s Project Manager.” PM Network, April 2003.

Gagnon, R. J. An Exploratory Analysis of the Relevant Cost Structure of Internal and External Engineering Consulting, Ph.D. dissertation. Cincinnati: University of Cincinnati, 1982. Gagnon, R. J., and S. J. Mantel, Jr. “Strategies and Performance Improvement for Computer-Assisted Design.” IEEE Transactions on Engineering Management, November 1987. Gogal, H. C., and L. R. Ireland. “Project Management: Meeting China’s Challenge.” Project Management Journal, February 1988. Grinbergs, A., and A. H. Rubenstein. “Software Engineering Management: A Comparison of Methods in Switzerland and the United States.” IEEE Transactions on Engineering Management, February 1993. Green, S. G. “Top Management Support of R&D Projects: A Strategic Leadership Perspective.” IEEE Transactions on Engineering Management, August 1995. Hauptman, O., and K. K. Hirji. “The Influence of Process Concurrency on Project Outcomes in Product Development: An Empirical Study of Cross-Functional Teams.” IEEE Transactions on Engineering Management, May 1996.

BIBLIOGRAPHY

Herzberg, F. H. “One More Time: How Do You Motivate Employees?” Harvard Business Review, January– February 1968. Hughes, T. P. Rescuing Prometheus. New York, Pantheon, 1998. Hunsberger, K. “Juggling Act.” PM Network, September 2008. Ireland, L. R., W. J. Pike, and J. L. Schrock. “Ethics for Project Managers.” Proceedings of the 1982 PMI Seminar/Symposium on Project Management, Toronto, Ontario, Canada. Jiang, J. J., G. Klein, and S. Margulis. “Important Behavioral Skills for IS Project Managers: The Judgments of Experienced IS Professionals.” Project Management Journal, March 1998. Kalu, T. C. U. “A Framework for the Management of Projects in Complex Organizations.” IEEE Transactions on Engineering Management, May 1993. Kent, S. “Stretched Thin.” PM Network, April 2008. Kloppenborg, T J., and S. J. Mantel, Jr. “Trade-offs on Projects: They May Not Be What You Think.” Project Management Journal, March 1990. Kotter, J. P. “What Effective General Managers Really Do.” Harvard Business Review, November–December 1982. Levinson, N. S., and M. Asahi. “Cross-National Alliances and Interorganizational Learning.” IEEE Engineering Management Review, Fall 1997, as reprinted from Organizational Dynamics, Autumn 1995. Lynn, L. H., and T. J. McKeown. Organizing Business: Trade Associations in America and Japan. Washington, D.C.: American Enterprise Institute for Public Policy Research, 1988. The AMA Handbook of Project Management. New York: AMACOM, 1993. Matson, E. “Congratulations, You’re Promoted” and “Project: You.” Fast Company, as reprinted in Engineering Management Review, Winter 1998. Medcof, J. W., J. Hauschildt, and G. Keim. “Realistic Criteria for Project Manager Selection and Development.” Project Management Journal, September 2000. Mintzberg, H. The Nature of Managerial Work. New York: Harper & Row, 1973. Müller, R., and R. Turner. “Leadership Competency Profiles of Successful Project Managers.” International Journal of Project Management, Vol 28, 2010. Nixon, M. A. “Legal Lights: Business Ethics.” Project Management Journal, September 1987. Norrie, J. and D. H. T. Walker. “A Balanced Scorecard Approach to Project Management Leadership.” Project Management Journal, December 2004.

133

Pastin, M. The Hard Problems of Management. San Francisco: Jossey-Bass, 1986. Patterson, N. “Selecting Project Managers: An Integrated List of Predictors.” Project Management Journal, June 1991. Pill, J. Technical Management and Control of Large Scale Urban Studies: A Comparative Analysis of Two Cases, Ph.D. dissertation. Cleveland: Case Western Reserve University, 1971. Pinto, J. K., and D. P. Slevin. “The Project Champion: Key to Implementation Success.” Project Management Journal, December 1989. Project Management Institute. “Slow Motion,” PM Network, April 2005, p. 1. Robb, D. J. “Ethics in Project Management: Issues, Practice, and Motive.” PM Network, December 1996. Rosegger, G., and S. J. Mantel, Jr. “Competitors as Consultants: Collaboration and Technological Advance.” In J. Allesch, ed., Consulting in Innovation: Practice, Methods, Perspectives. Amsterdam: Elsevier, 1990. Sahlin, J. P. “How Much Technical Training Does a Project Manager Need?” PM Network, May 1998. Schaefer, A. G., and A. J. Zaller. “The Ethics Audit for Nonprofit Organizations.” PM Network, March 1998. Scott, S. G., and R. A. Bruce. “Following the Leader in R&D: The Joint Effect of Subordinate ProblemSolving Style and Leader-Member Relations on Innovative Behavior.” IEEE Transactions on Engineering Management, February 1998. Shenhar, A. J. “From Theory to Practice: Toward a Typology of Project-Management Styles.” IEEE Transactions on Engineering Management, February 1998. Slevin, D. P. The Whole Manager. New York: AMACOM, 1989. Smith, L. A., and J. Haar. “Managing International Projects.” In P. C. Dinsmore, ed., The AMA Handbook of Project Management. New York: AMACOM, 1993. Tannenbaum, R., and F. Massarick. “Leadership: A Frame of Reference.” Management Science, October 1957. The World Book. Chicago: Field Enterprises, 1997. Whitten, N. “Attributes of the Successful Project Leader.” PM Network, June 1996. Zimmerer, T. W., and M. M. Yasin. “A Leadership Profile of American Project Managers.” Project Management Journal, March 1998. Zupek, R. “Sun Sets on Silicon Valley?” PM Network, May, 2010.

134

CHAPTER 3 / THE PROJECT MANAGER

The following case involves a project manager who stumbles into a public project somewhat by accident. The project starts out as one thing and evolves into something else. Acquiring sufficient resources for the project is a major difficulty, and competition may be troublesome also. A consultant is hired who conducts two surveys to gather more information and makes recommendations based on the survey evidence and experience. The case illustrates the varied skills necessary to be a successful project manager and the myriad opportunities/difficulties some projects entail.

C

A

S

E

THE NATIONAL JAZZ HALL OF FAME* Cornelis A. de Kluyver, J. Giuliano, J. Milford, and B. Cauthen Mr. Robert Rutland, founder of the National Jazz Hall of Fame, poured himself another drink as he listened to some old jazz recordings and thought about the decisions facing him. Established about one year ago, the National Jazz Hall of Fame (NJHF) had achieved moderate success locally but had not yet attracted national recognition. Mr. Rutland wondered how much support existed nationally, what services the NJHF should provide and for whom, and what the NJHF should charge for those services. He also thought about other jazz halls of fame and their implications for the NHJF. Although he had engaged an independent consultant to find some answers, the questions still lingered. Jazz The word “jazz,” according to Dr. David Pharies, a linguistics scholar at the University of Florida, originally meant copulation, but later identified a certain type of music. Amid the march of funeral bands, jazz music began in New Orleans in the early 1900s by combining Black spirituals, African rhythms, and Cajun music; Dixieland jazz became the sound of New Orleans. Jazz traveled from New Orleans, a major trade center, on river boats and ships and reached St. Louis, Kansas City, Memphis, Chicago, and New York. Musicians in these cities developed local styles of jazz, all of which remained highly improvisational, personal, and rhythmically complex. Over the years, different sounds emerged—swing, big band, be bop, fusion, and others—indicating the fluidity and diversity of jazz. Jazz artists developed their own styles and competed with one another for recognition of their musical ability and compositions. Such diversity denied jazz a simple definition, and *Reprinted with permission. Copyright the Darden Graduate Business School Foundation, Charlottesville, VA.

opinions still differed sharply on what exactly jazz was. It was difficult, however, to dispute Louis Armstrong’s statement that “if you have to ask what jazz is, you’ll never know.” Origins of the National Jazz Hall of Fame Mr. Rutland, a history professor at the University of Virginia, which is in Charlottesville, discovered that renovation plans for the city’s historic district excluded the Paramount Theatre, a local landmark. The Paramount was constructed in the 1930s and used as a performance center and later as a movie theatre. It was closed in the 1970s and now was in danger of becoming dilapidated. Alarmed by the apparent lack of interest in saving the Paramount, Mr. Rutland began to look for opportunities to restore and eventually use the theatre. The most attractive option to him was to establish a jazz hall of fame that would use the theatre as a museum and performance center; this would capitalize on the theatre’s name, because the Paramount Theatre in New York City was a prominent jazz hall during the 1930s and 1940s. Mr. Rutland mentioned his idea—saving the theatre by establishing a jazz hall of fame—to several friends in Charlottesville. They shared his enthusiasm, and together they incorporated the National Jazz Hall of Fame and formed the board of directors in early 1983. A few prominent jazz musicians, such as Benny Goodman and Chick Corea, joined the NJHF National Advisory Board. The purpose of the NJHF was to establish and maintain a museum, archives, and concert center in Charlottesville to sponsor jazz festivals, workshops, and scholarships, and to promote other activities remembering great jazz artists, serving jazz enthusiasts, and educating the public on the importance of jazz in American culture and history.

CASE

The First Year’s Efforts Immediately after incorporation, the directors began their search for funds to save the Paramount and to establish the NJHF, and soon encountered two difficulties. Philanthropic organizations refused to make grants because no one on the board of directors had experience in a project like the NJHF. In addition, government agencies such as the National Endowment for the Arts and the National Endowment for the Humanities considered only organizations in operation for at least two years. However, some small contributions came from jazz enthusiasts who had read stories about the NJHF in Billboard, a music industry magazine, and in the Charlottesville and Richmond newspapers. By mid-1983, the board of directors discovered that to save the Paramount at least $600,000 would be needed, a sum too large for them to consider. They decided, however, that out of their love for jazz they would continue to work to establish the NJHF in Charlottesville. Despite these setbacks, Mr. Rutland and the other directors believed that the first year’s activities showed promise. The NJHF sponsored three concerts at local high schools. The concerts featured such jazz greats as Maxine Sullivan, Buddy Rich, and Jon Hendricks and Company, and each concert attracted more than 500 people. Although the NJHF lost some money on each concert, the directors thought that the concerts succeeded in publicizing and promoting the NJHF. In addition, a fundraiser at a Charlottesville country club brought $2,000 to the NJHF, and Mr. Rutland started the NJHF newsletter. The collection of objects for the museum was enlarged, and Louis Armstrong and Duke Ellington were posthumously inducted into the NJHF. At the end of the first year, enthusiasm among board members was still high, and they believed that the NJHF could survive indefinitely, albeit on a small scale. But a Hall of Fame in Charlottesville . . . Mr. Rutland believed that a hall of fame could succeed in Charlottesville, though other cities might at first seem more appropriate. More than 500,000 tourists annually were attracted to Charlottesville (1980 population: 40,000) to visit Thomas Jefferson’s home at Monticello, James Monroe’s home at Ash Lawn, and the Rotunda and the Lawn of the University of Virginia, where total enrollment was 16,000. Mr. Jefferson designed the Rotunda and the buildings on the Lawn and supervised their construction. The Virginia Office of Tourism promoted these national landmarks as well as the city’s two

135

convention centers. In addition, 13 million people lived within a three-hour drive of Charlottesville. If Charlottesville seemed illogical for a hall of fame, Mr. Rutland reasoned, so did Cooperstown, New York, home of the Baseball Hall of Fame and Canton, Ohio, location of the Professional Football Hall of Fame. He thought that successful jazz festivals in such different places as Newport, Rhode Island, and French Lick, Indiana, showed that location was relatively unimportant for jazz. Moreover, a Charlottesville radio station recently switched to a music format called “Memory Lane,” which featured classics by Frank Sinatra, Patti Page, the Mills Brothers, the Glenn Miller Orchestra, and numerous others. The station played much jazz, and won the loyalty of many jazz enthusiasts in the Charlottesville area. The success of “Memory Lane” indicated to Mr. Rutland that the Charlottesville community could provide the NJHF with a base of interest and loyalty. Most important, Mr. Rutland believed that he and his friends possessed the commitment necessary to make a jazz hall of fame succeed. . . . And Halls of Fame in Other Cities? Although no national organization operated successfully, several local groups claimed to be the Jazz Hall of Fame, as Billboard magazine reported.

*** Billboard 4/28/84 HALL OF FAME IN HARLEM

by Sam Sutherland and Peter Keepnews CBS Records and the Harlem YMCA have joined forces to establish a Jazz Hall of Fame. The first induction ceremony will take place on May 14 at Avery Fisher Hall, combined with a concert featuring such artists as Ramsey Lewis, Hubert Laws, Ron Carter, and an all-star Latin Jazz ensemble. Proceeds from the concert will benefit the Harlem YMCA. Who will the initial inductees be, and how will they be chosen? What’s being described in the official literature as “a prestigious group of jazz editorialists, critics, producers, and respected connoisseurs” (and, also, incidentally, musicians—among those on the panel are Miles Davis, Dizzy Gillespie, Cab Calloway, Max Roach and the ubiquitous Dr. Billy Taylor) will do the actual selecting, but nominations are being solicited from the general public. Jazz lovers are invited to submit the names of six artists, three

136

CHAPTER 3 / THE PROJECT MANAGER

living and three dead, to: The Harlem YMCA Jazz Hall of Fame, New York, NY 10030. Deadline for nominations is May 1. Billboard, 5/19/84 ONE, TWO, MANY HALLS OF FAME?

by Sam Sutherland and Peter Keepnews Monday night marks the official launch of the Harlem YMCA Jazz Hall of Fame (Billboard, April 28), a project in which CBS Records is closely involved. The Hall’s first inductees are being unveiled at an Avery Fisher Hall concert that also includes performances by, among others, Sarah Vaughan and Branford Marsalis. The project is being touted as the first jazz hall of fame, a statement that discounts a number of similar projects in the past that never quite reached fruition. But first or not, the good people of CBS and the Harlem YMCA are apparently in for some competition. According to a new publication known as JAMA, the Jazz Listeners/Musicians Newsletter, Dizzy Gillespie—who also is a member of the Harlem YMCA Jazz Hall of Fame committee—“promised in Kansas City, Mo. to ask musicians for help in establishing an International Jazz Hall of Fame” in that city. The newsletter quotes Gillespie, whom it describes as “honorary chairman of the proposed hall,” as vowing to ask “those musicians who were inspired by jazz”—among them Stevie Wonder, Quincy Jones and Paul McCartney (?)—to contribute financially to the Kansas City project, which, as envisioned by the great trumpeter, would also include a jazz museum, classrooms and performance areas. Is there room for two Jazz Halls of Fame? Do the people involved in the New York city project know about the Kansas City project, and vice versa? (Obviously Gillespie does, but does anyone else?) Remember the New York Jazz Museum? Remember the plaques in the sidewalk on 52nd Street (another CBS Records brainchild)? The notion of commemorating the contributions of the great jazz musicians is a noble one. It would be a shame to see the energies of the jazz community get diverted into too many different endeavors for accomplishing the same admirable goal—which, unfortunately, is what has tended to happen in the past.

Billboard, 5/26/84 Also noted: the first inductees in the Harlem YMCA Jazz Hall of Fame (Billboard, May 19) have been announced. The posthumous inductees are, to nobody’s great surprise, Louis Armstrong, Duke Ellington, Count Basie, Charlie Parker, and—a slight surprise, perhaps— Mary Lou Williams. The living honorees are Roy Eldridge, Dizzy Gillespie, Miles Davis, Ella Fitzgerald and Art Blakey. *** The New York Jazz museum (which the 5/19/84 article referred to) was established in the early 1970s but quickly ran out of money and was closed a few years later. In the early 1960s, a jazz museum was established in New Orleans and because of insufficient funds, all that remained was the Louis Armstrong Memorial Park, the site of an outdoor jazz festival each summer. Tulane and Rutgers universities each possessed extensive archives containing thousands of phonograph records, tape recordings, posters, books, magazines, journals, and other historic pieces and memorabilia. Neither university, however, considered its archives a hall of fame. Other Halls of Fame The more prominent halls of fame in the U.S. were the Baseball, the Professional Football, the College Football, and the Country Music Hall of Fame. These and many other halls of fame were primarily concerned with preserving history by collecting and displaying memorabilia, compiling records, and inducting new members annually. Mr. Rutland visited most of the other halls of fame and learned that they were usually established by a significant contribution from an enthusiast. In the case of the Country Music Hall of Fame, some country music stars agreed to make a special recording of country hits and to donate the royalties to the organization. Mr. Rutland was especially interested in The Country Music Hall of Fame because of similarities between country music and jazz. Country music, like jazz, had a rich cultural history in America, and neither type of music was the most popular in the U.S. The Country Music Hall of Fame (CMHF) was established in 1967 in Nashville after a cooperative fundraising effort involving the city, artists, and sponsors. By 1976, the CMHF included a museum, an archives, a library, and a gift shop. More than one-half million people

CASE

visited the CMHF in 1983, partly because of the nearby Grand Ole Opry, the premier concert hall for country music where the Grand Ole Opry cable radio broadcasts originated. Of the CMHF’s $2.1 million annual budget, 85 percent came from admissions, 10 percent from sales at the gift shop and by mail, and 5 percent from donations. In the past two years, the CMHF had formed the Friends of Country Music, now more than 2,000 people who donated $25 each per year and who received a country music newsletter every three months and discounts on CMHF merchandise.

The National Association of Jazz Educators Mr. Rutland was uncertain how much and what type of support he could get from the National Association of Jazz Educators. This organization, with 5,000 members, primarily coordinated and promoted jazz education programs. Performance programs were normally offered through music departments. Most high schools and colleges had bands that played a variety of jazz arrangements as part of their repertoire. Band conductors usually had a music degree from a major university and belonged to the National Association of Jazz Educators. Most of the jazz appreciation courses offered in schools throughout the U.S. treated jazz as a popular art form, as a barometer of society, rather than as a subject of interest in itself. Some educators believed that jazz greats such as Louis Armstrong and Duke Ellington should be honored not as jazz musicians, but as composers like George Gershwin and Richard Rogers. Indeed, a prominent jazz historian told Mr. Rutland that jazz might benefit more from breaking down this

Exhibit 1.

distinction between jazz artists and composers than from reinforcing it. The National Survey To get some of the answers to his many questions, Mr. Rutland engaged an independent consultant who conducted two surveys; the first was a national survey and the second a tourist survey. For the national survey, the consultant designed a questionnaire to gauge the respondent’s level of interest in both jazz and the concept of a National Jazz Hall of Fame, and to determine the respondent’s demographics. A sample size of 1,300 was used and the mailing covered the entire continental United States. The mailing list, obtained from the Smithsonian Institution in Washington, DC, contained names and addresses of people who had purchased the “Classic Jazz Record Collection,” as advertised in Smithsonian magazine. Of the 1,300 questionnaires, 440 were sent to Virginia residents and 860 to residents of other states in order to provide both statewide and national data. Of the questionnaires that went to other states, the majority was targeted toward major cities and apportioned according to the interest level for jazz in each city as indicated by the circulation statistics of Downbeat, a jazz magazine. Of the 860 questionnaires sent to the other states, 88 were sent to residents of Chicago, 88 to Detroit, 83 to New York City, 60 to San Francisco, 56 to Philadelphia, 56 to Washington, DC, 52 to Los Angeles, 46 to Charlotte, 46 to Miami, 45 to Dallas, 42 to Atlanta, 42 to Houston, 30 to Denver, 28 to Kansas City, 28 to New Orleans, 28 to St. Louis, 27 to Boston, and 15 to Seattle. Of the 1,300 questionnaires, 165, or 12.7 percent, were returned. As shown in Exhibit 1, 79 percent of the respondents were 35 years of age or older, 73 percent were male, and

Survey Results: Demographics of Respondents

Demographics

Age—35 Sex—Male Education—Grad. Job—Professional Income—$50,000 Non-profit Contr. $200/year

137

Percentage of Respondents

Percentage of All Record Buyers*

Census Data**

79 73 54 57 50 75

37 82 24*** 26 23

43 49 31 22 7

*Source: Consumer Purchasing of Records and Pre-recorded Tapes in the U.S., 1970–1983, Recording Industry Association of America. **Source: U.S. Department of Commerce, Bureau of the Census, 1982. ***Source: Simmons Market Research Bureau, 1982.

138

CHAPTER 3 / THE PROJECT MANAGER

collect information on attractions nearby and throughout the state. The respondents came from all areas of the country, and most were traveling for more than one day. Almost 70 percent said they like jazz, mostly Dixieland and big band, and more than 60 percent indicated they would visit a Jazz Hall of Fame. The average admission they suggested was $3.50 per person.

the majority were well-educated, professionals, and had an annual income of more than $50,000. Of interest also was that 75 percent of the respondents contributed $200 or more per year to different non-profit organizations. Since the sample included a large number of record buyers of age 50 or older, the consultant weighted the survey results with age data obtained from the Recording Industry Association of America to make the survey results representative of all jazz-record buyers. The survey also showed in Exhibit 2 that swing was the most popular form of jazz, followed by Dixieland, and then more traditional forms of jazz, from which the consultant concluded that a nostalgic emphasis should gather support from jazz enthusiasts of all ages, and that later, the National Jazz Hall of Fame could promote more contemporary forms of jazz. As for services, the survey suggested in Exhibit 3 that respondents most wanted a performance center or concert hall. A museum and seminars were also popular choices. The consultant was surprised by the strong interest in information about jazz recordings because the average respondent did not buy many records. A newsletter was rated relatively unimportant by most respondents. Most gratifying for Mr. Rutland was that respondents on average were willing to contribute between $20.00 and $30.00 per year to the National Jazz Hall of Fame, with a weighted average contribution of $23.40.

The Consultant’s Recommendations The consultant limited his recommendations to the results of the two surveys. As a result, the question of whether the efforts in other cities to establish a National Jazz Hall of Fame would make the Charlottesville project infeasible was still unresolved. In a private discussion, however, the consultant intimated that “if the other efforts are as clumsily undertaken as many of the previous attempts, you will have nothing to worry about.” He thought it was time that a professional approach was taken toward this project. Specifically, he made three recommendations: 1. Launch a direct mail campaign to the 100,000 people on the Smithsonian jazz mailing list. The focus of the mailing should be an appeal by a jazz great such as Benny Goodman to become a Founding Sponsor of the National Jazz Hall of Fame. He estimated that the cost of the campaign would range between $25,000 and $30,000; however, with an average contribution of $25.00 per respondent, a response rate of only 2 percent would allow the National Jazz Hall of Fame to break even. 2. Appoint a full-time executive director with any funds exceeding the cost of the mailing. The principal responsibilities of the executive director would be to

The Tourist Survey In addition to conducting the National Survey, the consultant developed a questionnaire and interviewed approximately 100 tourists to the Charlottesville area at the Western Virginia Visitors Center near Monticello. About 140,000 tourists stopped at the center annually to

Exhibit 2.

Survey Results: Preferences for Different Styles of Jazz

Type of Interest

General Interest in Music Dixieland Swing Traditional Improvisational Jazz Rock Fusion Pop Jazz Classical

62 87 63 41 25 15 27 68

71 70 81 66 48 47 9 53 73

CASE

Exhibit 3.

139

Survey Results: Preferences for Services Offered Percentage of Respondents Answering with a 4 or 5 Rating

Weighted Percentage of Respondents Answering with a 4 or 5 Rating

Performance Center Concert Hall Artist Seminars Nightclub Museum Tourist Center Audio-Visual Exhibitions Shrine Educational Programs Record Information History Seminars Member Workshops Lounge

70 66 50 52 57 42 57 55 48 71 38 25 37

83 79 62 57 57 48 55 52 51 69 54 34 45

Financial Support: at $10.00/year at $20.00/year at $30.00/year

17 30 15

13 26 25

Number of Contributors

62

64

Service

organize and coordinate fundraising activities, to establish a performance center and museum, and to coordinate the collection of memorabilia and other artifacts. 3. Promote the National Jazz Hall of Fame at strategic locations around Charlottesville to attract tourists and other visitors. The Western Virginia Visitors Center was a prime prospect in his view for this activity. He calculated that 50,000 tourists annually at $3.00 each would provide sufficient funds to operate and maintain the National Jazz Hall of Fame. The consultant also identified what he considered the critical elements for his plan’s success. First, the National Jazz Hall of Fame should be professional in all of its services and communications to jazz enthusiasts. Second, the executive director should have prior experience in both fundraising and direct mail; he should have a commitment to and love for jazz, as well as administrative skill and creativity. Third,

the National Jazz Hall of Fame should communicate frequently with Founding Sponsors to keep their interest and excitement alive. Finally, to ensure the enthusiastic cooperation of city officials, local merchants, and the Charlottesville community, he thought that more local prominence for the National Jazz Hall of Fame would prove indispensable. The National Jazz Hall of Fame—Dream or Reality As he paged through the consultant’s report, Mr. Rutland wondered what to make of the recommendations. While he was encouraged by a national base of support for his idea, he was unsure how the Board of Directors would react to the consultant’s proposals. With less than $2,500 in the bank, how would they get the necessary funds to implement the plan? Yet he knew he had to make some tough decisions, and quickly, if he wanted to make his dream a reality.

140

CHAPTER 3 / THE PROJECT MANAGER

QUESTIONS 1. What is the project Mr. Rutland is trying to manage? Has it stayed the same? 2. Identify the various stakeholders in the project, including the competition. 3. Of the skills mentioned in the chapter that a project manager needs, which are most important here? Why? 4. What credibility does Mr. Rutland have? Is he a leader? 5. What cultures are relevant to this project? Describe the project environment.

6. What should Mr. Rutland do? Include the following issues: • Budget: acquiring adequate resources – philanthropic organizations – governmental agencies – donations – memberships – visitors • Budget: expenditures (consider Paramount theatre) • Performance: services/activities to offer • Competition • Schedule: deadlines, windows, milestones

The following reading integrates two views about the requirements for good project managers. One view concerns the personal and managerial characteristics of PMs and their ability to lead a team, regardless of the project. The other view considers the critical problems in the project in question and the PM’s talents relative to these problems. A survey is first described and then the critical problems that projects face are identified from the survey responses. Next, the skills required of project managers, as indicated by the survey respondents, are detailed. Last, the skills are related back to the critical project problems for an integrated view of the requirements for a successful project manager.

D I R E C T E D

R E A D I N G

WHAT IT TAKES TO BE A GOOD PROJECT MANAGER* B. Z. Posner Selecting a good project manager is not a simple task. Being an effective project manager is an ongoing challenge. The complex nature and multifaceted range of activities involved in managing projects precludes easily identifying managerial talent and continually stretches the capabilities of talented project managers. Two seemingly contradictory viewpoints have been advanced about what is required to be a good project manager. One perspective prescribes a set of personal characteristics necessary to manage a project [1]. Such personal attributes include aggressiveness, confidence, poise, decisiveness, resolution, entrepreneurship, toughness, integrity, versatility, multidisciplinarity, and quick thinking. However, Daniel Roman [2] maintains that it would take an extraordinary individual to have all of these critical *Reproduced from Project Management Journal with permission. Copyright Project Management Institute.

personal characteristics. A more practical solution, he suggests, would be to determine the critical problems faced by project managers and to select a person who can handle such difficulties. The shortcoming with this second perspective, argue those like Michael Badaway [3], is that the primary problems of project managers are really not technical ones. The reason managers fail at managing projects, he contends, is because they lack critical organization and management skills. Scholars like Roman and Badaway—as well as practitioners—may actually be raising different issues. On the one hand, good project managers understand the critical problems which face them and are prepared to deal with them. On the other hand, managing projects well requires a set of particular attributes and skills. But, are these two viewpoints really at odds with one another? In this study they were discovered to be two sides of the same coin!

DIRECTED READING

Study of Project Manager Problems and Skills Questionnaires were completed by project managers during a nationwide series of project management seminars. Project managers attending these seminars came from a variety of technology-oriented organizations. Responses to the survey instrument were both voluntary and confidential. Information about the respondents and the nature of their projects was collected. The typical project manager was a 37-year-old male, had nine people reporting to him, and was responsible for a small to moderate size project within a matrix organization structure. More specifically, there were 189 men and 98 women in the sample (N 287) and their ages ranged from 22 to 60 years of age (X 37.4, S.D. 8.3). Fifty-six percent indicated that they were the formal manager of the project. The size of their immediate project group ranged from 2 to over 100 people (median 8.9). Fifty-nine percent reported that they worked primarily on small projects (involving few people or functions, with a short time horizon) as compared to large projects (involving many people or functions, with a long time horizon). More than 63 percent indicated they were working within a matrix organization structure. No information was collected about the specific nature (e.g., new product development, R & D, MIS) of their projects. Two open-ended questions were asked (their order was randomized). The first asked about the skills necessary to be a successful project manager. The second question investigated the most likely problems encountered in managing projects. Responses to these questions were content analyzed. Content analysis is a systematic approach to data analysis, resulting in both qualitative assessments and quantitative information. Each respondent comment was first coded and then recoded several times as patterns of responses became apparent. The two questions were: 1. What factors or variables are most likely to cause you problems in managing a project? 2. What personal characteristics, traits, or skills make for “above average” project managers? What specific behaviors, techniques, or strategies do “above average” project managers use (or use better than their peers)? Problems in Managing Projects. There were nearly 900 statements about what factors or variables created “problems” in managing a project. Most of these statements could be clustered into eight categories as shown in Table 1. Inadequate resources was the issue most frequently mentioned as causing problems in managing a project. “No matter what the type or scope of your project,” wrote one engineering manager, “if insufficient resources are allocated to the project, you have to be a magician to be successful.” Not having the necessary budget or personnel for the project was a frequent complaint. However, the specific resource of

141

time—and generally the lack thereof—was mentioned just about as often as the general inadequate resource lament. Typically, the problem of time was expressed as “having to meet unrealistic deadlines.” That resources are inadequate is caused by many factors, not the least of which being that resources are generally limited and costly. Before this hue is dismissed by veteran project managers as just so much bellyaching—”after all, there are never enough resources to go around”—it is important to examine the cause(s) of this problem. Respondents pointed out that resource allocation problems were usually created by senior management’s failure to be clear about project objectives, which in turn resulted in poor planning efforts. These two problems—lack of clear goals and effective planning—were specifically mentioned by more than 60 percent of the respondents. It is painfully obvious that vague goals and insufficient planning lead to mistakes in allocating the resources needed by project managers.

Table 1 Project Management Problems

The three most significant problems reported by firstline research, development, and engineering supervisors in Lauren Hitchcock’s [4] study parallels those identified by project managers. He found “insufficient definition of policy from top downward, how to define the goal of a problem, and budgeting and manpower assignments” to be the major problems confronting supervisors. It remains true that senior management needs to articulate clearly where the project should be going, why, and what it expects from project personnel. When project goals are not clear, it is difficult (if not impossible) to plan the project efficiently. The lack of planning contributes directly to unrealistic resource allocations and schedules. People assigned to the project are unlikely, therefore, to commit energetically to the endeavor. The lack of commitment (and poor motivation) among project personnel was reported as emerging more from the problems already mentioned than from issues associated with the project’s technology or organizational structure (e.g., matrix form). The communication breakdowns (problems which occur during the life of a project) were often referred to as “inevitable.” These breakdowns occur as a result of the ambiguity

142

CHAPTER 3 / THE PROJECT MANAGER

surrounding the project, but also result from difficulties in coordinating and integrating diverse perspectives and personalities. The project manager’s challenge is to handle communication breakdowns as they arise rather than being able to predict (and control) communication problems before they happen. How the problems confronting project managers were interrelated is exemplified by how frequently problems of communication and dealing with conflicts were linked by respondents. The linkage between these two issues was demonstrated in statements like: “My problem is being able to effectively communicate with people when we disagree over priorities.” “Conflicts between departments end up as major communication hassles.” Conflicts between departments were also linked to earlier problems of poor goal-setting and planning. Managing changes (e.g., in goals, specifications, resources) contributed substantially to project management headaches. This was often mentioned as “Murphy’s Law,” highlighting the context or environment in which project management occurs. Planning cannot accurately account for future possibilities (or better yet, unknowns). Interestingly, less than one in ten project managers mentioned directly a “technological” factor or variable as significantly causing them problems in managing a project.

Project Manager Skills The second issue investigated was what project manager skills—traits, characteristics, attributes, behaviors, techniques—make a difference in successfully managing projects. Most respondents easily generated four to five items which they believed made the difference between average and superior project performance. The result was nearly 1400 statements. These statements were summarized into six skill areas as shown in Table 2. Several factors within each are highlighted.

Table 2

Project Management Skills

1. Communication Skills (84) • Listening • Persuading 2. Organizational Skills (75) • Planning • Goal-setting • Analyzing 3. Team Building Skills (72) • Empathy • Motivation • Esprit de corps

4. Leadership Skills (68) • Sets an example • Energetic • Vision (big picture) • Delegates • Positive 5. Coping Skills (59) • Flexibility • Creativity • Patience • Persistence 6. Technological Skills (46) • Experience • Project knowledge

Note: Numbers in parentheses represent percentage of project managers whose response was included in this cluster.

Eighty-four percent of the respondents mentioned “being a good communicator” as an essential project manager skill. Being persuasive or being able to sell one’s ideas was frequently mentioned as a characteristic of a good communicator within the project management context. Many people also cited the importance of receiving information, or good listening skills. As one systems engineer exclaimed: “The good project managers manage not by the seat of their pants but by the soles of their feet!” Organizational skills represented a second major set of competencies. Characteristics included in this category were planning and goal-setting abilities, along with the ability to be analytical. The ability to prioritize, captured in the phrases “stays on track” and “keeps the project goals in perspective,” was also identified as significant. While successful project managers were viewed as good problem solvers, what really differentiated them from their so-so counterparts was their problem finding ability. Because of their exceptional communication skills, goal clarity, and planning, effective project managers were aware of issues before they became problems. Problem finding gave them greater degrees of freedom, enabling them to avoid being seriously sidetracked by problems caused by unforeseen events. The important team building skills involved developing empathetic relationships with other members of the project team. Being sensitive to the needs of others, motivating people, and building a strong sense of team spirit were identified as essential for effectively managing a project. “The best project managers use a lot of ‘we’ statements in describing the project,” wrote one computer programmer. Being clear about the project’s objectives and subsequently breaking down the project into its component parts (e.g., schedules) helped project participants to understand their interdependencies and the need for teamwork. Several different attributes and behaviors were catalogued under leadership skills. These included setting a good example, seeing the big picture, being enthusiastic, having a positive outlook, taking initiative, and trusting people. Having a vision is closely related to goal clarity (which was included as an organizational skill). The leadership component of this competency was best expressed by one financial analyst as “the ability to see the forest through the trees.” Since, as is often lamented, the only constant in managing a project is change, successful project managers require coping or stressmanagement skills. Respondents indicated that both flexibility and creativity were involved in effectively dealing (or coping) with change, as were patience and persistence. What project managers experience are generally high levels of stress. How well they handle stress (“grace under pressure”) significantly affects their eventual success or failure. The final cluster of skills was labeled technological. Successful project managers were seen as having relevant experience or knowledge about the technology required by the project. Seldom, however, were effective project managers seen as technological “experts.” Indeed, expertise was

DIRECTED READING

often felt to be detrimental because it decreased flexibility and the willingness to consider alternative perspectives. Project managers do need to be sufficiently well versed in the technology to be able to ask the right questions because, as one senior military officer pointed out, “you’ve got to be able to know when people are blowing smoke at you.”

Skills and Problems: Fundamentally Interconnected It has been argued in the literature that project managers require certain skills in order to be effective. It has also been argued that project managers need to be able to handle certain problems in order to be effective. The results of this study suggest that these two perspectives are not contradictory but are fundamentally compatible. When the set of required skills is considered side-by-side with the set of critical problems project managers face, the complementary nature of these two perspectives is evident. This is illustrated in Table 3. Without arguing which comes first, it is clear that either (a) project managers require certain skills in order to deal effectively with the factors most likely to create problems for them in managing the project, or (b) because certain problems are most likely to confront project managers, they require particular skills in order to handle them. While this one-on-one matching in Table 3 obviously oversimplifies the dynamic nature of project management, it does have an inherent logical appeal. Since communication breakdowns are likely to create project management problems, effective project managers need to cultivate their communications (persuading and listening) skills. Project managers with good organizational skills are likely to be more effective at planning and subsequently allocating resources. Unless project managers are able to build strong project teams, they are likely to be plagued by problems caused by poorly committed team members and interdepartmental conflict. Project goals are likely to be more easily understood when the project manager’s leadership is consistent. Interpersonal conflicts will likely diminish when project managers set clear standards of performance and

Table 3 Skills—Problems: Interconnected in Project Management

143

demonstrate their trust in, and respect for, others. The inevitable changes which accompany any project will be less problematic when not only coped with calmly, but also when handled with flexibility and creativity. Finally, problems created when deadlines and schedules are unrealistic may be minimized through a project manager’s problem finding ability and experience in getting things back on track. What was found underscores the claim that the primary problems of project managers are not technical, but human. Improving project managers’ technological capabilities will be helpful only to the extent that this improves their ability to communicate, be organized, build teams, provide leadership, and deal comfortably with change. The challenge for technical managers, or for those moving from technical into managerial positions, is to recognize the need for, and to develop where necessary, their interpersonal skills. References 1. Archibald, R. D. Managing High-Technology Programs and Projects. New York: John Wiley & Sons, 1976; Kerzner, H. Project Management for Executives. New York: Van Nostrand Reinhold, 1982; Stuckenbruck, L., “Ten Attributes of the Proficient Project Manager.” Proceedings of the Project Management Institute, Montreal, 1976, 40–47; and Thamhain, H., and Wilemon, D., “Skill Requirements of Engineering Project Managers.” Twenty-Sixth IEEE Joint Engineering Management Conference, 1978. 2. Roman, D. D. Managing Projects: A Systems Perspective. New York: Elsevier Science Publishing, 1985. 3. Badaway, M. Developing Managerial Skills in Scientists and Engineers. New York: Van Nostrand Reinhold, 1982. 4. Hitchcock, L. “Problems of First-Line Supervisors.” Research Management Vol. 10, No. 6, 1967, 385–397.

Questions 1. What primary characteristic distinguishes the very successful project managers from the more mediocre project managers? 2. In Table 3, match the rankings between skills and problems. Why aren’t the top skills matched to the main problems? 3. In Table 1, which of the problems are related to project setup (perhaps occurring before a project manager was selected) and which are related to the project manager’s skills? 4. How does Table 1 compare to the discussion in the chapter? 5. How does Table 2 compare to the discussion in the chapter?

This page intentionally left blank

C

H

A

P

T

E

R

4 Managing Conflict and the Art of Negotiation

Conflict has been mentioned many times thus far in this book. This chapter is about conflict. It is also about negotiation—the skill required to resolve most conflicts. The question arises, why should there be so much conflict on projects? One of several causes is that conflict arises when people working on the same project have somewhat different ideas about how to achieve project objectives. But why should such a disagreement occur? Is there not “one best way?” There may be one best way, but exactly which way is the “one best” is a matter surrounded by uncertainty. For example, the client of the project’s outputs often has a substantially different point of view than those at the input end of the project, such as suppliers, or functional managers. And other stakeholders may have even different points of view, such as the project’s top management, or the local community, or the project firm’s lawyers. Most conflicts have their roots in uncertainty, and negotiation is a way of managing the resultant risk. Therefore, this chapter is also about risk management, about dealing with conflicts that often arise from uncertainty. As we will see in Chapter 6, the process of planning a project usually requires inputs from many people. Even when the project is relatively small and simple, planning may involve the interaction of almost every functional and staff operation in the organization. It is virtually impossible for these interactions to take place without conflict, and when a conflict arises, it is helpful if there are acceptable methods to reduce or resolve it. And, of course, we should mention that some people are more receptive to negotiation and compromise than others, who may be more insistent on having their own way, or see the world as trying to frustrate their every desire. Personalities vary tremendously and always need to be considered in evaluating ways to reduce conflicts in projects. Conflict has sometimes been defined as “the process which begins when one party perceives that the other has frustrated, or is about to frustrate, some concern of his” (Thomas, 1976, p. 891). While conflict can arise over issues of belief or feelings or behavior, our concern in this chapter is focused for the most part on goal conflicts that occur when an individual or group pursues goals different from those of other individuals or groups (Raiffa, 1982, Chapter 12). A party to the conflict will be satisfied when the level of frustration has been lowered to the point where no action, present or future, against the other party is contemplated. When all parties to the conflict are satisfied to this point, the conflict is said to be resolved.

145

146

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

There are, of course, many ways to resolve conflict, as described in detail in the reading “Methods of Resolving Interpersonal Conflict” at the end of this chapter, such as withdrawal, smoothing, compromise, forcing, confrontation/problem-solving, and others. As noted there, confrontation/problem-solving (i.e., facing the issue directly, such as by negotiation) is the most effective method while forcing, or brute force, is the most ineffective. Brute force is, of course, a time-honored method, as is the absolute rule of the monarch, but the rule of law is the method of choice for modern societies if negotiation or arbitration has not already succeeded—in spite of occasional lapses. Conflict resolution is the ultimate purpose of law. Organizations establish elaborate and complex sets of rules and regulations to settle disputes between the organization itself and the individuals and groups with whom it interacts. Contracts between a firm and its suppliers, its trade unions, and its customers are written to govern the settlement of potential conflicts. But the various parties-at-interest (stakeholders) do not always agree about the meaning of a law or a provision in a contract. No agreement, however detailed, can cover all the circumstances that might arise in the extensive relationships between the buyer and the seller of complicated industrial equipment, between the user and the supplier of engineering consulting services, between the producer and user of computer programs—the list of potential conflicts is endless. Our overcrowded courts are witness to the extent and variety of conflict. According to the web page of the New York State Bar Association, there are approximately 850,000 lawyers in the United States. The great majority of this group that numbers between 25 and 35 percent of the world’s supply of lawyers are employed in helping conflicting parties to adjudicate or settle their differences. In this chapter, we examine the nature of negotiation as a means of reducing or resolving the kinds of conflict that typically occur within projects. But before we begin the discussion, it must be made quite clear that this chapter is not a primer on how to negotiate; a course in negotiation is beyond the scope of this book (for such information, see the bibliography). Rather, this chapter focuses on the roles and applications of negotiation in the management of projects. Note also that we have given minimal attention to negotiations between the organization and outside vendors. In our experience, this type of negotiation is conducted sometimes by the project manager, sometimes by the project engineer, but most often by members of the organization’s purchasing department. In any case, negotiations between buyer and seller are admirably covered by Raiffa (1982). Debate over the proper technical approach to a problem often generates a collaborative solution that is superior to any solution originally proposed. Conflict often educates individuals and groups about the goals/objectives of other individuals and groups in the organization, thereby satisfying a precondition for valuable win-win negotiations (see Section 4.3). Indeed, the act of engaging in win-win negotiations serves as an example of the positive outcomes that can result from such an approach to conflict resolution. In Chapter 3 we noted that negotiation was a critical skill required of the project manager. No project manager should attempt to practice his or her trade without explicit training in negotiation. In this chapter, we describe typical areas of project management where this skill is mandatory. In addition, we will cover some of the appropriate and inappropriate approaches to negotiation, as well as a few of the characteristics of successful negotiation suggested by experts in the field or indicated by our experience. We will also note some ethical issues regarding negotiation. There are probably more opportunities for ethical missteps in handling conflicts and negotiations than in any other aspect of project management. Unlike other chapters, we will use comparatively few illustrative examples. Successful negotiation tends to be idiosyncratic to the actual situation, and most brief examples do little to

MANAGING CONFLICT AND THE ART OF NEGOTIATION

147

help transform theory into practice. We have, however, included a vignette at the end of the chapter. This vignette was adapted from “real life”; the names were changed to protect innocent and guilty alike.

Project Management in Practice Quickly Building a Kindergarten through Negotiation

The idea to build a school for orphans and poor children in an African slum in 30 days was suggested as fodder for a Norwegian television “reality” show. Only one of the ten Scandinavian team members recruited had any construction experience and only one, Ms. Lange, a PMP, had any project management experience. As might be expected, the challenges of climate, food, language, and especially culture shock were nearly overwhelming to the small team. The heat was sweltering to the northern Europeans and the food was tasteless—Lange had to negotiate with the hotel’s kitchen staff in order to add more spices in the food. But the cultural change was the

most challenging, particularly regarding time since African time was much more casual than Scandinavian time and the team was on a limited-time schedule. For example, to help secure local buy-in, Lange engaged a local carpenter to build the desks and tables for the school. When she checked back a few days before the furniture was due, she was shocked to find that he hadn’t even started the work: “Time is unpredictable; I will call you.” he said. Lange found that negotiation seemed to be required for everything. “Negotiation skills definitely were the most valuable of all the project management training that I have taken.” She found that she constantly needed

148

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

to count to 10 in her interactions, reflect on where these people were coming from, and figure out how to create a win-win situation that would satisfy both parties. The townsfolk began to refer to her as “The Diplomat.” Impressed with the foreigners who were trying to help them, the local villagers pitched in to help on the project. Lange found that, rather than going through official channels, she made better progress personally talking with many of the women who were doing the work, which solved a lot of the problems the team encountered.

4.1

However, as the end of their time began to arrive, success appeared unlikely. As the team considered how disappointed the children and villagers would be to not have the school completed, they decided to work in shifts throughout the night. The increased commitment paid off, and the school was done by the time the “reality show” was over. Source: B. G. Yovovich, “ Worlds Apart,” PM Network, Vol. 24.

CONFLICT AND THE PROJECT LIFE CYCLE In this section, following a brief discussion of the project life cycle, we will categorize the types of conflicts that frequently occur in the project environment, and then amplify the nature of these conflicts. Finally, we will link the project life cycle with the fundamental conflict categories and discover that certain patterns of conflict are associated with the different periods in the life of a project. With this knowledge, the PM can do a faster and more accurate job of diagnosing the nature of the conflicts he or she is facing, thereby reducing the likelihood of escalating the conflict by dealing with it ineffectually.

More on the Project Life Cycle Various authors define the stages of the project life cycle (see Figures 1-3, 1-4, and 1-5) in different ways. Two of the most commonly cited definitions are those of Thamhain et al. (1975a) and Adams et al. (1983). The former use a four-stage model with project formation, buildup, main program, and phase-out identified as the stages of the life cycle. Adams et al. also break the project life cycle into four, but slightly different, stages: conceptualization, planning, execution, and termination. For our purposes, these two views of the cycle are not significantly different. During the first stage, senior management tentatively, sometimes unofficially, approves preliminary planning for a project. Often, this management recognition is preceded by some strictly unofficial “bootleg” work to test the feasibility of an idea. Initial planning is undertaken, basic objectives are often adopted, and the project may be “scoped out.” The second stage is typified by detailed planning, budgeting, scheduling, and the aggregation of resources. In the third stage, the lion’s share of the actual work on the project is accomplished. During the final stage of the life cycle, work is completed and products are turned over to the client or user. This stage also includes disposition of the project’s assets and personnel. It may even include preparation for the initial stage of another related project to follow.

Categories of Conflict All stages of the project life cycle appear to be typified by conflict. Thamhain et al. (1975a, 1975b) have done extensive research on conflict in the project. These conflicts center on such matters as schedules, priorities, staff and labor requirements, technical factors, administrative procedures, cost estimates, and, of course, personality conflicts (Afzalur, 1992). Thamhain

4.1

CONFLICT AND THE PROJECT LIFE CYCLE

149

et al. collected data on the frequency and magnitude of conflicts of each type during each stage of the project life cycle. Multiplying conflict frequency by a measure of conflict magnitude and adjusting for the proportion of PMs who reported each specific type of conflict, they derived an estimate of the “intensity” of the conflicts. On examination of the data, it appears that the conflicts fall into three fundamentally different categories: 1. Groups working on the project may have different goals and expectations. 2. There is significant uncertainty about who has the authority to make decisions. 3. There are interpersonal conflicts between people who are parties-at-interest in the project. Some conflicts reflect the fact that the day-to-day work on projects is usually carried out by many different units of the organization, units that often differ in their objectives and technical judgments. The result is that these units have different expectations about the project, its costs and rewards, its relative importance, and its timing. Conflicts about schedules, intra- and interproject priorities, cost estimates, and staff time tend to fall into this category. At base, they arise because the project manager and the functional managers have very different goals. The PM’s concern is the project. The primary interest of the functional manager is the daily operation of the functional department. Other conflicts reflect the fact that both technical and administrative procedures are important aspects of project management. Uncertainty about who has the authority to make decisions on resource allocation, on administrative procedures, on communication, on technological choices, and on all the other matters affecting the project produces conflict between the PM and the other parties. It is simple enough (and correct) to state that the functional manager controls who works on the project and makes technical decisions, while the project manager controls the schedule and flow of work. In practice, in the commonly hectic environment of the project, amid the day’s countless little crises faced by project and functional manager alike, the distinction is rarely clear. Finally, some conflicts reflect the fact that human beings are an integral part of all projects. In an environment that depends on the cooperation of many persons, it seems inevitable that some personalities will clash. Also, in conflicts between the project and the client, or between senior management and the project, it is the project manager who personifies the project and thus is generally a party to the conflict. We can categorize these conflicts as conflict over differing goals, over uncertainty about the locus of authority, and between personalities. For the entire array of conflict types and parties-at-interest, see Table 4-1.

Table 4-1

Project Conflicts by Category and Parties-at-Interest

150

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

The three types of conflict seem to involve the parties-at-interest to the project in identifiable ways. The different goals and objectives of the project manager, senior management, and functional managers are a major and constant source of conflict. For example, senior management (at times, arbitrarily) is apt to fix all three parameters of the project—time, cost, and scope—and then to assume that the PM will be able to achieve all the preset targets. Underestimation of cost and time is a natural consequence of this practice, and it leads directly to conflict between the PM, as a representative of the project team, and senior management. A second consequence is that the PM tries to pass the stringent cost and time estimates along to functional managers whose units are expected to perform certain work on the project. More conflict arises when the functional managers complain that they cannot meet the time and cost restrictions. All this tends to build failure into the job of managing a project, another source of conflict between the PM and senior management. Functional managers also may not see eye-to-eye with the PM on such issues as the project’s priority or the desirability of assigning a specifically named individual to work on the project, or even the applicability of a given technical approach to the project. In addition, the client’s priorities and schedule, whether an inside or outside client, may differ radically from those of senior management and the project team. Finally, the project team has its own ideas about the appropriateness of the schedule or level of project staffing. The Thamhain et al. (1975a) data show that these goal-type conflicts occur in all stages of the project’s life cycle, though they are particularly serious in the early stages. Regardless of the timing, in many cases it is not certain just whose priorities are ruling. There are, of course, a number of methods for settling conflicts about priorities between projects, as well as intraproject conflicts. Often, the project selection model used to approve projects for funding will generate a set of projects ranked by some measure of value. It is also common for senior management to determine interproject priorities. The relative importance of the various tasks in an individual project is set by the project manager, who allocates scarce resources depending on the requirements of schedule, task difficulty, resource availability, and similar considerations. The existence of these methods for resolving priority conflicts is all too often irrelevant, because there is a powerful tendency for both project and functional managers to optimize their individual interests, with little regard for the total organization. Locus-of-authority conflicts are endemic to projects. The project team and the client tend to focus on the technical procedures, debating the proper approach to the project, or perhaps how to solve individual problems that can occur at any stage. Senior management has other fish to fry. Not only do they insist that the project manager adopt and maintain a set of administrative procedures that conform to organizational and legal standards, but they also are quite concerned with who reports to whom and whose permission is required to take what action. The astute reader will note that such concerns are not entirely appropriate for projects. Our discussions with senior managers lead us to the obvious conclusion that it is common for senior management to want the efficiency and other advantages of projects but simultaneously to attempt to maintain the managerial comforts of traditional hierarchical structures—a sure source of conflict. The conflict-resolution potential of partnering and project charters should be quite clear. Neither technique will stop conflicts from arising, but they will sharply lower the intensity of the conflicts as well as provide a framework for resolving conflict. They will even allow an environment in which the PM and functional managers can take positions that support the total organization rather than suboptimizing the project or the function. Project managers will often find themselves arguing for scheduling or resource priorities from functional managers who outrank them by several levels. Neither the functional

4.1

CONFLICT AND THE PROJECT LIFE CYCLE

151

nor the project managers are quite sure about who has what authority. A constant complaint of project managers is “I have to take the responsibility, but I have no authority at all.” People problems arise, for the most part, within the project team, though functional managers may clash with PMs—the former accusing the latter of being “pushy,” and the latter accusing the former of “foot dragging.” In our experience, most personality clashes on the project team result from differences in technical approach or philosophy of problem solving, and in the methods used to implement the project results. Of course, it is quite possible that a personality conflict causes a technical conflict. It is also possible that any type of conflict will appear, at first blush, to be a personality clash. Next we put these conflicts into the chronological perspective of the project life cycle.

Project Formation In the initial stage of the project life cycle, most of the conflict centers around the inherent confusion of setting up a project in the environment of matrix management. Almost nothing about the project or its governance has been decided. Even the project’s technical objectives, not clearly defined or established, are apt to be understood only in the most general sense. Moving from this state of semichaos to the relatively ordered world of the buildup stage is difficult. To make this transition, four fundamental issues must be handled, although not necessarily in the order presented here. First, the technical objectives of the project must be specified to a degree that will allow the detailed planning of the buildup stage to be accomplished. Second, commitment of resources to the project must be forthcoming from senior management and from functional managers. Third, the priority of the project, relative to the priorities of the parent organization’s other projects, must be set and communicated. We feel the project’s priority must be set as early as possible in the life of the project. (While it will probably not save the project from delay in the event of a mandate, it stands as an important political signal to functional managers about which projects take precedence in case of resource conflicts.) These conditions are not sufficient, but they are most certainly necessary if the conflicts typical of the formation stage are to be resolved—at least at a reasonable level—and not simply carried forward to the buildup stage in an exacerbated state. The project manager who practices conflict avoidance in this stage is inviting disaster in the next. The four fundamental issues above underlie such critical but down-to-earth matters as these: Which of the functional areas will be needed to accomplish project tasks? What will be the required level of involvement of each of the functional areas? How will conflicts over resources/facility usage between this and other projects be settled? What about those resource/facility conflicts between the project and the routine work of the functions? Who has the authority to decide the technical, scheduling, personnel, and cost questions that will arise? Most important, how will changes in the parent organization’s priorities be communicated to everyone involved? Note that three of the four fundamental issues—delimiting the technical objectives, getting management commitment, and setting the project’s relative priority—must be resolved irrespective of what organizational form is selected for the project. It should also be noted that the organizational structure selected will have a major impact on the ways in which the conflicts are handled. The more independent and standalone the project, the more authoritative the role played by the PM. The weaker the project and the more functional ties, the more authority is embedded in the functional managers. Lack of clarity about the relative power/influence/authority of the PM and the functional managers is a

152

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

major component of all conflicts involving technical decisions, resource allocation, and scheduling.

Project Buildup Thamhain et al. (1975a, p. 39) note that conflict occurring in the buildup stage “over project priorities, schedules, and administrative procedures . . . appears as an extension from the previous program phase.” This is the period during which the project moves (or should move) from a general concept to a highly detailed set of plans. If the project is independent and standalone, the PM seeks a commitment of people from the functional departments. If the project is functionally tied down, the PM seeks a commitment of work from the functional departments. In either case, the PM seeks commitment from functional managers who are under pressure to deliver support to other projects, in addition to the routine, everyday demands made on their departments. As the project’s plans become detailed, conflicts over technical issues build—again, conflicts between the PM and the functional areas tend to predominate. Usually, the functional departments can claim more technical expertise than the PM, who is a “generalist.” On occasion, however, the PM is also a specialist. In such situations, discussions between the functional manager and the project manager about the best technical approach often result in conflict. The total level of conflict is at its highest in this transition period.

Main Program Schedules are still a major source of conflict in the main program phase of the project life cycle, though the proximate cause of schedule-related conflict is usually different than in the earlier stages. Project plans have been developed and approved by everyone involved (although, perhaps, grudgingly), and the actual work is under way. Let us make an assumption that is certain to be correct; let us assume that some activity runs into difficulty and is late in being completed. Every task that is dependent on this late activity will also be delayed. Some of these subsequent activities will, if sufficiently late and if the late work is not made up, delay the entire project. In order to prevent this consequence, the PM must try to get the schedule back on track. But catching up is considerably more difficult than falling behind. Catching up requires extra resources that the functional groups who are doing the “catching up” will demand, but which the PM may not have. The more complex the project, the more difficult it is to trace and estimate the impact of all the delays, and the more resources that must be consumed to get things back on schedule. Throughout this book we have referred to the PM’s job of managing time/cost/scope tradeoffs. Maintaining the project schedule is precisely an exercise in managing trade-offs, but adding to the project’s cost or scaling down the project’s technical capabilities in order to save time are trade-offs the PM will not take if there is any viable alternative. The PM’s ability to make trade-offs is often constrained by contract, company policy, and ethical considerations. In reality, trade-off decisions are quite difficult. Like schedule conflicts, technical conflicts are frequent and serious during the main program stage. Also like schedule conflicts, the source of technical conflict is somewhat different than in earlier stages. Just as a computer and a printer must be correctly linked together in order to perform properly, so must the many parts of a project. These linkages are known as interfaces. The number of interfaces increases rapidly as the project gets larger, which is to say that the system gets more complex. As the number of interfaces increases, so does the probability that problems will arise at the interfaces. The need to

4.1

CONFLICT AND THE PROJECT LIFE CYCLE

153

manage these interfaces and to correct incompatibilities is the key to the technical conflicts in the main program phase.

Project Phase-out As in the main program stage, schedule is the major source of conflict during project phaseout. If schedule slippage has occurred in the main program stage (and it probably has), the consequences will surely be felt in this final stage. During phase-out, projects with firm deadlines develop an environment best described as hectic. The PM, project team, and functional groups often band together to do what is necessary to complete the project on time and to specification. Cost overruns, if not outrageously high, are tolerated—though they may not be forgiven and they will certainly be remembered. Technical problems are comparatively rare during phase-out because most have been solved or bypassed earlier. Similarly, working interfaces have been developed and put in place. If the project involves implementing a technology in an outside client’s system, technical conflicts will probably arise, but they are usually less intense. Thamhain et al. (1975b, p. 41) note that personality conflicts are the second-ranked source of conflict during phase-out. They ascribe these conflicts to interpersonal stress caused by the pressure to complete the project, and to individuals’ natural anxiety about leaving the project either to be assigned to another, or be returned to a functional unit. In addition, we have observed conflict, sometimes quite bitter, focused on the distribution of the project’s capital equipment and supplies when the project is completed. Conflict also arises between projects phasing out and those just starting, particularly if the latter need resources or personnel with scarce talents being used by the former. The way in which Thamhain et al. have defined conflict as having its source in differences about goals/expectations, uncertainty about authority, and interpersonal problems, precludes identifying conflict as occurring between discipline-oriented and problem-oriented team members. Recall our discussions of Hughes (1998) and de Laat (1994). We do not argue that Thamhain et al. are in error, but merely that their classification does not specifically include a type of conflict we feel is both frequent and important. Much of the conflict identified during our discussion of planning in Chapter 6, it seems to us, is due to discipline/problem-orientation differences. A clear example comes from an interview recorded during Pelled et al.’s (1994, p. 23) research on conflict in multifunctional design teams. One team member speaking of another said, “He will do whatever he thinks is right to get his [own] job done, whether or not it’s good for [the company] or anyone else.” In context, it is clear that this conflict was between a problem-oriented individual and one who was discipline oriented. The upshot is simple. As we noted in the first section of Chapter 1, conflict is an inherent characteristic of projects, and the project manager is constantly beset by conflict. The ability to reduce and resolve conflict in ways that support achievement of the project’s goals is a prime requisite for success as a PM. The primary tool to accomplish conflict resolution and reduction is negotiation, and the method of handling conflict established in the project formation stage will set the pattern for the entire project. Therefore, the style of negotiation adopted by the PM is critical. Much has been written on conflict resolution. Burke’s classic paper on the confrontation-problem solving method of resolving conflicts is offered as a “Reading” at the end of this chapter. The similarities between the confrontation-problem solving technique for conflict resolution and win-win negotiation covered in the following section are quite striking.

154

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

Project Management in Practice A Consensus Feasibility Study for Montreal’s Archipel Dam

To assess the desirability of a feasibility study evaluating the costs and benefits of constructing a dam for watershed development within the St. Lawrence river basin in the Montreal metropolitan area, Quebec initiated an interdepartmental evaluation. The evaluation concluded that a feasibility study that considered the hydroelectric power generated, the flood control possible, and the shoreline restoration for recreation for the 3 million local area residents was justified. It was recommended that a central authority act as project manager for the study and that arbitration procedures be instituted for the interests of all affected parties. Thus, a new body called “Secretariat Archipel” was created to directly supervise the feasibility study. Secretariat Archipel, however, rejected the recommendations of the prior evaluation and chose to use a more democratic “consensus” approach between all involved agencies rather than a central authority approach. Doing so avoided the need for arbitration procedures as well. In addition, a matrix structure was put in place to guarantee a veto right to each of the ten governmental departments involved in the process. It was believed that this consensus approach would lead to a solution acceptable to all, while protecting the jurisdictional responsibilities of all departments. Although this approach apparently avoided difficult conflicts, and the concomitant need to arbitrate them, a post-study evaluation of the process concluded that it was neither effective nor efficient. By discarding the recommendation for a central authority body, a leadership gap arose in the decision framework and veto rights were abused by many of the participants. The leadership gap led, for example, to no one identifying incompatible objectives, rules for making decisions, or common priorities.

In terms of effectiveness, the recommendations of the study are questionable: that the dam be postponed until the year 2015 while only $35 million—less than the cost of the feasibility study—be spent on recreational facilities. Considering efficiency, it was found that many of the expensive support studies authorized by the Secretariat did not add significantly to the feasibility process. Also, the study appeared to take one to two years longer than necessary, with a correspondingly higher cost. The evaluation proposed three probable causes of the lack of decisiveness in this study process: 1. Fear of litigation between the governmental departments and municipalities, 2. Difficulty comparing positive and negative impacts due to a lack of decision rules, and 3. Long delays and unavoidable sacrifices through a failure of the consensus process. In retrospect, the consensus approach appeared to have been selected to protect the fields of jurisdiction of each governmental department rather than for defining the best project for the community. Since many of the goals were incompatible to start with, a consensual decision process with veto override would simply have to reject any recommendation—no matter how appropriate for the community—that was incompatible with another goal or disliked by any of the ten departments involved in the study. Although consensus is a highly desirable goal for public studies, leadership cannot be abandoned in the process. Attempting to avoid conflict through mandated consensus simply defeats the purpose of any study in the first place, except a study to determine what everyone commonly agrees upon. Source: R. Desbiens, R. Houde, and P. Normandeau, “Archipel Feasibility Study: A Questionable Consensus Approach,” Project Management Journal,Vol. 20.

4.2

4.2

THE NATURE OF NEGOTIATION

155

THE NATURE OF NEGOTIATION The favored technique for resolving conflict is negotiation. What is negotiation? Wall (1985, preface) defines negotiation as “the process through which two or more parties seek an acceptable rate of exchange for items they own or control.” Dissatisfied with this definition, he spends part of a chapter extending and discussing the concept (Chapter 1), without a great deal of improvement. Cohen (1980, p. 15) says that “Negotiation is a field of knowledge and endeavor that focuses on gaining the favor of people from whom we want things.” Other authors define negotiation differently, but do not appreciably extend Cohen’s definition. Even if no single definition neatly fits all the activities we label “negotiation,” we do recognize that such terms as “mediate,” “conciliate,” “make peace,” “bring to agreement,” “settle differences,” “moderate,” “arbitrate,” “adjust differences,” “compromise,” “bargain,” “dicker,” and “haggle” (Roget’s International Thesaurus, 1993) are synonyms for “ negotiate” in some instances. Most of the conflicts that involve the organization and outsiders have to do with property rights and contractual obligations. In these cases, the parties to negotiation see themselves as opponents. Conflicts arising inside the organization may also appear to involve property rights and obligations, but they typically differ from conflicts with outsiders in one important way: As far as the firm is concerned, they are conflicts between allies, not opponents. Wall (1985, pp. 149–150) makes this point neatly: Organizations, like groups, consist of interdependent parts that have their own values, interests, perceptions, and goals. Each unit seeks to fulfill its particular goal . . . and the effectiveness of the organization depends on the success of each unit’s fulfillment of its specialized task. Just as important as the fulfillment of the separate tasks is the integration of the unit activities such that each unit’s activities aid or at least do not conflict with those of the others. One of the ways in which organizations facilitate this integration is to establish “lateral relations [which] allow decisions to be made horizontally across lines of authority” (Wall, 1985, p. 150). Because each unit will have its own goals, integrating the activities of two or more units is certain to produce the conflicts that Wall says should not take place. The conflicts may, however, be resolved by negotiating a solution, if one exists, that produces gains (or minimizes losses) for all parties. Raiffa (1982, p. 139) defines a Pareto-optimal solution to the two-party conflict and discusses the nature of the bargaining process required to reach optimality, a difficult and time-consuming process. While it is not likely that the conflicting parties will know and understand the complex trade-offs in a real-world, project management, many-persons/many-issues conflict (see Raiffa, 1982, Chapters 17–23), the general objective is to find a solution such that no party can be made better off without making another party worse off by the same amount or more—i.e., a Pareto-optimal solution. The concept of a Pareto-optimal solution is important. Approaching intraproject conflicts with a desire to win a victory over other parties is inappropriate. The PM must remember that she will be negotiating with project stakeholders many times in the future. If she conducts a win-lose negotiation and the other party loses, from then on she will face a determined adversary who seeks to defeat her. This is not helpful. The proper outcome of this type of negotiation should be to optimize the outcome in terms of overall organizational goals. Although it is not always obvious how to do this, negotiation is clearly the correct approach. During the negotiation process, an ethical situation often arises that is worth noting. Consider the situation where a firm requests an outside contractor to develop a software package to achieve some function. When the firm asks for a specific objective to be accomplished,

156

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

it frequently does not know if that is a major job or a trivial task because it lacks technical competence in that area. Thus, the contractor has the opportunity to misrepresent the task to its customer, either inflating the cost for a trivial task or minimizing the impact of a significant task in order to acquire the contract and then boosting the cost later. The ethics of the situation require that each party in the negotiation be honest with the other, even in situations where it is clear there will not be further work between the two.

4.3

PARTNERING, CHARTERING, AND SCOPE CHANGE Projects provide ample opportunity for the project manager (PM) to utilize her or his skills at negotiation. There are, however, three situations commonly arising during projects that call for the highest level of negotiating skill the PM can muster: the use of subcontractors, the use of input from two or more functional units to design and develop the project’s mission, and the management of changes ordered in the project’s deliverables and/or priorities after the project is underway (de Laat, 1994; Hughes, 1998). The former probably accounts for more litigation than all other aspects of the project combined. The latter two are, in the authors’ experience, by far the most common and most troublesome issues project managers report facing.

Partnering In recent years there has been a steady growth in the frequency of outsourcing parts of projects (Smith, 1998). External suppliers, increasingly, are delivering parts of projects, including tangible products and services as well as intangible knowledge and skills. There are many reasons beyond avoidance of litigation that firms enter partnering arrangements with each other, for example, diversification of technical risk, avoidance of capital investment, reducing political risk on multinational projects, shortening the duration of the project, and pooling of complementary knowledge, among others (Beecham et al., 1998, p. 192). Generally, relations between the organization carrying out a project and a subcontractor working on the project are best characterized as adversarial. The parent organization’s objective is to get the deliverable at the lowest possible cost, as soon as possible. The subcontractor’s objective is to produce the deliverable at the highest possible profit with the least effort. These conflicting interests tend to lead both parties to work in an atmosphere of mutual suspicion and antagonism. Indeed, it is almost axiomatic that the two parties will have significantly different ideas about the exact nature of the deliverable itself. The concept of “partnering” has been developed to replace this atmosphere with one of cooperation and mutual helpfulness, but the basically adversarial relationship makes cooperation difficult in the best of cases (Larson et al., 1997). Cowen et al. (1992, p. 5) define partnering as follows: Project partnering is a method of transforming contractual relationships into a cohesive, cooperative project team with a single set of goals and established procedures for resolving disputes in a timely and effective manner. They present a multistep process for building partnered projects. First, the parent firm must make a commitment to partnering, select subcontractors who will also make such a commitment, engage in joint team-building exercises, and develop a “charter” for the project. (See the next subsection for a description of such a charter.) Second, both parties must implement the partnering process with a four-part agreement on: (1) “joint evaluation” of the project’s progress; (2) a method for resolving any problems or disagreements; (3) acceptance of a goal for continuous improvement (also known as “total quality management,” or TQM) for the joint project; and (4) continuous support for the process of partnering from senior management of both parties. Finally, the parties commit to a joint review of “project execution” when the project is completed. Beecham et al. (1998, p. 194ff) note several things that can “doom”

4.3

PARTNERING, CHARTERING, AND SCOPE CHANGE

157

partnering agreements and they develop several “propositions” that lead to success. Partnering is an attempt to mitigate the risks associated with subcontracting. Consider the nature of the steps listed above. Clearly, there are specific risks that must be managed in each of them. Each step in this process must be accompanied by negotiation, and the negotiations must be nonadversarial. The entire concept is firmly rooted in the assumption of mutual trust between the partners, and this assumption, too, requires nonadversarial negotiation. Finally, these articles focus on partnering when the partners are members of different organizations. We think the issue is no less relevant when the partners are from different divisions or departments of the same parent organization. Identical assumptions hold, identical steps must be taken, and interparty agreements must be reached for partnering to succeed. The concept of partnering, however, goes far beyond two-party agreements between buyer and seller or interdepartmental cooperation on a project. The use of multiparty consortia to pursue technological research objectives is common. As noted in Chapter 3, SEMATECH is a consortium of semiconductor manufacturers for the purpose of conducting joint research projects in the field. The consortium was exempted from prosecution under the U.S. anti-trust laws when the National Cooperative Research Act of 1984 was passed expressly to allow such cooperation among competitors (Rosegger et al., 1990). There are a great many such groups of competitors engaged in cooperative research and other cooperative activities (not, one hopes, in price-setting or other illegal activities). They exist worldwide and are often multinational in their membership; for example, Airbus Industry (originally British, French, Spanish, and German) and International Aero Engines (originally USA, Japan, Germany, Italy, and UK), as mentioned in Chapter 3. Airbus Industry is not only a consortium of private firms from four different nations, but each of the four governments subsidized their respective private firms. This venture, apparently undertaken in order to foster a European competitor to USA’s Boeing Aircraft, resulted in a successful competitor in the market for commercial aircraft. Partnering, however, is not without its problems. There can be no doubt that those who have not had much experience with partnering underrate its difficulty. Partnering requires strong support from senior management of all participants, and it requires continuous support of project objectives and partnering agreements (Moore et al., 1995). Above all, and most difficult of all, it requires open and honest communication between the partners. With all of its problems, however, partnering yields benefits great enough to be worth the efforts required to make it work correctly (Baker, 1996; Larson et al., 1997).

Project Management in Practice Habitat for Humanity Wins a Big One

Loudoun Habitat for Humanity (LHH) of Sterling, VA, had everything going its way in its proposal to the Loudoun County Housing Trust Committee for $876,000 to help purchase, build, and redevelop 21 local properties for low-income families: •

The county had a $3 million housing fund available specifically to develop housing for low- and moderate-income families.

The $876,000 would enable LHH to apply for federal stimulus funding earmarked for projects such as this which, together with private donations, would bring in another $2,630,000 for a total of $3.5 million. There was no other competing group in the area building homes for low-income families.

158

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

LHH had good construction, project management, and financial expertise to successfully execute this project within the schedule and budget.

Still, LHH had to make a successful 2-hour presentation to the Committee, convincing them of their qualifications and the attractive business case the proposal offered. But, despite prodding and frequent calls, LHH didn’t hear back from the Committee, and the deadline for federal stimulus funds was approaching quickly. So LHH developed a strategy of writing letters, calling, and using any contacts available to explain the urgency of the timeline. Finally, they heard from the committee, which denied their application; apparently there had been at least one committee member who would rather use the funds to invest in high-density rentals. But this made no sense to LHH since then the county stimulus money for affordable housing would be denied, the county’s political inclination didn’t support high-density subsidized rentals so the zoning application would probably be rejected,

and the recent U.S. fiscal crisis has reduced the value of the low-income tax credits needed to make such a project viable. However, the Committee’s recommendation had to be approved by the County Board of Supervisors, and LHH was able to make a presentation there, outlining the advantages of their proposal and the disadvantages of the high-density rentals proposal. But again, they didn’t hear anything. With time running out, they made an effort to contact each of the nine supervisors, catching three in person and delivering letters to the others. The odds were stacked against them because to accept LHH’s proposal meant overturning the Committee’s recommendation. The Board decided in LHH’s favor, but only approved $500,000 for a major portion of their proposal. But it came just in time for LHH to win federal stimulus funds to leverage that money and allow them to proceed with the major portion of their plan. Source: S. F. Gale, “A Closer Look,” PM Network, Vol. 24.

4.3

PARTNERING, CHARTERING, AND SCOPE CHANGE

159

Chartering The agreements between groups partnering on large endeavors are often referred to as charters. A project (program, etc.) charter is simply a written agreement between the PM, senior management, and the functional managers who are committing resources and/or people to a specific project (program, etc.). Bear in mind, the charter may take many different forms. Typically, it details the expected deliverables, often including schedules, budgets, and resource commitments. It attests to the fact that senior management of all relevant organizations, functional managers, and the PM are “on the same page,” agreeing about what is to be done, when, and at what cost. Note that if there is such an agreement, there is also an implication that none of the parties will change the agreement unilaterally, or, at least, without prior consultation with the other parties. Many projects do not have charters, which is one reason for observing that many projects are not completed on specification, on time, and on budget. In Chapter 6, we will describe an iterative process for developing a project plan. We note that it is not uncommon for the individuals or groups who make commitments during the process of developing the project plan to sign-off on their commitments. The signed-off project plan can constitute a project charter, particularly if senior management has signedoff on the overall mission statement, and if it is recognized as a charter by all parties to the plan. A somewhat less specific project charter appears in Cowen et al. (1992, Figure 2, p. 8), in which the various members of the partnering team sign a commitment to:

• • • •

Meet design intent Complete contract without need for litigation Finish project on schedule: —Timely resolution of issues —Manage joint schedule Keep cost growth to less than 2 percent . . . etc.

Of course, to meet the underlying purpose of a charter, even these less-specific terms assume an agreement on the “design intent,” the schedule, and costs.

Scope Change

PMBOK Guide Chapter 5

The problem of changing the scope expected of a project is a major issue in project management and constitutes part of the second PMBOK knowledge area. No matter how carefully a project is planned, it is almost certain to be changed before completion. No matter how carefully defined at the start, the scope of most projects is subject to considerable uncertainty. There are three basic causes for change in projects. Some changes result because planners erred in their initial assessment about how to achieve a given end or erred in their choice of the proper goal for the project. Technological uncertainty is the fundamental causal factor for either error. The foundation for a building must be changed because a preliminary geological study did not reveal a weakness in the structure of the ground on which the building will stand. An R & D project must be altered because metallurgical test results indicate another approach should be adopted. The project team becomes aware of a recent innovation that allows a faster, cheaper solution to the conformation of a new computer. Other changes result because the client/user or project team learns more about the nature of the project deliverable or about the setting in which it is to be used. An increase in user or team knowledge or sophistication is the primary factor leading to change. A computer program must be extended or rewritten because the user thinks of new uses for the software. Physicians request that intensive care units in a hospital be equipped with laminar air-flow

160

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

control in order to accommodate patients highly subject to infection who might otherwise not be admissible in an ICU. The fledgling audio-addict upgrades the specifications for a system to include very high frequencies so that his dog can enjoy the music, too. A third source of change is the mandate. This is a change in the environment in which the project is being conducted. As such, it cannot be controlled by the PM. A new law is passed. A government regulatory unit articulates a new policy. A trade association sets a new standard. The parent organization of the user applies a new criterion for its purchases. In other words, the rules of conduct for the project are altered. A state-approved pollution control system must be adopted for each chemical refinery project. The state government requires all new insurance policies to conform to a revised law specifying that certain information must be given to potential purchasers. At times, mandates affect only priorities. The mandate in question might move a very important customer to the “head of the line” for some scarce resource or service. To some extent, risk management techniques can be applied to scope change. Technological uncertainty can be mitigated by careful analysis of the technologies involved, including the use of technological forecasting. Risk of scope change caused by increased user knowledge can only be managed by improving the up-front communication with the client and then establishing a formal process to handle change. See Chapter 11 for more about this. Finally, mandates are, for the most part, unpredictable. These can be “managed” only by having some flexibility built into the budget and schedule of the project. Ways of doing this sensibly will be discussed in the following two chapters. As Greek philosopher Heraclitus said, “Nothing endures but change.” It is thus with projects, but whatever the nature of the change, specifications of the deliverables must be altered, and the schedule and budget recalculated. Obviously, negotiation will be required to develop new agreements between the parties-at-interest to the project. These negotiations are difficult because most of the stakeholders will have a strong interest in maintaining the status quo. If the proposed change benefits the client and increases the cost of the project, the producer will try to sequester some of the user’s potential benefit in the form of added charges to offset the added cost. The client will, of course, resist. All parties must, once again, seek a Paretooptimal solution—always a difficult task. Change by mandate raises an additional problem. Not only are the project’s deliverables, budget, and schedule usually changed, the priorities of other projects are typically changed too, if only temporarily while the mandate receives the system’s full attention. Suddenly, a PM loses access to key resources, because they are urgently required elsewhere. Key contributors to a project miss meetings or are unable to keep promised task-delivery dates. All too often, the PM’s response to this state of affairs is anger and/or discouragement. Neither is appropriate. This project is so important, we can’t let things that are more important interfere with it. Anonymous After discussing priorities with both PMs and senior managers, it has become clear to us that most firms actually have only three levels of priority (no matter how ornate the procedure for setting project priorities might seem to be). First, there are the high-priority projects, that is, the “set” of projects currently being supported. When resource conflicts arise within this highpriority set, precedence is typically given to those projects with the earliest due date. (More about this is in Chapter 9.) Second, there are the lower-priority projects, the projects “we would like to do when we have the time and money.” Third, occasionally, there are urgent projects— mandates—that must be done immediately. “Customer A’s project must be finished by the end of

4.4

SOME REQUIREMENTS AND PRINCIPLES OF NEGOTIATION

161

the month.” “The state’s mandate must be met by June 30.” Everything else is delayed to ensure that mandates are met. As noted earlier, we will have more to say on this subject in Chapter 11. While project charters and partnerships would certainly help the PM deal with conflicts that naturally arise during a project, the use of charters and partnering is growing slowly—though outsourcing is growing rapidly. It is understandably difficult to convince senior managers to make the firm commitments implied in a project charter in the face of a highly uncertain future. Functional managers are loath to make firm commitments for precisely the same reason. So, too, the client, aware of her or his own ignorance about the degree to which the project output will meet his or her needs, is cautious about commitment—even when a procedure for negotiating change exists. Partnering is a recently developed concept, and in our litigious society any system for conflict resolution that asks parties to forego lawsuits is viewed with considerable suspicion. Indeed, we find that a great many organizations preach “team building,” “TQM,” and “employee involvement,” but many fail to practice what they preach. For each participative manager you find, we can show you a dozen micromanagers. For each team player ready to share responsibility, we can show you a dozen “blame placers.” The era of project charters and partnering is approaching, but it is not yet here.

4.4

SOME REQUIREMENTS AND PRINCIPLES OF NEGOTIATION The word “negotiation” evokes many images: the United States President and Congress on the annual federal budget, the “Uruguay Round” of the GATT talks, a player’s agent and the owner of an NFL team, the buyer and seller of an apartment complex, attorneys for husband and wife in a divorce settlement, union and management working out a collective bargaining agreement, tourist and peddler haggling over a rug in an Ankara market. But as we noted in the introduction to this chapter, none of these images is strictly appropriate for the project manager who must resolve the sorts of conflicts we have considered in the previous section. The key to understanding the nature of negotiation as it applies to project management is the realization that few of the conflicts arising in projects have to do with whether or not a task will be undertaken or a deliverable produced. Instead, they have to do with the precise design of the deliverable and/or how the design will be achieved, by whom, when, and at what cost. The implication is clear: The work of the project will be done. If conflicts between any of the parties to the project escalate to the point where negotiations break down and work comes to a halt, everyone loses. One requirement for the conflict reduction/resolution methods used by the PM is that they must allow the conflict to be settled without irreparable harm to the project’s objectives. A closer consideration of the attorneys negotiating the divorce settlement makes clear a second requirement for the PM negotiating conflicts between parties-at-interest to the project. While the husband and wife (or the rug peddler and tourist) may employ unethical tactics during the negotiation process and, if not found out, profit from them at the expense of the other party, it is much less likely for the attorneys representing the husband and wife to do so—particularly if they practice law in the same community. The lawyers know they will have to negotiate on other matters in the future. Any behavior that breeds mistrust will make future negotiations extremely difficult, perhaps impossible. The rug peddler assumes no further contact with the tourist, so conscience is the sole governor of his or her ethics. A second requirement for the conflict resolution/reduction methods used by the PM is that they allow (and foster) honesty between the negotiators. The conflicting parties-at-interest to a project are not enemies or competitors, but rather allies—members of an alliance with strong common interests. It is a requirement of all conflicting parties to seek solutions to the conflict that not only satisfy their own individual needs, but also satisfy the needs of other parties to the conflict, as well as the needs of the parent

162

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

organization. In the language of negotiation, this is called a “win-win” solution. Negotiating to a win-win solution is the key to conflict resolution in project management. Fisher et al. (1983, p. 11) have developed a negotiation technique that tends to maintain these three requirements. They call it “principled negotiation,” that is, win-win. The method is straightforward; it is defined by four points. 1. Separate the people from the problem. The conflicting parties are often highly emotional. They perceive things differently and feel strongly about the differences. Emotions and objective fact get confused to the point where it is not clear which is which. Conflicting parties tend to attack one another rather than the problem. To minimize the likelihood that the conflict will become strictly interpersonal, the substantive problem should be carefully defined. Then everyone can work on it rather than each other. 2. Focus on interests, not positions. Positional bargaining occurs when the PM says to a functional manager: “I need this subassembly by November 15.” The functional manager responds: “My group can’t possibly start on it this year. We might be able to deliver it by February 1.” These are the opening lines in a dialogue that sounds suspiciously like the haggling of the tourist and the rug peddler. A simple “Let’s talk about the schedule for this subassembly” would be sufficient to open the discussion. Otherwise each party develops a high level of ego involvement in his or her position and the negotiation never focuses on the real interests and concerns of the conflicting parties—the central issues of the conflict. The exchange deteriorates into a series of positional compromises that do not satisfy either party and leave both feeling that they have lost something important. In positional negotiation, the “positions” are statements of immediate wants and assume that the environment is static. Consider these positional statements: “I won’t pay more than $250,000 for that property.” Or, as above, “We might be able to deliver it by February 1.” The first position assumes that the bidder’s estimates of future property values are accurate, and the second assumes that the group’s current workload (or a shortage of required materials) will not change. When negotiation focuses on interests, the negotiator must determine the underlying concern of the other party. The real concerns or interests of the individuals stating the positions quoted above might be to earn a certain return on the investment in a property, or to not commit to delivery of work if delivery on the due date cannot be guaranteed. Knowledge of the other party’s interests allows a negotiator to suggest solutions that satisfy the other party’s interests without agreeing with the other’s position. 3. Before trying to reach agreement, invent options for mutual gain. The parties-in-conflict usually enter negotiations knowing the outcome they would like. As a result, they are blind to other outcomes and are not particularly creative. Nonetheless, as soon as the substantive problems are spelled out, some effort should be devoted to finding a wide variety of possible solutions— or elements thereof—that advance the mutual interests of the conflicting parties. Success at finding options that produce mutual gain positively reinforces win-win negotiations. Cohen (1980) reports on a conflict between a couple in which “he” wanted to go to the mountains and “she” wanted to go to the shore. A creative win-win solution sent them both to Lake Tahoe. 4. Insist on using objective criteria. Rather than bargaining on positions, attention should be given to finding standards (e.g., market value, expert opinion, law, company policy) that can be used to determine the quality of an outcome. Doing this tends to make the negotiation less a contest of wills or exercise in stubbornness. If a functional manager wants to use an expensive process to test a part, it is acceptable for the PM to ask if such a process is required to ensure that the parts meet specified quality standards. Fisher et al. (1983) have had some success with their approach in the Harvard (Graduate School of Business) Negotiation Project. Use of their methods increases the chance of finding win-win solutions.

4.4

PMBOK Guide 9.3, 9.4

SOME REQUIREMENTS AND PRINCIPLES OF NEGOTIATION

163

There are many books on negotiation, some of which are listed in the bibliography of this chapter. Most of these works are oriented toward negotiation between opponents, not an appropriate mindset for the project manager, but all of them contain useful, tactical advice for the project manager. Wall’s book (1985) is an excellent academic treatment of the subject. Fisher et al. (1983) is a clear presentation of principled negotiation, and contains much that is relevant to the PM. In addition, Herb Cohen’s You Can Negotiate Anything (1980) is an outstanding guide to win-win negotiation. The importance of negotiation is beginning to be recognized by the project management profession (Dodson, 1998; Grossman, 1995; Long, 1997; and Robinson, 1997), but the subject has not yet found its way into the Project Management Body of Knowledge in discussions about conflict. Among the tactical issues covered by most books on negotiation are things the project manager, as a beginning negotiator, needs to know. For example, what should a negotiator who wishes to develop a win-win solution do if the other party to the conflict adopts a win-lose approach? What do you do if the other party tries to put you under psychological pressure by seating you so that a bright light shines in your eyes? What do you do if the other party refuses to negotiate in order to put you under extreme time pressure to accept whatever solution he or she offers? How do you settle what you perceive to be purely technical disputes? How should you handle threats? What should be your course of action if a functional manager, with whom you are trying to reach agreement about the timing and technology of a task, goes over your head and attempts to enlist the aid of your boss to get you to accept a solution you feel is less than satisfactory? How can you deal with a person you suspect dislikes you? Almost every writer on negotiation emphasizes the importance of understanding the interests of the person with whom you are negotiating. As we noted above, the positions taken by negotiators are not truly understandable without first understanding the interests and concerns that prompt those positions. The statement that a test requested for May 15 cannot be run until June 2 may simply mean that the necessary test supplies will not be delivered until the latter date. If the PM can get the supplies from another source in time for the May 15 deadline, the test can be run on schedule. But the ability to do this depends on knowing why the test was to be delayed. If the negotiation remains a debate on positions, the PM will never find out that the test could have been run on time. The key to finding a negotiator’s interests and concerns is to ask “Why?” when he or she states a position. The following vignette demonstrates the maintenance of a nonpositional negotiating style. This vignette is based on an actual event and was described to the authors by an “actor” in the case.

Project Management in Practice Negotiation in Action—The Quad Sensor Project

Dave Dogers, an experienced project manager, was assigned the project of designing and setting up a production system for an industrial instrument. The instrument would undoubtedly be quite delicate, so the design and fabrication methods for the shipping container were included in the project. Production of containers capable of meeting the specifications in this case were outside the experience of the firm, but

one engineer in the container group had worked with this type of package in a previous job. This engineer, Jeff Gamm, was widely recognized as the top design engineer in the container group. During the initial meetings on the project, which was organized as a weak matrix, Dogers asked Tab Baturi, manager of the Container Group, to assign Gamm to the project because of his unique

164

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

background. Baturi said he thought they could work it out, and estimated that the design, fabrication of prototypes, and testing would require about four weeks. The package design could not start until several shape parameters of the instrument had been set and allowable shock loadings for the internal mechanisms had been determined. The R&D group responsible for instrument design thought it would require about nine months of work before they could complete specifications for the container. In addition to the actual design, construction, and test work, Gamm would have to meet periodically with the instrument design team to keep track of the project and to consult on design options from the container viewpoint. It was estimated that the entire project would require about 18 months. Seven months into the project, at a meeting with Dave Dogers, the senior instrument design engineer, Richard Money, casually remarked: “Say, Dave, I thought Jeff Gamm was going to do the package for the Quad Sensor.” “He is, why?” Dogers replied. “Well,” said the engineer, “Gamm hasn’t been coming to the design team meetings. He did come a couple of times at the start of the project, but then young McCutcheon showed up saying that he would substitute for Gamm and would keep him informed. I don’t know if that will work. That package is going to be pretty tricky to make.” Dogers was somewhat worried by the news the engineer had given him. He went to Gamm’s office, as if by chance, and asked, “How are things coming along?” “I’m up to my neck, Dave,” Gamm responded. “We’ve had half a dozen major changes ordered from Baker’s office (V.P. Marketing) and Tab has given me the three toughest ones. I’m behind, getting behinder, and Baker is yelling for the new container designs. I can’t possibly do the Quad Sensor package unless I get some help—quick. It’s an interesting problem and I’d like to tackle it, but I just can’t. I asked Tab to put McCutcheon on it. He hasn’t much experience, but he seems bright.” “I see,” said Dogers. “Well, the Quad Sensor package may be a bit much for a new man. Do you mind if I talk to Tab? Maybe I can get you out from under some of the pressure.” “Be my guest!” said Gamm.

The next day Dogers met with Tab Baturi to discuss the problem. Baturi seemed depressed. “I don’t know what we’re supposed to do. No sooner do I get a package design set and tested than I get a call changing things. On the Evans order, we even had production schedules set, had ordered the material, and had all the setups figured out. I’m amazed they didn’t wait till we had completed the run to tell us to change everything.” Baturi continued with several more examples of changed priorities and assignments. He complained that he had lost two designers and was falling further and further behind. He concluded: “Dave, I know I said you could use Gamm for the Quad Sensor job, but I simply can’t cut him loose. He’s my most productive person, and if anyone can get us out from under this mess, he can. I know McCutcheon is just out of school, but he’s bright. He’s the only person I can spare, and I can only spare him because I haven’t got the time to train him on how we operate around here—if you can call this ‘operating.’ ” The two men talked briefly about the poor communications and the inability of senior management to make up its collective mind. Then Dogers suggested, “Look, Tab, Quad Sensor is no more screwed up than usual for this stage of the project. How about this? I can let you borrow Charlotte Setter for three or four weeks. She’s an excellent designer and she’s working on a low-priority job that’s not critical at the moment. Say, I’ll bet I can talk Anderson into letting you borrow Levy, too, maybe half time for a month. Anderson owes me a favor.” “Great, Dave, that will help a lot, and I appreciate the aid. I know you understand my problem and you know that I understand yours.” Baturi paused and then added, “You realize that this won’t take much pressure off Jeff Gamm. If you can get him the designing help he needs he can get more done, but I can’t release him for the amount of time you’ve got allocated for the Quad Sensor.” They sat quietly for a while, then Dogers said, “Hey, I’ve got an idea. Container design is the hard problem. The production setup and test design isn’t all that tough. Let me have Gamm for the container design. I’ll use McCutcheon for the rest of the project and get him trained for you. I can get Carol Mattson to show him how to set up the shock tests and he can

GLOSSARY

get the word on the production setup from my senior engineer, Dick Money. Baturi thought a moment. “Yeah, that ought to work,” he said. “But Gamm will have to meet with your people to get back up to speed on the project. I think he will clean up Baker’s biggest job by Wednesday. Could he meet with your people on Thursday?” “Sure, I can arrange that,” Dogers said. Baturi continued. “This will mean putting two people on the package design. McCutcheon will have

165

to work with Gamm if he is to learn anything. Can your budget stand it?” “I’m not sure,” Dogers said, “I don’t really have any slack in that account, but . . . ” “Never mind,” interrupted Baturi, “I can bury the added charge somewhere. I think I’ll add it to Baker’s charges. He deserves it. After all, he caused our problem.” Source: S. J. Mantel, Jr. Consulting Project.

SUMMARY This chapter addressed the need for negotiation as a tool to resolve project conflicts. We discussed the nature of negotiation and its purpose in the organization. We also described various categories of conflict and related them to the project life cycle. We followed this by identifying a number of requirements and principles of negotiation. Finally, we presented a short vignette illustrating an actual negotiation situation. Specific points made in the chapter were these:

Negotiation within the firm should be directed at obtaining the best outcome for the organization, not winning.

There are three traditional categories of conflict: goal-oriented, authority-based, and interpersonal.

There are also three traditional sources of conflict. They are the project team itself, the client, and functional and senior management. We added the problem/discipline orientation of people working on the project.

Critical issues to handle in the project formation stages are delimiting technical objectives, getting management commitment, setting the project’s

• • •

relative priority, and selecting the project organizational structure. The total level of conflict is highest during the project buildup stage. Scheduling and technical conflicts are most frequent and serious in the project buildup and main program stages, and scheduling conflicts in particular during the phase-out stage. Project negotiation requirements are that conflicts must be settled without permanent damage, the methodology must foster honesty, and the solution must satisfy both individuals’ and the organization’s needs. One promising approach to meeting the requirements of project negotiation is called “principled negotiation.”

In the next chapter we move to the first task of the PM, organizing the project. We deal there not only with various organizational forms, such as functional, project, and matrix, but also with the organization of the project office. This task includes setting up the project team and managing the human element of the project.

GLOSSARY Interfaces The boundaries between departments or functions. Lateral Relations Communications across lines of equivalent authority. Pareto-Optimal Solution A solution such that no party can be made better off without making another party worse off by the same amount or more.

Positional Negotiation Stating immediate wants on the assumption that the environment is static. Principled Negotiation A process of negotiation that aims to achieve a win-win result. Parties-at-interest Those who have a vested interest in the outcome of the negotiations. Win-win When both parties are better off in the outcome.

166

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

QUESTIONS Material Review Questions 1. Review and justify the placement of the seven types of

4. What are the three main requirements of project

conflicts into the nine cells of Table 4-1. 2. Discuss each of the four fundamental issues for poten-

tial conflict during the project formation stage. 3. Identify the types of likely conflicts during the project

buildup, main program, and phaseout stages.

5. 6. 7. 8.

negotiation? Describe the four points of principled negotiation. What is the objective of negotiation? What are the four categories of conflict? What is “principled negotiation”?

Class Discussion Questions 9. Summarize the vignette in the chapter in terms of the

Habitat for Humanity Wins a Big One

negotiation skill used. Comment on the appropriateness and ethical aspects related to “burying” the cost. 10. What will be the likely result of a win-win style manager negotiating with a win-lose style manager? What if they are both win-lose styled? 11. Reallocate the placement of the seven types of conflicts into the nine cells of Table 4-1 according to your own logic.

18. Did LHH use any of the principles of negotiation described in the chapter? 19. How did LHH use the concept of “lateral relations?” 20. How do the concepts of partnering and scope change apply, or not apply, in this example?

12. How does the type of project organization affect each

approach indeed lead to a solution acceptable to all? Why wasn’t everyone happy with this outcome? 22. Based on this case situation, does the consensus approach lead to what is best for the overall community? Why (not)? 23. What approach should have been adopted to determine what was best for the overall community?

of the types of conflicts that occur over the project life cycle? 13. Project managers are primarily concerned with project

interfaces. At what rate do these interfaces increase with increasing project size? 14. The critical term in the concept of principled negotia-

tion is “position.” Elaborate on the multiple meanings of this term relative to negotiation. Can you think of a better term? 15. Give an example of a Pareto-optimal solution in a

conflict. 16. Given that many conflicts are the result of different par-

ties having different interests, is it possible to achieve a win-win situation? 17. The chairman of Cadbury Schweppes PLC, G.A.H. Cadbury suggests (1987) the following test for an ethical action: Would you be embarrassed to have it described in the newspaper? Is this a sufficient test for ethics? Can you think of any others?

A Consensus Feasibility Study for Montreal’s Archipel Dam 21. Given the results of the study, did the consensus

Negotiation in Action—The Quad Sensor Project 24. What categories of conflict occurred in this project? At

what stage was the project? 25. What negotiation techniques were used here? How

successful were they? Quickly Building a Kindergarten through Negotiation

26. Is time unpredictable? What did the carpenter mean? 27. Did Ms. Lange use any of the principles of negotiation in this project? 28. At some point do you think the team had to think about the goals of the reality show compared to the needs of the African slum children?

INCIDENTS FOR DISCUSSION Pritchard Soap Co.

Samantha (“Sam”) Calderon is manager of a project that will completely alter the method of adding perfume to Pritchard Soap’s “Queen Elizabeth” gift soap line. The new process will greatly extend the number of available scents and should result in a significant increase in sales. The

project had been proceeding reasonably well, but fell several weeks behind when the perfume supplier, the Stephen Marcus Parfumissary, was unable to meet its delivery deadline because of a wildcat strike. Under normal circumstances this would not have caused problems, but the project had been subject to a particularly

BIBLIOGRAPHY

long evaluation study and now was in danger of not being ready for the Christmas season. The major scheduling problem concerned Pritchard’s toxicity lab. Kyle Lee, lab manager, had been most cooperative in scheduling the Queen Elizabeth perfumes for toxicity testing. He had gone out of his way to rearrange his own schedule to accommodate Sam’s project. Because of the strike at Marcus, however, Sam cannot have the perfumes ready for test as scheduled, and the new test date Lee has given Sam will not allow her to make the new line available by Christmas. Sam suspects that the project might not have been approved if senior management had known that they would miss this year’s Christmas season. Questions: What was the source of change in this project and how will it affect the project’s priority? What are Sam’s alternatives? What should she do? Sutton Electronics

Eric Frank was still basking in the glory of his promotion to marketing project manager for Sutton Electronics Corporation, manufacturer of electronic fire alarm systems for motels, offices, and other commercial installations. Eric’s first project involved the development of a marketing plan for Sutton’s revolutionary new alarm system based on sophisticated circuitry that would detect and identify a large number of dangerous gases as well as smoke and very high temperatures. The device was the brainchild of Ira Magee, vice-president of research

167

and the technical wizard responsible for many of Sutton’s most successful products. It was unusual for so young and relatively inexperienced an employee as Eric to be given control of such a potentially important project, but he had shown skill in handling several complex, though routine, marketing assignments. In addition, he had the necessary scientific background to allow him to understand the benefits of Magee’s proposed gas detection system. Four weeks into the project, Eric was getting quite worried. He had tried to set up an organizational and planning meeting several times. No matter when he scheduled the meeting, the manager of the manufacturing department, Jaki Benken, was unable to attend. Finally, Eric agreed that manufacturing could be represented by young Bill Powell, a Benken protégé who had just graduated from college and joined Sutton Electronics. However, Eric was doubtful that Powell could contribute much to the project. Eric’s worry increased when Powell missed the first planning meeting completely and did not appear at the second meeting until it was almost over. Powell seemed apologetic and indicated that plant floor crises had kept him away from both meetings. The project was now five weeks old, and Eric was almost three weeks late with the marketing master plan. He was thinking about asking Ira Magee for help. Questions: Do you think that Eric should involve Magee at this point? If so, what outcome would you expect? If not, what should he do?

CONTINUING INTEGRATIVE CLASS PROJECT The topic of negotiation will come up in two guises during the class project: When the PM is trying to assign tasks to the class members and they are resisting, and also possibly when the PM or class is negotiating for resources with the Instructor, the Dean, or others. The topic of conflict can arise at any time and over any issue, obviously. In all these

circumstances, the individuals would be well advised to recall the principles of negotiation (or quickly refer back to this chapter). The class historian should also be noting when conflicts and bargaining occurred during the project, as well as its nature, and resolution.

BIBLIOGRAPHY Adams, J. R., and S. E. Barndt. “Behavorial Implications of the Project Life Cycle.” In D. I. Cleland and W. R. King, eds., Project Management Handbook. New York: Van Nostrand Reinhold, 1983. Afzalur, R. M. Managing Conflict in Organizations. Westport, CT: Praeger, 1992. Baker, K. R. “Measuring the Benefits of Partnering.” PM Network, June 1996. Beecham, M. A., and M. Cordey-Hayes. “Partnering and Knowledge Transfer in the U.K. Motor Industry.” Technovation, March 1998.

Cadbury, G. A. H. “Ethical Managers Make Their Own Rules.” Harvard Business Review, September–October 1987. Cohen, H. You Can Negotiate Anything. Secaucus, NJ: Lyle Stuart Inc., 1980. Cowen, C., C. Gray, and E. W. Larson. “Project Partnering.” Project Management Journal, December 1992. de Laat, P. B. “Matrix Management of Projects and Power Struggles: A Case Study of an R&D Laboratory.” IEEE Engineering Management Review, Winter 1995, reprinted from Human Relations, Vol. 47, No. 9, 1994.

168

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

Fisher, R., and W. Ury. Getting to Yes. Harmondsworth, Middlesex, G.B.: Penguin Books, 1983. Grossman, J. “Resolve Conflicts So Everybody Wins.” PM Network, September 1995. Hughes, T. P. Rescuing Prometheus, New York: Pantheon, 1998. Larson, E. W., and J. A. Drexler, Jr. “Barriers to Project Partnering: Reports from the Firing Line.” Project Management Journal, March 1997. Long, A. “Negotiating the Right Decision.” PM Network, December 1997. Moore, C. C., J. D. Maes, and R. A. Shearer. “Recognizing and Responding to the Vulnerabilities of Partnering.” PM Network, September 1995. Pelled, L. H., and P. S. Adler. “Antecedents of Intergroup Conflict in Multifunctional Product Development Teams: A Conceptual Model.” IEEE Transactions on Engineering Management, February 1994. Raiffa, H. The Art and Science of Negotiation. Cambridge: Belknap/Harvard Press, 1982. Robinson, T. “When Talking Makes Things Worse!” PM Network, March 1997.

Roget’s International Thesaurus. New York: Thomas Y. Crowell, 1993. Rosegger, G., and S. J. Mantel, Jr. “Competitors as Consultants: Collaboration and Technological Advance.” J. Allesch (Ed.), Consulting in Innovation: PracticeMethods-Perspectives, Amsterdam: Elsevier, 1990. Smith, M. B. “Financial Constraints on Service and Outsourcing Projects.” PM Network, October 1998. Thamhain, H. J., and D. L. Wilemon. “Conflict Management in Project Life Cycles.” Sloan Management Review, Summer 1975a. Thamhain, H. J., and D. L. Wilemon. “Diagnosing Conflict Determinants in Project Management.” IEEE Transactions on Engineering Management, February 1975b. Thomas, K. “Conflict and Conflict Management.” In M. D. Dunnette (Ed.), Handbook of Industrial and Organizational Psychology, Chicago: Rand McNally, 1976. Wall, J. A., Jr. Negotiation: Theory and Practice. Glenview, IL: Scott, Foresman, 1985.

The following classic article describes a number of methods for negotiating and handling conflicts. The author identifies effective and ineffective methods ranging from withdrawal to forcing. Each method is then illustrated with a number of examples. Finally, the most effective method, Confrontation Problem Solving, is described in terms of its many characteristics.

D I R E C T E D

R E A D I N G

METHODS OF RESOLVING INTERPERSONAL CONFLICT* R. J. Burke

The management of conflict in creative and useful ways, rather than its containment or abolition, has been proposed by many writers. Various strategies for dealing with conflict at different levels and for managing disagreements have also been proposed. Most of these methods have not been experimentally evaluated. Given the central and inevitable role of conflict in human affairs, a high priority of importance is to be placed on learning the most effective way to resolve it. *Reprinted from Personnel Administration, with permission. Copyright International Personnel Management Association.

Purpose of This Study In an early investigation, Burke collected questionnaire data from 74 managers, in which they described the way they and their superiors dealt with conflict between them. It was possible to relate five different methods of conflict resolution originally proposed by Blake and Mouton (1964)—Withdrawing, Smoothing, Compromising, Forcing, and Confrontation or Problem Solving—to two major areas of the superior-subordinate relationship. These were (1) constructive use of differences and disagreements, and (2) several aspects of the superior-subordinate relationship in planning job targets and evaluating accomplishments.

DIRECTED READING

In general, the results showed that Withdrawing and Forcing behaviors were consistently negatively related to these two areas. Compromising was not related to these two areas. Use of Smoothing was inconsistently related, sometimes positive and sometimes negative. Only Confrontation-Problem Solving was always related positively to both. That is, use of Confrontation was associated with constructive use of differences and high scores on various measures of the superior-subordinate relationship. This study has the dual purpose of attempting to specify more precisely the characteristics of the ConfrontationProblem Solving method of conflict resolution, and replicating Burke’s earlier study using different methodology.

Method Subjects: The respondents were managers from various organizations who were enrolled in a university course emphasizing behavioral science concepts relevant to the functions of management. Their organizational experience ranged from one year to over 30 years. Procedure: Each respondent was asked to describe a time when he felt particularly GOOD (or BAD) about the way in which an interpersonal conflict was resolved. The specific instructions stated: “Think of a time when you felt especially GOOD (or BAD) about the way an interpersonal conflict or disagreement (e.g., boss-subordinate, peer-peer, etc.) in which you were involved was resolved. It may have been on your present job, or any other job, or away from the work situation. “Now describe it in enough detail so a reader would understand the way the conflict or differences were handled.” This statement appeared at the top of a blank sheet of paper. Approximately half the respondents were first to describe the instance when they felt particularly good, followed by the instance when they felt particularly bad. The remaining respondents described the instances in the reverse order. No apparent effects were observed from the change in order, so the data from both groups will be considered together in this report.

Results Fifty-three descriptions of effective resolution of conflict (felt especially GOOD) and 53 descriptions of ineffective resolutions of conflict (felt especially BAD) were obtained. These were provided by 57 different individuals. Some individuals provided only one example. The response rate was about 70 percent of the total available population. The written descriptions were then coded into one of the five methods of conflict resolution proposed by Blake and Mouton.

169

1. Withdrawing—easier to refrain than to retreat from an argument; silence is golden. “See no evil, hear no evil, speak no evil.” 2. Smoothing—play down the differences and emphasize common interests; issues that might cause divisions or hurt feelings are not discussed. 3. Compromising—splitting the difference, bargaining, search for an intermediate position. Better half a loaf than none at all; no one loses but no one wins. 4. Forcing—a win-lose situation; participants are antagonists, competitors, not collaborators. Fixed positions, polarization. Creates a victor and a vanquished. 5. Confrontation-Problem Solving—open exchange of information about the conflict or problem as each sees it, and a working through of their differences to reach a solution that is optimal to both. Both can win. Table 1 presents the method of conflict resolution associated with effective resolution (left half of Table 1) and ineffective resolution (right half of Table 1). Considering the left half of the table, Confrontation-Problem Solving was the most common method for effective resolution (58.5%), followed by Forcing (24.5%), and Compromise (11.3%). The prominence of Confrontation as an effective method is consistent with Burke’s earlier study but the value for Forcing was higher than expected. When these 13 cases are considered as a group, 11 of them are similar in that the party providing the written description benefited as a result of the Forcing. That is, Forcing was perceived as an effective method of resolving conflict by the victor, but not by the vanquished.

Table 1 Methods Associated with Effective and Ineffective Conflict Resolution

170

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

Moving to the right half of Table 1, Forcing was the most commonly used method for ineffective resolution, followed in second place by Withdrawal with only 9.4 percent. The vast majority of individuals providing written descriptions of Forcing methods were victims or “losers” as a result of Forcing behavior. In summary, the major differences in methods of conflict resolution found to distinguish effective versus in effective examples were: (1) significantly greater use of Confrontation in the effective examples (58.5% vs. 0.0%); (2) significantly less use of Forcing in the effective examples (24.5% vs. 79.2%); and (3) significantly less use of Withdrawing in the effective examples (0.0% vs. 9.4%). When Forcing was seen to be effective, the authors of the examples were “winners” of a win-lose conflict; when Forcing was seen to be ineffective, the authors of the examples were “losers” of a win-lose conflict. Whether the resolution of conflict via Forcing would actually be perceived to be effective by members of the organization outside the conflict (i.e., objectively seen as effective), as it was perceived to be effective by the “winners,” remains to be determined by future research.

Effective Conflict Resolution A few of the examples of effective conflict resolution are provided to highlight specific features of Confrontation. These were taken verbatim from the written descriptions. 1. This example highlights the presentation of a problem of mutual interest—meeting deadlines more often at the earliest opportunity (when the problem is observed). Superior is open-minded and asking for help. “I once was given the responsibility for managing a small group of technicians engaged in turning out critical path schedules. I spent some time trying to get organized and involved with the group, but I sensed a hostile atmosphere, accompanied by offhand sarcastic remarks. At the end of the day very little work had been accomplished. “The next day when I came in, I called the group together and told them that we were falling behind, and asked them to help me find a solution. After the initial distrust had been dissipated, the group produced some good ideas on work reallocation, office arrangement, priorities and techniques. I told the group that all of their agreedupon suggestions would be implemented at once, and their reply was that the backlog would be cleared in three days and would not build up again. “Within three days the backlog was gone, the group worked together better, and for the six months I was in charge, schedules were always ready before they were required.” 2. This example highlights emphasis on facts in determining the best resolution of conflict. Both had strong

convictions but one willingly moved to the other’s position when facts indicated that this position was best. “The project engineer and I disagreed about the method of estimating the cost of alternative schemes in a highway interchange. Neither of us could agree on the other’s method. Eventually I was able to satisfy him using algebra. We were both happy with the result.” 3. Like Example 2, this one highlights an emphasis on facts and the conviction that by digging and digging, the truth will be discovered. Although the superior had a vested interest in the “old” system (a product of his thinking), the discussion was never personalized. That is, it did not involve “me” versus “you,” but rather a comparison of two systems, two concepts or two ideas. “About a year ago I developed a new system for processing the accounting of the inventory of obsolete material on hand in our plant. It was my estimation that it would prove to be an easier system to operate and control and would also involve a considerable monetary saving for the company. “When I approached my boss with the system, he immediately turned it down as he had developed the present system and was sure it was the best possible system. As I was sure my new system was superior to the present one, I then convinced him to join me in analyzing a comparison of the two systems, pointing out the strengths and weaknesses of the two. After a period of evaluation involving many differences of opinion, we were able to resolve that my system had definite merit and should be brought into operation.” 4. This example highlights the fact that through problem solving both parties can benefit. Instead of compromising, the issues are discussed until a solution completely satisfactory to both is found. Often this is superior to the ones initially favored by the separate parties. “In the XXX Board of Education, there were eight inspectors of Public Schools and four superintendents. Last February the inspectors were given the assignment of developing an in-service plan for the training of teachers for the next school year. The inspectors gave the assignment to a group of three of their number who were to bring a report to the next inspectors’ meeting. I was not a member of the in-service committee but in conversations with the committee members I discovered that they contemplated having an in-service program for two teachers from each school (there are about 85 schools) once a month for the entire year in mathematics. I felt that this would be a very thin coverage of our 2000 or so teachers. “Consequently I worked on a plan whereby utilizing two Thursday mornings a month and the specialized teaching help available in XXX, every teacher would have the opportunity to become involved in an in-service training session in a subject of his or her choice once during the year. At the inspectors’ meeting the subcommittee presented its report and after some procedural wrangling I was permitted to present my plan. The two were diametrically opposed and it looked as if

DIRECTED READING

my plan would be voted down except the chairman suggested that both plans be presented to the superintendents. “At the meeting of the superintendents, the subcommittee made its report and I presented my plan. As the meeting progressed there was some give and take and instead of one or the other being discarded, both plans were adopted. For this school year mathematics is stressed for the first eight Thursday mornings (their plan in a rather concentrated form); then for the next eight months on the second and fourth Thursday my plan is used. We came out of this meeting with a combination of the two plans which was better than either one individually.”

Ineffective Conflict Resolution Examples 5, 6, and 7 illustrate Forcing methods of conflict resolution. A win-lose situation is set up, and usually the superior wins. The individual with the greater power triumphs (a personalized disagreement) rather than the one whose position is supported by the most factual evidence. 5. “In a previous job, I worked for a major management consulting group as a consultant. One assignment, lasting four months, was to use a simulation technique to evaluate the most preferable investment decision using defined quantitative criteria. At the end of the job two alternatives were shown to be marginally better than the other. However, later sensitivity tests also showed that the analytical technique could not rate one to be substantially better than the other. “Therefore, I wrote a ‘technically honest’ report stating that our analysis could not provide the one best alternative. My manager, feeling that we were hired to recommend a ‘one best’ alternative, wanted to cover up the limitations of our methodology. “We disagreed and I was overruled. The manager wrote a ‘technically dishonest’ version of the report and the revised report was sent to the client indicating the ‘one best’ alternative.” 6. “Recently in my firm, management had sprung a secrecy agreement contract upon all of the technical people. No word of introduction or explanation was given. It was simply handed out and we were asked to sign it. Most of us found objection in several clauses in the agreement. However, management officials stated that the agreement would probably not stand up in a court of law. They further stated that it was something that was sent from corporate in the United States and was not their idea. The employees continued to show reluctance. “The vice-president called on everyone individually and stated that there would be no room for advancement for anyone who did not sign the contract. As a result, everyone signed.” 7. “I was assigned a project by my boss to determine the optimum way, using predetermined times, to lay out an assembly line. It would have to provide optimum efficiency

171

with the following variables: (a) different hourly production rates (e.g., 100/hr. Mon., 200/hr. Tues.) which would mean different numbers of operators on the line; (b) different models of the product (electric motors). The group was on group incentive. “After much research and discussion, the system was installed utilizing the floating system of assembly (operators could move from station to station in order to keep out of the bottleneck operation). This system was working out well. However, at this time I was informed by my boss that he and the foreman of the area decided that they wished to use the ‘paced’ system of assembly. This would mean the conveyor belt would be run at set speeds and that the stripes would be printed on the belt indicating that one device would have to be placed on each mark and operators would not float. “I was dead against this since I had considered it and rejected it in favor of the implemented method. I was, however, given the order to use their proposed system or else. There was no opportunity for discussion or justification of the method.” 8. This example is a classic description of Withdrawal as a mode of conflict resolution. Clearly the problem is not resolved. “On the successful completion of a project which involved considerable time and effort, I was praised and thanked for a job well done by my immediate supervisor and his supervisor, the vice-president in charge of manufacturing. They promised me that on my next salary review I would receive a substantial increase. “The next salary review came up and my immediate supervisor submitted an amount that he and I felt was a good increase. The amount I received was one-third of this figure. I felt insulted, cheated, and hurt that the company considered I was worth this ‘token’ amount. “I had a personal interview with the vice-president where I argued that I felt I should receive more. He agreed in sort of an offhanded way—he felt the whole salary schedule should be reviewed and that my area of responsibility should be increased. He said the company wants people to ‘prove themselves’ before they give them increases; and he suggested a salary review. I felt I had just done this in my last project— I felt I was being put off, but agreed to the salary review. “One month passed and nothing happened. I became frustrated—I purposely slowed down the amount of work I turned out. “Another month passed and still no action. I became disillusioned with the company and resolved at this point to look for another position. Several months later with still no action, I resigned and accepted another position.”

Inability to Resolve Conflict These descriptions of ineffective resolution of conflict indicate that an impressive number of respondents included termination or change of employment of one member in the

172

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

situation (19 of 53, 26%). These cases tended to be of two types. The first is represented by Example 8. Here an employee decides to quit because he felt the problem was not resolved in a satisfactory manner. Forcing is likely to be associated with instances of voluntary termination. The second centered around an inability to resolve the conflict. Then the “problem employee” (a visible symptom of the conflict) was dismissed. 9. The following example illustrates this: “This concerned a young girl about 18 years old who was a typist in our office. This girl lacked a little maturity, but was not really all that bad. She was tuned to all the latest fashions in both dress and manners. “I felt and still feel that this girl was a potentially good employee. But it was decided that she should be let go. The argument used was that she was not a good worker and lacked the proper attitude for office work. Rather than spend a little time and effort to understand the girl and perhaps develop her into a good employee, the easy way was taken and the girl was fired.” There were two other clear cases of “effective” conflict resolution resulting in voluntary employee terminations. In both instances a Forcing mode was employed and the “loser” resigned from the organization soon after. Our finding is that these were given as examples of effective conflict resolution by the “winner.” In another effective example of Forcing, the “loser” was dismissed.

Conclusions The results of this investigation are consistent with earlier studies showing the value of Confrontation-Problem Solving as a method of conflict resolution. About 60 percent of the examples of effective conflict resolution involved use of the method, while no examples of ineffective conflict resolution did. The poorest method of conflict resolution was Forcing. This method accounted for 80 percent of the examples of ineffective conflict resolution and only 24 percent of the examples of effective conflict resolution. The latter conclusion is somewhat at odds with Lawrence and Lorsch’s findings that Forcing was an effective backup method to Confrontation, from an organizational effectiveness standpoint. In fact, Burke’s earlier study found that the use of these methods tended to be negatively correlated. Managers high in use of one of them tended to be low in use of the other.

Characteristics of Problem Solving Let us now consider more specific features of Confrontation, the most effective method of resolving interpersonal conflict. Insights from the present investigation and the writings of others becomes relevant. The following then are

characteristics of Confrontation as a method of managing conflict: 1. Both people have a vested interest in the outcome (Examples 1, 2, 3, and 4). 2. There is a belief on the part of the people involved that they have the potential to resolve the conflict and to achieve a better solution through collaboration. 3. There is a recognition that the conflict or the problem is mainly in the relationship between the individuals and not in each person separately. If the conflict is in the relationship, it must be defined by those who have the relationship. In addition, if solutions are to be developed, the solutions have to be generated by those who share the responsibility for assuring that the solution will work and for making the relationship last. 4. The goal is to solve the problem, not to accommodate different points of view. This process identifies the causes of reservation, doubt, and misunderstanding between the people confronted with conflict and disagreement. Alternative ways of approaching conflict resolution are explored and tested (Examples 2 and 3). 5. The people involved are problem-minded instead of solution-minded; “fluid” instead of “fixed” positions. Both parties jointly search out the issues that separate them. Through joint effort, the problems that demand solutions are identified, and later solved. 6. There is a realization that both aspects of a controversy have potential strengths and potential weaknesses. Rarely is one position completely right and the other completely wrong (Example 4). 7. There is an effort to understand the conflict or problem from the other person’s point of view, and from the standpoint of the “real” or legitimate needs that must be recognized and met before problem solving can occur. Full acceptance of the other is essential. 8. The importance of looking at the conflict objectively rather than in a personalized sort of way is recognized (Example 3). 9. An examination of one’s own attitudes (hostilities, antagonisms) is needed before interpersonal contact on a less effective basis has a chance to occur. 10. An understanding of the less effective methods of conflict resolution (e.g., win-lose, bargaining) is essential. 11. One needs to present “face-saving” situations. Allow people to “give” so that a change in one’s viewpoint does not suggest weakness or capitulation. 12. There is need to minimize effects of status differences, defensiveness, and other barriers which prevent people from working together effectively.

DIRECTED READING

13. It is important to be aware of the limitations of arguing or presenting evidence in favor of your own position while downgrading the opponent’s position. This behavior often stimulates the opponent to find even greater support for his position (increased polarization). In addition, it leads to selective listening for weaknesses in the opponent’s position rather than listening to understand his or her position.

Attitude, Skill, and Creativity Two related themes run through these characteristics, one dealing with attitudes, and the other with skills (interpersonal, problem solving) of the individuals involved. As the research of Maier and his associates has shown, differences and disagreements need not lead to dissatisfaction and unpleasant experiences but rather can lead to innovation and creativity. One of the critical variables was found to be the leader’s attitudes toward disagreement. The person with different ideas, especially if he or she is a subordinate, can be seen as a problem employee and troublemaker or as an innovator, depending on the leader’s attitude. There are some people that go through life attempting to sell their ideas, to get others to do things they do not want to do. They set up a series of win-lose situations, and attempt to emerge victorious. Many of these people are able to accomplish their ends. There are others who are more concerned with the quality and effectiveness of their operations, and who, with creative solutions to problems, are genuinely openminded and able and willing to learn from others (and to teach others), in a collaborative relationship. The interpersonal skills are related to the development of a “helping relationship” and include among other things, mutual trust and respect, candid communication, and awareness of the needs of others. The problem solving skills center around locating and stating the problem, seeking alternatives, exploring and testing alternatives, and selecting the best alternative. Knowledge and insight gained through experience with the benefits of problem solving and the dysfunctional effects of other strategies would be valuable in developing interpersonal skills.

Further Research Needed Two additional areas need immediate research consideration. The first needs to explore the notions of conflict resolution from the organizational as well as the individual viewpoint. Lawrence and Lorsch report that Forcing was an effective backup mode to Confrontation from the organization’s standpoint, because at least things were being done. Our data in two separate investigations indicate that this mode of conflict resolution is very unsatisfactory from the standpoint of the one forced, the “loser,” and may also have dysfunctional consequences.

173

The second research area concerns the application of these principles of effective conflict resolution (ConfrontationProblem Solving, with their more specific attitudinal and skill components) in an attempt to arrive at more constructive use of disagreement. Preliminary results from an experiment simulating conflict situations using role playing suggest that knowledge of these principles and some limited practice in their use increases one’s ability to use differences constructively in obtaining a quality solution, and decreases the tendency to engage in “limited war,” as Burke called it. References Blake, R. R., and J. S. Mouton. The Managerial Grid, Houston: Gulf Publishing Company, 1964. Blake, R. R., H. A. Shepard, and J. S. Mouton. Managing Intergroup Conflict in Industry, Houston: Gulf Publishing Company, 1964. Boulding, K. “A pure theory of conflict applied to organization.” In R. I. Kahn and E. Boulding (eds.), Power and Conflict in Organizations. New York: Basic Books, Inc., 1964, pp. 136–145. Burke, R. J. “Methods of managing superior-subordinate conflict: Their effectiveness and consequences.” Unpublished manuscript, 1969a. Burke, R. J. “Effects of limited training on conflict resolution effectiveness.” Unpublished manuscript, 1969b. Kata, D. “Approaches to managing conflict.” In R. L. Kahn and E. Boulding (eds.), Power and Conflict in Organizations. New York: Basic Books, Inc., 1964, pp. 105–114. Lawrence, P. R., and J. W. Lorsch. “Differentiation and integration in complex organizations.” Administrative Science Quarterly, 1967a, 12, 1–47. Lawrence, P. R., and J. W. Lorsch. Organization and Environment, Boston: Division of Research, Harvard Business School, Harvard University, 1967b. Maier, N. R. F. Problem-Solving Discussions and Conferences. New York: McGraw-Hill, 1963. Maier, N. R. F., and L. R. Hoffman. “Acceptance and quality of solutions as related to leaders’ attitudes toward disagreement in group problem-solving.” Journal of Applied Behavioral Science, 1965, 1, pp. 373–386. McGregor, D. The Professional Manager. New York: McGraw-Hill, 1967. Shepard, H. A. “Responses to situations of competition and conflict.” In R. L. Kahn and E. Boulding (eds.), Power and Conflict in Organizations. New York: Basic Books, Inc., 1964, pp. 127–135.

174

CHAPTER 4 / MANAGING CONFLICT AND THE ART OF NEGOTIATION

Questions 1. In Table 1, what was the second best resolution technique? What was the worst resolution technique? What do you conclude from this? 2. Which of the four examples of conflict resolution is the best example, in your opinion, of effective resolution? Why? 3. Of the ineffective resolution examples, which was the worst, in your opinion? Why?

4. Summarize or condense the 13 characteristics of Confrontation as a conflict-resolving method. 5. The article concludes on the note that conflict need not be a bad thing. Compare this view with that in the chapter concerning the win-win approach to negotiation.

C

H

A

P

T

E

R

5 The Project in the Organizational Structure

A firm, if successful, tends to grow, adding resources and people, developing an organizational structure. Commonly, the focus of the structure is specialization of the human elements of the group. As long as its organizational structure is sufficient to the tasks imposed on it, the structure tends to persist. When the structure begins to inhibit the work of the firm, pressures arise to reorganize along some other line. The underlying principle will still be specialization, but the specific nature of the specialization will be changed. Any elementary management textbook covers the common bases of specialization. In addition to the ever-popular functional division, firms organize by product line, by geographic location, by production process, by type of customer, by subsidiary organization, by time, and by the elements of vertical or horizontal integration. Indeed, large firms frequently organize by several of these methods at different levels. For example, a firm may organize by major subsidiaries at the top level; the subsidiaries organize by product groups; and the product groups organize into customer divisions. These, in turn, may be split into functional departments that are further broken down into production process sections, which are set up as three-shift operating units. In the past decade or so, a new kind of organization structure has appeared in growing numbers—the project organization, a.k.a. “enterprise project management” (Dinsmore, 1998; Levine, 1998; Williams, 1997), also known as “managing organizations by projects,” the “project-oriented firm,” and other names. Such organizations have been described as applying “project management practices and tools across an enterprise” (Levine, 1998). The source of these organizations is probably in the software industry that has long made a practice of developing major software application programs by decomposing them into a series of comparatively small software projects. Once the projects are completed, they are integrated into the whole application system. A great many firms, both software and nonsoftware firms alike, have now adopted a system whereby their traditional business is carried out in the traditional way, but anything that represents a change is carried out as a project. One hospital, for example, operates the usual departments in what, for them, are the usual ways. At the same time, the hospital supports several dozen projects oriented toward developing new health care products, or changing various aspects of standard medical and administrative methods.

175

176

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

There are many reasons for the rapid growth of project-oriented organizations, but most of them can be subsumed in four general areas. First, speed and market responsiveness have become absolute requirements for successful competition. It is no longer competitively acceptable to develop a new product or service using traditional methods in which the potential new product is passed from functional area to functional area until it is deemed suitable for production and distribution. First-to-market is a powerful competitive advantage. Further, in many industries it is common (and necessary) to tailor products specifically for individual clients. Suppliers of hair care products or cosmetics, for example, may supply individual stores in a drug chain with different mixes of products depending on the purchase patterns, ethnic mix of customers, and local style preferences for each store. Second, the development of new products, processes, or services regularly requires inputs from diverse areas of specialized knowledge. Unfortunately, the exact mix of specialties appropriate for the design and development of one product or service is rarely suitable for another product or service. Teams of specialists that are created to accomplish their ad hoc purpose and disband typify the entire process. (See the PMIP sidebar on floating teams in Section 5.6 for an example of this approach.) Third, the rapid expansion of technological possibilities in almost every area of enterprise tends to destabilize the structure of organizations. Consider communications, entertainment, banks, consumer product manufacturing and sales, the automotive industry, aircraft manufacture, heavy electrical equipment, machine tools, and so forth without end. Mergers, downsizing, reorganizations, spin-offs, new marketing channels, and other similar major disturbances all require system-wide responsiveness from the total organization. Again, no traditional mechanism exists to handle change on such a large scale satisfactorily—but project organization can. Finally, TV, movies, novels, and other mythology to the contrary, a large majority of senior managers we know rarely feel much confidence in their understanding of and control over a great many of the activities going on in their organizations. The hospital mentioned above became a project-oriented organization because its new CEO strongly felt that she had no way of understanding, measuring, or controlling anything going on in the hospital except for the most routine, traditional activities. Transforming nonroutine activities into projects allowed her to ensure that accountability was established, projects were properly planned, integrated with other related activities, and reported routinely on their progress. Moving from a nonproject environment to one in which projects are organized and used to accomplish special tasks to a full-fledged project-oriented organization presents senior management of a firm with an extraordinarily difficult transition. A full treatment of this subject is beyond the scope of this book, but several observations are in order. First, the process is time consuming. Even when the required resources are available and senior management is fully committed to the transition, it is still an arduous process. Our experience indicates that when all goes well, the transition rarely requires less than three years. In an excellent article on the process of leading fundamental change in a complex organization, Kotter (1997) lists eight steps that must be successfully completed if the change is to be accomplished. Most of these are dependent on active leadership from top management. Whether the organization is conducting a few occasional projects or is fully project oriented and carrying on scores of projects, any time a project is initiated, three organizational issues immediately arise. First, a decision must be made about how to tie the project to the parent firm. Second, a decision must be made about how to organize the project itself. Third, a decision must be made about how to organize activities that are common to other projects. In Chapter 3 we discussed the selection of the project manager (PM) and described the difficulties and responsibilities inherent in the PM’s role. This chapter focuses on the interface between the project and its parent organization (i.e., how the project is organized as a part of

5.1

PMBOK Guide 2.4.2

5.1

PROJECTS IN A FUNCTIONAL ORGANIZATION

177

its host). In the latter part of this chapter, we begin a discussion of how the project itself is organized, a discussion that will be continued in the next chapter. First we look at the three major organizational forms commonly used to house projects and see just how each of them fits into the parent organization. (These three forms are also emphasized in PMBOK.) We examine the advantages and disadvantages of each form, and discuss some of the critical factors that might lead us to choose one form over the others. We then consider some combinations of the fundamental forms and briefly examine the implications of using combination structures. Finally, we discuss some of the details of organizing the project team, describing the various roles of the project staff. We then turn to the formation and operation of a project management office (PMO) that can provide critically important services for all projects. The skill with which the PMO organizes, administers, and carries out its responsibilities will have a major impact on the ability of projects to meet their objectives. We also describe some of the behavioral problems that face any project team. Finally, we discuss the impact that various ways of structuring projects may have on intraproject conflict in project-oriented firms. To our knowledge, it is rare for a PM to have much influence over the interface between the organization and the project, the choice of such interface usually being made by senior management. The PM’s work, however, is strongly affected by the project’s position in the organizational structure, and the PM should understand its workings. Experienced PMs do seem to mold the project’s organization to fit their notions of what is best. One project team member of our acquaintance remarked at length about how different life was on two projects run by different PMs. Study of the subtle impacts of the PM on the project structure deserves more attention from researchers in the behavioral sciences.

PROJECTS IN A FUNCTIONAL ORGANIZATION As one alternative for giving the project a “home” in a functionally structured organization, we can make it a part of one of the functional divisions of the firm, usually the function that has the most interest in ensuring its success or can be most helpful in implementing it. We commonly think of the functions of an organization as being those of Finance, Marketing, Operations (or Manufacturing), Human Resources, and so on. However, to consider a slightly different type of organization, Figure 5-1 is the organizational chart for the University of Cincinnati, a functionally organized institution. If U.C. undertook the development of a Master of Science program in Project Management (or perhaps an MPM), the project would probably be placed under the general supervision of the senior vice president and provost, under the specific supervision of the dean of the College of Business (and/or College of Engineering), and might be managed by a senior faculty member with a specialty in operations management. It might also be placed under the general supervision of the V.P. and dean for Graduate Studies and Research. Note that more than one choice of parent may exist, and if the project needs resources from some of the other functional areas, they are expected to help support the project. Another way a project may be organized in a functional organization is to assign the work to all the relevant functional divisions with either top management overseeing the effort or else someone assigned to coordinate their efforts, perhaps as a project manager or possibly as just a facilitator. A project to increase the percentage of women in senior management might thus involve all the U.C. functions and might be coordinated through the President’s office, the Affirmative Action office, or possibly using someone from Personnel in the Administration function.

Administrative Policy Procedures Coordination Personnel Benefits Compensation Employment Labor and Employee Relations Records Training and Development

University of Cincinnati organization chart.

Figure 5-1

Graduate Education Research Administration Research Institutes

Government and Behavioral Science Legislative Liaison Laboratory (Local, State, and National) Institute of Governmental Information Services Research Public Relations Institutional Research

Accounting and Budgetary Control Budget Planning Cashiering and Student Accounts

UC Founder

Colleges of: Medicine Nursing and Health Pharmacy

Financial Reporting and Control Investments Management Payroll Administration Payroll and Employee Records Processing

Campus Planning and Construction Campus Security and Safety Campus Services Campus Mail Parking Services Printing Services Publications Subsidized Employee Work Programs Telephone Communications Transportation Services University Bookstores

Physical Plant Energy Systems Operations and Maintenance Purchasing and Material Management Contract Compliance Property Control U.C. Computer Center Academic and Admin. Computer Services Contract Services

Vice President for Business Affairs

Medical Center Administrative Units (including Medical Center Personnel) Medical Center Libraries University Hospital (General and Holmes Divisions)

Senior Vice President Director of Medical Center

Vice President for Finance and Treasurer

Appointing Officer Contracting Office Custodian of Records Internal Audit/ Management Services Legal Advisory Services Secretary of the Board

Senior Vice President for Administration

Vice President and Dean for Graduate Studies and Research

OMI College of Applied Science Raymond Walters University College Academic Affairs Continuing Education and Metropolitan Services Enrollment Policy and Educational Research Faculty Affairs Professional Practice Student Affairs University Libraries

Enrollment Advertising Publicity and Promotion

Vice President for Public Affairs

Colleges of: Arts and Sciences Business Clermont College College Conservatory of Music Community Services Design, Architecture, and Art Education and Home Economics Engineering Evening College Law

Senior Vice President and Provost

Athletics

Ombudsman

Development Liaison WGUC Radio

President

Alumni Affairs

Affirmative Action

Board of Trustees

5.1

PROJECTS IN A FUNCTIONAL ORGANIZATION

179

There are advantages and disadvantages of using a functional placement for a project, assuming that the organization is functionally organized. The major advantages are: 1. There is maximum flexibility in the use of staff. If the proper functional division has been chosen as the project’s home, the division will be the primary administrative base for individuals with technical expertise in the fields relevant to the project. Experts can be temporarily assigned to the project, make the required contributions, and immediately be reassigned to their normal work. 2. Individual experts can be utilized by many different projects. With the broad base of technical personnel available in the functional divisions, people can be switched back and forth between the different projects with relative ease. 3. Specialists in the division can be grouped to share knowledge and experience. Therefore, the project team has access to whatever technical knowledge resides in the functional group. This depth of knowledge is a potential source of creative, synergistic solutions to technical problems. 4. The functional division also serves as a base of technological continuity when individuals choose to leave the project, and even the parent firm. Perhaps just as important as technological continuity is the procedural, administrative, and overall policy continuity that results when the project is maintained in a specific functional division of the parent firm. 5. Finally, and not the least important, the functional division contains the normal path of advancement for individuals whose expertise is in the functional area. The project may be a source of glory for those who participate in its successful completion, but the functional field is their professional home and the focus of their professional growth and advancement. Just as there are advantages to using a functional placement, there are also disadvantages: 1. A primary disadvantage of this arrangement is that the client is not the focus of activity and concern. The functional unit has its own work to do, which usually takes precedence over the work of the project, and hence over the interests of the client. 2. The functional division tends to be oriented toward the activities particular to its function. It is not usually problem oriented in the sense that a project should be to be successful. 3. Occasionally in functionally organized projects, no individual is given full responsibility for the project. This failure to pinpoint responsibility usually means that the PM is made accountable for some parts of the project, but another person is made accountable for one or more other parts. Little imagination is required to forecast the lack of coordination and chaos that results. 4. The same reasons that lead to lack of coordinated effort tend to make response to client needs slow and arduous. There are often several layers of management between the project and the client. 5. There is a tendency to suboptimize the project. Project issues that are directly within the interest area of the functional home may be dealt with carefully, but those outside normal interest areas may be given short shrift, if not totally ignored. 6. The motivation of people assigned to the project tends to be weak. The project is not in the mainstream of activity and interest, and some project team members may view service on the project as a professional detour. 7. Such an organizational arrangement does not facilitate a holistic approach to the project. Complex technical projects such as the development of a jet transport aircraft or an emergency room in a hospital simply cannot be well designed unless they are designed as a totality. No matter how good the intentions, no functional division can avoid focusing on its unique areas of interest. Cross-divisional communication and sharing of knowledge is slow and difficult at best.

180

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

Project Management in Practice Reorganizing for Project Management at Prevost Car

At Prevost Car in Quebec City, Canada, the vicepresident of production was told that he would have to expand production capacity 31 percent in the next five months. In the past, such a task would start with a bulldozer the next day and the work would be under way, but no one knew at what cost, what timetable, or what value to the firm. Realizing that he needed some fresh ideas, a structured approach, and that there was no allowance for a mistake, the VP contacted a project management consulting firm to help him. The consulting firm set up a five-day meeting between their project managers, a value engineering expert, and the seven foremen from Prevost’s main factory to scope out the project. The group produced a report for senior management outlining a $10 million project to expand the main factory by 60,000 square feet, and a follow-on potential to make a further expansion of 20 percent more. The detail of the plan came as a revelation to top management who approved it after only two days of study. After it was completed on time and on budget, the firm also committed to the additional 20 percent expansion which also came in as planned.

5.2

The success of this project resulted in “infecting” Prevost Car with the project management “bug.” The next major task, an initiative to reduce workplace injuries, was thus organized as a project and was also highly successful. Soon, all types of activities were being handled as projects at Prevost. The use of project management in manufacturing firms is highly appropriate given their need to adapt quickly to ferocious international competition, accelerating technological change, and rapidly changing market conditions. In addition, Prevost has found that project management encourages productive cooperation between departments, fresh thinking and innovation, team approaches to problems, and the highly valued use of outside experts to bring in new ideas, thereby breaking current short-sighted habits and thinking. As Prevost’s VP states: “Right now it’s a question of finding what couldn’t be better managed by project.” Source: M. Gagne, “Prevost Car—The Power of Project Management,” PM Network,Vol. 11.

PROJECTS IN A PROJECTIZED ORGANIZATION At the other end of the organizational spectrum (in terms of project structure) is the projectized organization. Here the firm’s administrative support groups (HR, Legal, Finance, Controller, etc.) report to the President or CEO as staff units. The line units are the various standalone projects being undertaken in the organization. Each project has a full complement of the functions needed for its operation, though some members may serve on two or more projects. Each standalone project is a self-contained unit with its own technical team, its own staff, and so on. Some parent organizations prescribe administrative, financial, personnel, and control procedures in detail. Others allow the project almost total freedom within the limits of final accountability. There are examples of almost every possible intermediate position. Figure 5-2 illustrates the projectized organization and its standalone projects. As with the functional organization, standalone projects have unique advantages and disadvantages. The former are: 1. The project manager has full line authority over the project. Though the PM must report to a senior executive in the parent organization, there is a complete work force devoted to the project. The PM is like the CEO of a firm that is dedicated to carrying out the project.

5.2

PROJECTS IN A PROJECTIZED ORGANIZATION

181

President

Administrative Support

Project DcX

Project Beta

Project Red

Project Grow

Project Save

Team

Team

Team

Team

Team

Figure 5-2

The projectized organization.

2. All members of the project work force are directly responsible to the PM. There are no functional division heads whose permission must be sought or whose advice must be heeded before making technological decisions. The PM is truly the project director. 3. When the project is removed from the functional division, the lines of communication are shortened. The entire functional structure is bypassed, and the PM communicates directly with senior corporate management. The shortened communication lines result in faster communications with fewer communication failures. 4. When there are several successive projects of a similar kind, the projectized organization can maintain a more or less permanent cadre of experts who develop considerable skill in specific technologies. Indeed, the existence of such skill pools can attract customers to the parent firm. Lockheed’s famous “Skunk Works” was such a team of experts who took great pride in their ability to solve difficult engineering problems. The group’s name, taken from the Li’l Abner comic strip, reflects the group’s pride, irreverent attitude, and strong sense of identity. 5. The project team that has a strong and separate identity of its own tends to develop a high level of commitment from its members. Motivation is high and acts to foster the task orientation discussed in Chapter 3. 6. Because authority is centralized, the ability to make swift decisions is greatly enhanced. The entire project organization can react more rapidly to the requirements of the client and the needs of senior management. 7. Unity of command exists. While it is easy to overestimate the value of this particular organizational principle, there is little doubt that the quality of life for subordinates is enhanced when each subordinate has one, and only one, boss. 8. Projectized organizations are structurally simple and flexible, which makes them relatively easy to understand and to implement. 9. The organizational structure tends to support a holistic approach to the project. A brief explanation of the systems approach was given in Chapter 3, and an example of the problems arising when the systems approach is not used appears in Section 5.3 of this chapter. The dangers of focusing on and optimizing the project’s subsystems rather than the total project are often a major cause of technical failure in projects.

182

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

While the advantages of the projectized organization make a powerful argument favoring this structure, its disadvantages are also serious: 1. When the parent organization takes on several projects, it is common for each one to be fully staffed. This can lead to considerable duplication of effort in every area from clerical staff to the most sophisticated (and expensive) technological support units. If a project does not require a full-time personnel manager, for example, it must have one nonetheless because personnel managers come in integers, not fractions, and staff is usually not shared across projects. 2. In fact, the need to ensure access to technological knowledge and skills results in an attempt by the PM to stockpile equipment and technical assistance in order to be certain that it will be available when needed. Thus, people with critical technical skills may be hired by the project when they are available rather than when they are needed. Similarly, they tend to be maintained on the project longer than needed, “just in case.” Disadvantages 1 and 2 combine to make this way of organizing projects very expensive. 3. Removing the project from technical control by a functional department has its advantages, but it also has a serious disadvantage if the project is characterized as “high technology.” Though individuals engaged with projects develop considerable depth in the technology of the project, they tend to fall behind in other areas of their technical expertise. The functional division is a repository of technical lore, but it is not readily accessible to members of the standalone project team. 4. Projectized project teams seem to foster inconsistency in the way in which policies and procedures are carried out. In the relatively sheltered environment of the project, administrative corner-cutting is common and easily justified as a response to the client or to technical exigency. “They don’t understand our problems” becomes an easy excuse for ignoring dicta from headquarters. 5. In projectized organizations, the project takes on a life of its own. Team members form strong attachments to the project and to each other. A disease known as projectitis develops. A strong “we–they” divisiveness grows, distorting the relationships between project team members and their counterparts in the parent organization. Friendly rivalry may become bitter competition, and political infighting between projects is common. 6. Another symptom of projectitis is the worry about “life after the project ends.” Typically, there is considerable uncertainty about what will happen when the project is completed. Will team members be laid off? Will they be assigned to low-prestige work? Will their technical skills be too rusty to be successfully integrated into other projects? Will our team (“that old gang of mine”) be broken up?

5.3

PROJECTS IN A MATRIXED ORGANIZATION In an attempt to couple some of the advantages of the standalone project in the projectized organization with some of the desirable features of the functional project, and to avoid some of the disadvantages of each, the matrixed project organization was developed. In effect, the functional and the projectized organizations represent extremes. The matrixed project organization is a combination of the two. It is a standalone project organization overlaid on the functional divisions of the parent firm. Being a combination of standalone projectized and functional organization structures, a matrix organization can take on a wide variety of specific forms, depending on which of the two extremes (functional or standalone) it most resembles. The “projectized” or

5.3

PROJECTS IN A MATRIXED ORGANIZATION

183

“strong” matrix most resembles the projectized organization. The “functional” or “weak” matrix most resembles the functional form of organization. Finally, the “balanced” matrix lies in between the other two. In practice, there is an almost infinite variety of organizational forms between the extremes, and the primary difference between these forms has to do with the relative power/decision authority of the project manager and the functional manager. Because it is simpler to explain, let us first consider a strong matrix, one that is similar to a standalone project. Rather than being a standalone organization, like the standalone project, the matrix project is not separated from the parent organization. Consider Figure 5-3. Although not always the case, here the project manager of Project 1, PM1, reports to a program manager who also exercises supervision over two other projects having to do with the same program. Project 1 has assigned to it three people from the manufacturing division, one and one-half people from marketing, one-half of a person each from finance and personnel, four individuals from R & D, and perhaps others not shown. These individuals come from their respective functional divisions and are assigned to the project full-time or part-time, depending on the project’s needs. It should be emphasized that the PM controls when and what these people will do, while the functional managers control who will be assigned to the project and how the work will be done, including the technology used. With heavy representation from manufacturing and R&D, Project 1 might involve the design and installation of a new type of manufacturing process for a new product Alpha. Project 2 could involve marketing for the new product. Project 3 might concern the installation of a new financial control system for the new product. All the while, the functional divisions continue on with their routine activities. There is no single executive to whom PMs generally report. If a project is merely one of several in a specific program, the PM typically reports to a program manager, if there is one. It is not uncommon, however, for the PM to report to the manager of the functional area that has a particular interest in the project. If several projects on mathematics are being conducted for the Office of Naval Research (ONR), for instance, it would be normal for the PMs to report to the ONR section head for Mathematical Sciences. In smaller firms with only a few projects, it is common for the PM to report directly to a senior executive. At the other end of the spectrum of matrix organizations is the functional or weak matrix. A project might, for example, have only one full-time person, the PM. Rather than

President

Program manager

Manufacturing

Marketing

Finance

R&D

Personnel

PM1

3

1 1/2

1/2

4

1/2

PM2

1

4

1/4

1 1/2

1/4

PM3

1/2

3

1/2

1

Figure 5-3

The matrix organization.

184

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

having an individual functional worker actually assigned to the project, the functional departments devote capacity to the project, and the primary task of the PM is to coordinate the project activities carried out by the functional departments. For example, the PM of a project set up to create a new database for personnel might request that the basic design be done by the information technology (IT) group in the administrative division. The personnel job would then be added to the normal workload of the IT group. The priority given to the design might be assigned by senior management or might be the result of negotiations between the PM and the head of the IT group. In some cases, the IT group’s charges for the job might also be subject to negotiation. The task could even be subcontracted to an outside vendor. Between these extremes is the balanced matrix, which is typically anything but balanced. There are many different mixtures of project and functional responsibilities. When a functional group’s work is frequently required by projects, it is common to operate the group as a functional unit rather than to transfer its people to the project. For instance, a toxicology unit in a cosmetic business, a quality assurance group in a multiproduct manufacturing firm, or a computer graphics group in a publishing firm might all be functionally organized and take on project work much like outside contractors. While the PM’s control over the work is diminished by this arrangement, the project does have immediate access to any expertise in the group, and the group can maintain its technological integrity. We have previously discussed the difference between discipline-oriented individuals and those who are problem-oriented, indicating that the latter are highly desirable as members of project teams. Both de Laat (1994) and Kalu (1993) stand as adequate testimony to the fact that discipline-oriented team members tend to become ardent supporters of their functional areas, sometimes to the detriment of the project as a whole. The resultant power struggles may stress the project manager’s skills in conflict reduction. The matrixed project approach has its own unique advantages and disadvantages. Its strong points are: 1. The project is the point of emphasis. One individual, the PM, takes responsibility for managing the project, for bringing it in on time, within cost, and to specification. The matrix organization shares this virtue with the standalone project organization. 2. Because the project organization is overlaid on the functional divisions, temporarily drawing labor and talent from them, the project has reasonable access to the entire reservoir of technology in all functional divisions. When there are several projects, the talents of the functional divisions are available to all projects, thus sharply reducing the duplication required by the standalone project structure. 3. There is less anxiety about what happens when the project is completed than is typical of the standalone project organization. Even though team members tend to develop a strong attachment for the project, they also feel close to their functional “home.” 4. Response to client needs is as rapid as in the standalone project case, and the matrix organization is just as flexible. Similarly, the matrix organization responds flexibly and rapidly to the demands made by those inside the parent organization. A project nested within an operating firm must adapt to the needs of the parent firm or the project will not survive. 5. With matrix management, the project will have—or have access to—representatives from the administrative units of the parent firm. As a result, consistency with the policies, practices, and procedures of the parent firm tends to be preserved. If nothing else, this consistency with parent firm procedures tends to foster project credibility in the administration of the parent organization, a condition that is commonly undervalued.

5.3

PROJECTS IN A MATRIXED ORGANIZATION

185

6. Where there are several projects simultaneously under way, matrix organization allows a better companywide balance of resources to achieve the several different time/ cost/scope targets of the individual projects. This holistic approach to the total organization’s needs allows projects to be staffed and scheduled in order to optimize total system performance rather than to achieve the goals of one project at the expense of others. 7. While standalone projects and functionally organized projects represent extremes of the organizational spectrum, matrix organizations cover a wide range in between. We have differentiated between strong and weak matrices in terms of whether the functional units supplied individuals or capacity to projects. Obviously, some functional units might furnish people and others only supply capacity. There is, therefore, a great deal of flexibility in precisely how the project is organized—all within the basic matrix structure—so that it can be adapted to a wide variety of projects and is always subject to the needs, abilities, and desires of the parent organization. The advantages accruing to the matrix structure are potent, but the disadvantages are also serious. All of the following disadvantages involve conflict—between the functional and project managers for the most part. 1. In the case of functionally organized projects, there is no doubt that the functional division is the focus of decision-making power. In the standalone project case, it is clear that the PM is the power center of the project. With matrix organizations, the power is more balanced. Often, the balance is fairly delicate. When doubt exists about who is in charge, the work of the project suffers. If the project is successful and highly visible, doubt about who is in charge can foster political infighting for the credit and glory. If the project is a failure, political infighting will be even more brutal to avoid blame. 2. While the ability to balance time, cost, and scope between several projects is an advantage of matrix organizations, that ability has its dark side. The set of projects must be carefully monitored as a set, a tough job. Further, the movement of resources from project to project in order to satisfy the several schedules may foster political infighting among the several PMs, all of whom tend to be more interested in ensuring success for their individual projects than in helping the total system optimize organizationwide goals. 3. For strong matrices, problems associated with shutting down a project are almost as severe as those in standalone project organizations. The projects, having individual identities, resist death. Even in matrix organizations, projectitis is still a serious disease. 4. In matrix-organized projects, the PM controls administrative decisions and the functional heads control technological decisions. The distinction is simple enough when writing about project management, but for the operating PM the division of authority and responsibility inherent in matrix management is complex. The ability of the PM to negotiate anything from resources to technical assistance to delivery dates is a key contributor to project success. Success is doubtful for a PM without strong negotiating skills. 5. Matrix management violates the management principle of unity of command. Project workers have at least two bosses, their functional heads and the PM. There is no way around the split loyalties and confusion that result. Anyone who has worked under such an arrangement understands the difficulties. Those who have not done so cannot appreciate the discomforts it causes. To paraphrase Plato’s comment on democracy, matrix management “is a charming form of management, full of variety and disorder.”

186

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

Modern matrix management today strives to achieve many more goals than when it was adopted decades ago. For example, IBM is organized as a multi-dimensional matrix (Grant, 2008). There is a “business” organization (structured around hardware, software, and services), a “geographical” orientation (regions/countries), a “functional” home, “customer” groupings, “distribution channel” specialties, and “new business development” thrusts. If the old form of matrix management was confusing, the new form can be overwhelming. But modern organizations find that they have many more goals to achieve and must be multi-dexterous, achieving a more complex organizational integration but without hampering their flexibility, responsiveness, and performance. The solution many organizations have come up with has been to be more formal and controlling for the operational activities such as business and distribution channel goals (more centralized) while more informal (dotted-line relationships) for the functional, geographic, and customer activities, and even less formal, even voluntary or self-organizing, for knowledge management activities such as new business development.

Virtual Projects Virtual projects are those in which work on the project team crosses time, space, organizational, or cultural boundaries. Thus, a virtual team may work in different time zones, be geographically dispersed, work in different organizations, or work in different cultures. In all cases, the rise of virtual projects has been facilitated by the use of the Internet and other communication technologies. In many of these cases, the project team is often organized in some matrix-type of structure rather than a functional or standalone project form. Kalu (1993, p. 175) further defines virtual positions as “task processes, the performance of which requires composite membership” in both project and functional organizations. When complex organizations conduct projects, virtual positions are typical because projects usually require input from several functional departments. This creates overlapping and shared responsibility for the work with functional and project managers sharing responsibility for execution of the project. The reading “The Virtual Project: Managing Tomorrow’s Team Today” at the end of this chapter more narrowly specifies that virtual projects exist when project team members are geographically dispersed and gives some suggestions for successfully running such projects. Gratton (2007) also offers some rules for success when organizations find they must use geographically dispersed virtual teams for some of their projects.

• • • • • •

Only use virtual teams for projects that are challenging and interesting. But also be sure the project is meaningful to the company as well as the team. Solicit volunteers as much as possible—they’ll be more enthusiastic and dedicated to the success of the project. Include a few members in the team who already know each other, and make sure one in every six or seven are “boundary spanners” with lots of outside contacts. Create an online resource for team members to learn about each other (especially how they prefer to work), collaborate, brainstorm, and draw inspiration. Encourage frequent communication, but not social gatherings (which will occur at more natural times anyway). Divide the project work into geographically independent modules as much as possible so progress in one location isn’t hampered by delays in other locations.

5.3

PROJECTS IN A MATRIXED ORGANIZATION

187

Project Management in Practice Software Firm Yunio Avoids Complex Technologies

Chris Mathews, co-founder and CEO of China-based startup software maker Yunio, avoids cumbersome gadgetry and complex interfaces to manage his global project teams. He prefers techniques and technologies that seem natural and comfortable for the virtual teams. His focus is clear communication, regardless of the technology used. And when a message can be sent by example, he prefers that to other, less-effective forms of communication. For instance, when working with his Chinese teams he found that it wasn’t the norm for team members to let their colleagues know when they would be absent, or how to reach them. To set an example, he started e-mailing team members whenever he would be unable to attend a meeting. For individual teams or groups, he creates separate, distinct mailing lists. As his example was adopted by the teams, it became part of Yunio’s culture whereby new employees automatically adopted it too. Although Mathews uses e-mail for important matters where a written record is desirable, he finds

other technologies can be more appropriate for other uses. To keep communication as simple and seamless as possible, he only uses wiki for teams larger than 15 people because it’s a large investment requiring input from an online community of users to create content. Wikis become increasingly efficient, particularly for knowledge management, as the team grows. For less than 15 people, he prefers group chats but supplemented by chat logs. Instant messages don’t require instant responses so they allow team members to drop a quick note to someone without requiring a response. Since his workers use instant messaging anyway, it’s a natural communication tool for chats. Mathews believes that the use of tech products don’t define how to manage virtual teams but rather are just part of the toolkit; smart management is about picking the most appropriate tool to communicate clearly. Source: M. S. Zoninsein, “ Less is More,” PM Network, Vol. 24.

188

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

5.4

PROJECTS IN COMPOSITE ORGANIZATIONAL STRUCTURES The complexities of the real world rarely lead firms to organize their projects in any of the previous “pure” forms, so what we tend to see in practice is some combination of two or three or more different forms. In a functional organization, there may be project divisions along with marketing and finance, or in a matrix division there may be a staff project reporting to the CEO (or treasurer, or . . .), and so on. We call these “composite” structures. As an example, organization by territory is especially attractive to national organizations whose activities are physically or geographically spread, and where the products have some geographical uniqueness, such as ladies’ garments. So we may have projects such as spring fashion designs being run within each territory. But suppose each territory also sells to different kinds of customers, like retailers, wholesalers, and consumers; or perhaps civilians and military. Project organization within customer divisions is typically found when the projects reflect a paramount interest in the needs of different types of customers. Then we might also have matrixed projects that cross the various territories and focus on customer preferences, or projectized if it is a single project, such as installing a customer relationship management (CRM) software database for all the territories. If both functional and projectized divisions coexist in a firm, this would result in the composite form shown in Figure 5-4. This form is rarely observed for a long duration. What is done, instead, is to spin off the large, successful long-run projects as subsidiaries or independent operations. Many firms nurture young, unstable, smaller projects under the wing of an existing division, then wean them to standalone projects with their own identity, as in Figure 5-4, and finally allow the formation of a venture team—or, for a larger project, venture firm—within the parent company. For example, Texas Instruments did this with the Speak and Spell® toy that was developed by one of its employees, and 3M did this with their Post-It® Notes. The composite form leads to flexibility. It enables the firm to meet special problems by appropriate adaptation of its organizational structure. There are, however, distinct dangers involved in using the composite structure. Dissimilar groupings within the same accountability center tend to encourage overlap, duplication, and friction because of incompatibility of interests. Again, we have the conditions that tend to result in conflict between functional and project managers. Figure 5-5 illustrates another common solution to the problem of how to organize a project. The firm sets up what appears to be a standard form of functional organization, but it adds a staff office to administer all the projects. This frees the functional groups of administrative problems while it uses their technical talents. In a large specialty chemical firm, this organizational form worked so well that the staff office became the nucleus of a full-scale division of the firm whose sole purpose was to administer projects. Much has been written about the use of a “project management office” (PMO) which, as noted in earlier chapters

President

Project M

Figure 5-4

Finance

Engineering

Project Z

Manufacturing

A functional/projectized composite organization.

5.5

SELECTING A PROJECT FORM

189

President PMO

Finance

Manufacturing

Engineering

Figure 5-5 A functional/staff organization.

and shown in Figure 5-5, is an equivalent structure; more will be said about the PMO in Section 5.6. For single projects, this is basically the functional organization described earlier, but if used for multiple projects, and particularly if a PMO is used, this organization is similar to the matrix form. The main difference is that this form would typically be used for small, shortterm projects where the formation of a full-fledged matrix system is not justified. This mixed form shares several advantages and disadvantages of the matrix structure, but the project life is usually so short that the disease of projectitis is rarely contracted. If the number or size of the projects being staffed in this way grows, a shift to a formal matrix organization naturally evolves. Though the ways of interfacing project and parent organization are many and varied, most firms eventually adopt the matrix form as the basic method of housing their growing number of projects. To this base, occasional standalone, functional, and composite projects may be added if these possess special advantages; otherwise, they will be added to the matrix due to the relatively low cost of managing them and their enhanced ability to get access to broad technical support.

5.5

SELECTING A PROJECT FORM The choice of how to organize a project is not addressed to PMs or aspiring PMs. It is addressed to senior management. Very rarely does the PM have a choice about the way the project interfaces with the parent organization. Indeed, the PM is rarely asked for input to the interface choice. Even experienced practitioners find it difficult to explain how one should proceed when trying to choose. The choice is determined by the situation, but even so is partly intuitive. There are few accepted principles of design, and no step-by-step procedures that give detailed instructions for determining what kind of structure is needed and how it can be built. All we can do is consider the nature of the potential project, the characteristics of the various organizational options, the advantages and disadvantages of each, the cultural preferences of the parent organization, and make the best compromise we can. In general, the functional form is apt to be the organizational form of choice for projects where the major focus must be on the in-depth application of a technology rather than, for example, on minimizing cost, meeting a specific schedule, or achieving speedy response to

190

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

change. Also, the functional form is preferred for projects that will require large capital investments in equipment or buildings of a type normally used by the function. If the firm engages in a large number of similar projects (e.g., construction projects), the projectized form of organization is preferred. The same form would generally be used for one-time, highly specific, unique tasks that require careful control and are not appropriate for a single functional area—the development of a new product line, for instance. When the project requires the integration of inputs from several functional areas and involves reasonably sophisticated technology, but does not require all the technical specialists to work for the project on a full-time basis, the matrix organization is the only satisfactory solution. This is particularly true when several such projects must share technical experts. Another special case is when projects are created to change the way the parent organization is organized or communicates internally. Such projects typically require representation of all major parts of the parent to be successful. Matrix organizations are complex and present a difficult challenge for the PM, but are sometimes necessary. If choice of project structure exists, the first problem is to determine the kind of work that must be accomplished. To do this requires an initial, tentative project plan (a topic covered in detail in Section 6.1). First, identify the primary deliverable(s) of the project. Next, list the major tasks associated with each deliverable. For each task, determine the functional unit that will probably be responsible for carrying out the task. These are the elements that must be involved in order to carry out the project. The problem is how best to bring them together—or, how best to integrate their work. Additional matters to be considered are the individuals (or small groups) who will do the work, their personalities, the technology to be employed, the client(s) to be served, the political relationships of the functional units involved, and the culture of the parent organization. Environmental factors inside and outside the parent organization must also be taken into account. By understanding the various structures, their advantages and disadvantages, a firm can select the organizational structure that seems to offer the most effective and efficient choice. We illustrate the process with an example using the following procedure. 1. Define the project with a statement of the objective(s) that identifies the major outcomes desired. 2. Determine the key tasks associated with each objective and locate the units in the parent organization that serve as functional “homes” for these types of tasks. 3. Arrange the key tasks by sequence and decompose them into work packages. 4. Determine which organizational units are required to carry out the work packages and which units will work particularly closely with which others. 5. List any special characteristics or assumptions associated with the project—for example, level of technology needed, probable length and size of the project, any potential problems with the individuals who may be assigned to the work, possible political problems between different functions involved, and anything else that seems relevant, including the parent firm’s previous experiences with different ways of organizing projects. 6. In light of the above, and with full cognizance of the pros and cons associated with each structural form, choose a structure.

5.5

SELECTING A PROJECT FORM

191

Project Management in Practice Trinatronic, Inc.

Project objective: To design, build, and market a laptop computer that uses open standards where possible, and is capable of running all current engineering design and office productivity software packages. To satisfy security and confidentiality considerations, the computer should be able to maintain multiple versions of its operating information without needing to use offline storage.

A. B. C. D. E. F. G. H. I. J. K. L. M.

Key Tasks Write specifications. Design hardware, do initial tests. Engineer hardware for production. Set up production line. Manufacture small run, conduct quality and reliability tests. Write (or adopt) operating systems. Test operating systems. Write (or adopt) applications software. Test applications software. Prepare full documentation, repair and user manuals. Set up service system with manuals and spare parts Prepare marketing program. Prepare marketing demonstrations.

Without attempting to generate a specific sequence for these tasks, we note that they seem to belong to seven categories of work. 1. Develop and prioritize requirements. 2. Design, build, and test hardware.

3. Design, write, and test software. 4. Set up production and service/repair systems with spares and manuals. 5. Prepare and implement a make-or-buy analysis. 6. Develop release plan. 7. Design marketing effort, with demonstrations, brochures, and manuals.

In addition, the computer must be able to support video and audio conferencing capabilities, and must be compatible with European Common Market and U. S. “Green” standards for energy usage. The desired price point for this computer should be 10% below what we suspect competitors could offer.

Organizational Units Mktg. Div. and R & D R&D Eng. Dept., Mfg. Div. Eng. Dept., Mfg. Div. Mfg. Div. and Q.A. Dept., Exec. V.P. staff Software Prod. Div. Q.A. Dept., Exec. V.P. staff Software Prod. Div. Q.A. Dept., Exec. V.P. staff Tech. Writing Section (Eng. Div.) and Tech. Writing Section (Software Prod. Div.) Tech. Writing Section (Eng. Div.) and Tech. Mktg. Div. Mktg. Div.

Based on this analysis, it would appear that the project will need the following elements:

• •

Groups to design the hardware and software. Groups to test the hardware and write and test the software.

A group to engineer the production system for the hardware. A group to design the marketing program.

• • •

A group to prepare all appropriate documents and manuals. And, lest we forget, a group to administer all the above groups.

192

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

These subsystems represent at least three major divisions and perhaps a half-dozen departments in the parent organization. The groups designing the hardware and the multiple operating systems will have to work closely together. The test groups may work quite independently of the hardware and software designers, but results improve when they cooperate. Trinatronics has people capable of carrying out the project. The design of the hardware and operating systems is possible in the current state of the art, but to design such systems at a cost of 10% below potential competitors will require an advance in the state of the art. The project is estimated to take between 18 and 24 months, and to be the most expensive project yet undertaken by Trinatronics. Based on the sketchy information above, it seems clear that a functional project organization would

5.6

Source: S. J. Mantel, III. Consulting project.

THE PROJECT MANAGEMENT OFFICE (PMO)

PMBOK Guide 1.4.4

not be appropriate. Too much interaction between major divisions is required to make a single function into a comfortable organizational home for everyone. Either a standalone project or matrix structure is feasible, and given the choice, it seems sensible to choose the simpler standalone project organization if the cost of additional personnel is not too high. Note that if the project had required only parttime participation by the highly qualified scientific professionals, the matrix organization might have been preferable. Also, a matrix structure would probably have been chosen if this project were only one of several such projects drawing on a common staff base.

Thus far in this chapter it has been tacitly assumed that however the project has been organized, it has, or has access to, sufficient skill, knowledge, and resources to accomplish any activities that may be required. As we shall see, this assumption is not always true. A primary task of the PM is to acquire the resources, technical skills, knowledge, and whatever is needed by the project. While this may be difficult, acquisition of the project’s technical resources is mainly dependent on the PM’s skill in negotiation as described in Chapter 4. Even if the PM has all the resources needed, two problems remain. First, in the entire history of projects from the beginning of time until the day after tomorrow, no project has ever been completed precisely as it was planned. Uncertainty is a way of life for PMs and their projects. Second, the successful execution of a project is a complex managerial task and requires the use of planning, budgeting, scheduling, and control tools with which the neophyte PM may not be completely familiar. In addition, there are contractual, administrative, and reporting duties that must be performed in accord with the law, the wishes of the client, and the rules of the organizational home of the project. Dealing with uncertainties has come to be known as risk management. We introduced the subject in Chapter 2 when the uncertainties of project selection were discussed. To deal with uncertainty, the parent organization must create some mechanism to manage it, a topic treated in detail in Chapter 6. In order to deal with the managerial and administrative issues in a way that meets the parent organization’s rules for management and administration, many firms have created a project management office, or PMO. In a recent PMI (2011) survey, it was found that three out of five respondents’ organizations have PMOs. This section is devoted to the investigation of how project management and administration can be organized in order to perform with efficiency, effectiveness, and consistency. The PMO and its responsibilities are detailed in the introductory chapter of PMBOK®. With the increasing role of projects in today’s organizations and the move toward “management by projects,” the need has arisen for an organizational entity to help manage these fast-multiplying forms of getting work done. This is the role of the Project Management

5.6

THE PROJECT MANAGEMENT OFFICE (PMO)

193

Office (PMO), a.k.a. the Project Office, the Program Management Office, the Project Support Office, and so on. There are a variety of forms of PMOs to serve a variety of needs. Some of these are at a low level in the organization and others report to the highest levels. The best PMOs (Baker, 2007) have some common characteristics, however, including the traits of being run like the best businesses (a business plan, focused, emphasis on results), enjoying strong executive support, being future-oriented learning organizations, and offering the best project leadership in the organization.

Purposes of the Project Management Office Before discussing the purpose and services offered by PMOs, consider the following statistics reported by Block et al. (2001). When asked the reasons for initiating a PMO, almost two-thirds of the respondents indicated a need for establishing consistent project management standards and methods, and that the PMO was initiated by senior management direction. About half the respondents also indicated a need to eliminate project delays and correct poor project planning. A bit less than 40 percent wanted to improve project performance and eliminate cost overruns. Last, about a quarter of the respondents indicated they wished to reduce customer dissatisfaction. The 2011 PMI survey mentioned earlier found that having a PMO was a key practice in improving project performance, and their roles now commonly include portfolio management, program management, monitoring project success metrics, and managing project resource allocation. A major contribution of PMOs is to establish project administration procedures for selecting, initializing and planning, budgeting, and scheduling projects as well as to serve as a repository for reports on the performance of the planning, budgeting, scheduling, and resource allocation processes. PMO files also often contain reports on risk management, project audits, evaluations, and histories. As reflected by the reasons for initiating the PMOs in the first place, 78 percent of the respondents to Block et al. (2001) indicated that their PMO established and maintained standard project processes (practices and procedures), 64 percent offered consulting help on projects, and 58 percent offered training and mentoring services. About half performed project tracking and slightly fewer conducted portfolio management. Only 28 percent maintained a stable of project managers for future project needs.

Project Management in Practice A Project Management Office Success for the Transportation Security Administration

The Transportation Security Administration (TSA) had only 3 months and $20 million to build a 13,500 square foot coordination center, involving the coordination of up to 300 tradespeople working simultaneously on various aspects of the center. A strong Project Management Office (PMO) was crucial to making the effort a success. The PMO accelerated the procurement and approval process, cutting times in half in some cases. They engaged a team leader, a master scheduler, a master financial manager, a

procurement specialist, a civil engineer, and other specialists to manage the multiple facets of the construction project, finishing the entire project in 97 days and on budget, receiving an award from the National Assn. of Industrial and Office Properties for the quality of its project management and overall facility. Source: Project Management Institute. “PMO Speeds Success for Transportation Facility,” PM Network, Vol 18.

194

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

Although specific goals may be articulated for the PMO, the overarching purpose is often inherent in the process itself and is unarticulated, for example, ensuring that the firm’s portfolio of projects supports the organization’s overall goals and strategy, as described in Chapter 2. In this case, the PMO is the critical tie between strategic management and the project managers. Another overarching purpose may be the gradual assimilation of good project management practice into the entire organization, moving it from a functionally organized to a matrixed form, not only in structure but in culture as well. In such cases, the PMO is often renamed the Enterprise Project Management Office (EPMO), or given a similar name. In a recent study of PMOs following the financial crisis and Great Recession of 2008–9 (Gale 2010), it was found that more than half the PMOs now report to the highest levels of management and work on high-value strategic tasks such as managing the governance process (72% of those reporting), advising executives (64%), and participating in strategic planning (62%). In terms of payoffs, they reduced the number of failed projects by 31 percent, delivered 30 percent of projects under budget, and saved U.S. companies an average of $567,000 per project. PMOs show the greatest value when their project portfolio performance matches the strategic objectives of the organization. If they have no vision or mission and no measures of success, they risk getting labeled as administrative overhead and cut in tough times. In one case, a PMO was initiated when management wanted more insight into what was happening in their projects. The PMO reorganized projects to ensure they were all in sync with the firm’s goals, and had a clear business case that alligned with the organizational strategy. The PMO then not only tracked the projects but also issued monthly management reports with at-aglance information about every project. The reports also show how each completed project helps the firm meet its objectives. To provide management with forward looking information about potential issues that might jeopardize each project’s ability to deliver on its strategic goals, all projects maintain risk registers that are consolidated into a risk report at the end of each month. It is important to understand that the role of the PMO is that of an enabler/facilitator of projects, not the doer of projects. Top management cannot allow the EPMO or the PMO to usurp the technical aspects—scheduling, budgeting, etc.—of running the project. Those are the project manager’s responsibility. Although the PMO may, on occasion, become involved in some project management tasks, it should be for the purpose of facilitating liaison with top management, not to do the work of the project team.

Forms of Project Management Office Akin to the time phasing of PMO responsibilities just noted, there are various levels of competence, sophistication, and responsibility of PMOs. That is, some organizations may only want a limited PMO that represents an information center, reporting on project progress and assessing the organization’s project maturity. At the next level, the PMO may establish project management procedures and practices, promulgate lessons learned from prior projects, create a database for risk analysis, help project managers with administrative and managerial matters, and possibly even offer basic training in project management. At the upper level, the PMO may establish a resource database and monitor interproject dependencies, manage the project portfolio to ensure attainment of the organization’s goals, audit and prioritize individual projects, and generally establish an enterprise project management system. Another way of organizing the PMO has to do with the reporting level of the office. If top management wants to test the efficacy of a PMO at a lower level before approving it for the organization as a whole, they may place it in a functional department such as Information Technology or Engineering. In this role, the main responsibility of the PMO will be to help the department’s project managers with their individual projects. If the PMO is established at the business level, it may take on more responsibility for good project management practices and possibly offer basic training. At higher organizational levels, the PMO’s responsibilities will

5.6

THE PROJECT MANAGEMENT OFFICE (PMO)

195

broaden and become less tactical and more strategic. If the eventual goal is to improve the organization’s ability to execute projects, however, this is a risky way to implement a PMO! Simply because a PMO is not able to rescue a failing engineering project, for example, does not mean that it could not be extremely valuable to the organization by performing many of the preceding tasks. In recent years, several large organizations conducting scores or more (sometimes hundreds) of projects have created multiple PMOs, each overseeing and aiding projects in their individual unit of the organization. An EPMO is occasionally also created to oversee the multiple PMOs and ensure that they follow organizational standards for managing projects. While a PMO is typically only division-wide in a large organization, the EPMO is systemwide and responsible for policy making and organizational change. The 2011 PMI survey also found that EPMOs tend to focus on the strategic aspects of project management. In such cases, PMO contact with senior management is conducted through the EPMO, typically used to manage the project selection process as well as to communicate relevant organizational policy to the PMOs, direct risk management activities, establish processes for audits and reviews, and act as the organizational repository for project records.

Tasks of the Project Management Office To achieve its goals, PMOs and EPMOs commonly perform many of the following tasks (Block, 1999):

• • • • • • • • • • • • • • • •

Establish and enforce good project management processes such as procedures for bidding, risk analysis, project selection, progress reports, executing contracts, and selecting software Assess and improve the organization’s project management maturity Develop and improve an enterprise project management system Offer training in project management and help project managers become certified Identify, develop, and mentor project managers and maintain a stable of competent candidates Offer consulting services to the organization’s project managers Help project managers with administrative details such as status reports Establish a process for estimation and evaluation of risk Determine if a new project is a good “fit” for the changing organization Identify downstream changes (market, organization) and their impacts on current projects: Are the projects still relevant? Is there a need to change any project’s scope? Are there any cost effects on the projects? Review and manage the organization’s project risk portfolio, including limiting the number of active projects at any given time and identifying and reining in runaway projects as well as managing potential disasters Conduct project reviews and audits, particularly early in each project’s life cycle, and report project progress relative to the organization’s goals Maintain and store project archives Establish a project resource database and manage the resource pool Serve as a champion to pursue project management excellence in the organization and encourage discussion on the value of individual projects in the firm Serve as a “home” for project managers to communicate with each other and with PMO staff

196

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

• •

Collect and disseminate information, techniques, and lessons learned as reported in project evaluations that can improve project management practices Assist in project termination

Not all of these goals can be achieved at once. In the short term, or the first few months, the PMO will only be able to assess the organization’s current project management practices and perhaps evaluate the progress of each of the organization’s many projects. In the midterm, the PMO can start standardizing project management processes and procedures, begin helping individual projects with, for example, risk analysis and administrative details, and perhaps initiate a strategic portfolio analysis of the current projects. In the long term, or after about a year, the more comprehensive tasks may be undertaken, such as assembling a resource database, training project managers, conducting project audits, and consulting on individual projects. In our opinion, it would be rare for a PMO or EPMO to handle, or try to handle, all of the above matters. Rather, a great many control the Project Selection Process and manage a few other project related matters, e.g., maintaining project records and archives, handling risk management, and/or training new project managers. An experienced consultant told us: Lately, in my travels, in most companies I come across it is the PMO’s major role to create and facilitate the methodology of the project selection process in order to support upper-management’s decision making. The PMO evaluates all proposed initiatives against the company’s goals, estimates costs, and proves the business’s proposed ROI if the initiative is funded. Once a project is selected, the PMO shifts its effort to determining if the project is meeting all of its objectives. Many PMOs do little or no direct project management support of projects as they are being carried out, but PMOs do conduct several major evaluations of all projects in a portfolio, both during the projects’ life cycles and after the fact, to see if they achieve what they said they would during the selection process.

Implementing the Project Management Office As was noted previously, the best way to implement a PMO is to treat it as a project and apply good project management procedures. In addition, given the role of this special type of project, it is also suggested that the effort not be initiated until it has the full commitment of the top managers of the organization. It should also have a senior management sponsor/champion who is determined to see this project through to success. One way to initiate the project is through a pilot program in one of the areas that falls under the responsibility of the PMO project champion. Following its completion, the pilot project can be assessed, any mistakes corrected, and the benefits publicized to the rest of the organization. As the PMO expands and interacts with more and more projects, its benefits to the organization will increase progressively with its reach. Liu et al. (2007) have shown that PMOs have a significantly positive impact on projects operating with high task uncertainty. (The positive impact of PMOs decreases as task uncertainty diminishes.) Unfortunately, not all PMOs are successful. According to Tennant (2001), one of the primary problems of PMOs is that the executives who establish PMOs often do not understand project management practices themselves. Thus, they have unrealistic expectations of the PMO, such as providing temporary help for a project in trouble, or to obtain cost reductions from on-going projects. The PMO is not a quick fix for saving projects that are failing; its primary objective is to improve project management processes over the long run. PMOs cannot be expected to correct upper management failures such as inappropriate project goals, insufficient project support, and inadequate resource availability. Interestingly,

5.7

THE PROJECT TEAM

197

a recent trend in project organizations is the outsourcing of the PMO functions themselves. One has to wonder if this is a sign of impending trouble or a wise recognition of the limitations of upper management knowledge.

5.7

THE PROJECT TEAM “Teamwork is a lot of people doing what I say.” Anonymous Boss

PMBOK Guide 9.2–9.4

In this section we consider the makeup of the project team, bearing in mind that different projects have vastly different staffing needs. The role of the project team takes up most of Chapter 9 in PMBOK®. Then we take up some problems associated with staffing the team. Last, we deal with a few of the behavioral issues in managing this team. To be concrete during our discussion of project teams, let us use the example of a software engineering project to determine how to form a project team. Assume that the size of our hypothetical project is fairly large. In addition to the PM, the following key team members might be needed, plus an appropriate number of systems architects, engineers, testers, clerks, and the like. This example can be applied to a construction project, a medical research project, or any of a wide variety of other types of projects. The titles of the individuals would change, but the roles played would be similar.

• • • •

• •

Systems Architect The systems architect is in charge of the basic product design and development and is responsible for functional analysis, specifications, drawings, cost estimates, and documentation. Development Engineer This engineer’s task is the efficient production of the product or process the project engineer has designed, including responsibility for manufacturing engineering, design and production of code, unit testing, production scheduling, and other production tasks. Test Engineer This person is responsible for the installation, testing, and support of the product (process) once its engineering is complete. Contract Administrator The administrator is in charge of all official paperwork, keeping track of standards compliance (including quality/reliability), customer (engineering) changes, billings, questions, complaints, legal aspects, costs, and negotiation of other matters related to the contract authorizing the project. Not uncommonly, the contract administrator also serves as project historian and archivist. Project Controller The controller keeps daily account of budgets, cost variances, labor charges, project supplies, capital equipment status, etc. The controller also makes regular reports and keeps in close touch with both the PM and the company controller. If the administrator does not serve as historian, the controller can do so. Support Services Manager This person is in charge of product support, subcontractors, data processing, purchasing, contract negotiation, and general management support functions.

Of these top project people, it is most important that the systems architect and the project controller report directly to the PM (see Figure 5-6). This facilitates control over two of the main goals of the project: technical performance and budget. (The project manager is usually

198

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

Project manager

Systems architect

Project controller

Development engineer

Contract administrator

Test engineer

Support services manager

Figure 5-6 Typical organization for software projects.

in personal control of the schedule.) For a large project, all six project officials could work out of the project office and report directly to the PM. To staff the project, the PM works from a forecast of personnel needs over the life cycle of the project. This is done with the aid of some special charts. First, a work breakdown structure (WBS) is prepared to determine the exact nature of the tasks required to complete the project. (The WBS is described in detail and illustrated in Chapter 6.) The skill requirements for these tasks are assessed and like skills are aggregated to determine work force needs. Be warned that development of the WBS may involve consultations with external experts. The PM needs to understand, plan for, and closely monitor the effects on current projects of these consultations. It is common for these experts to be pulled away from their own work in order to deal with planning needs arising elsewhere in a WBS. From this base, the functional departments are contacted to locate individuals who can meet these needs. On occasion, certain tasks may be subcontracted. This option may be adopted because the appropriately skilled personnel are unavailable or cannot be located, or subcontractors can deliver for lower cost, or even because some special equipment required for the project is not available in-house. The need to subcontract is growing as firms “downsize.” If the proper people (and equipment) are found within the organization, however, the PM usually must obtain their services from their home departments. Many firms insist on using “local” resources when they are available, in order to maintain better control over resource usage and quality. Typically, the PM will have to negotiate with both the functional department head and the employee, trying to “sell” the employee on the challenge and excitement of working on the project and trying to convince the department head that lending the employee to the project is in the department head’s best interest. There are some other people, not necessarily technical, who are also critical to the project’s success and should report directly to the PM or to the PM’s deputy (often the systems architect):

• • •

Senior project team members who will be having a long-term relationship with the project Those with whom the PM will require continuous or close communication Those with rare skills necessary to project success.

Remember that the PM must depend on reason when trying to convince a department head to lend their valuable people to the project. The functional department head, who sees the project as a more or less glamorous source of prestige in which the department cannot

5.7

THE PROJECT TEAM

199

share, has little natural motivation to be cooperative. Once again, project success depends on the political and negotiating skill of the PM as much as on the technical skill of the team. Thus far, we have tacitly assumed a fairly strong matrix or projectized organization for the project in our example. In recent years, the use of weaker matrices has become more and more frequent. In many firms, when project managers are asked for the number of people who report directly to them, the answer “None!” is not uncommon. Most common of all, it seems to us, is the matrix organization with a project manager, one or two key skilled contributors who may be full-time members of the project, and a wide variety of services or capacity supplied to the project by functional groups in the parent organization. Such structures are often found in R&D projects that are part of larger programs being carried out by a parent firm. In a pharmaceutical project, for example, one or two senior scientists and laboratory technicians may be assigned to the project, but the work involved in toxicity testing, efficacy testing, and writing the product insert is supplied to the project in the form of deliverables from functional units rather than people assigned directly to the project to carry out the work. Although the project manager has to bargain for fewer individuals in these weaker matrix structures than in the case of stronger matrices, the PM’s negotiating skills are just as critical. It is typical for the success of weak-matrix projects to be dependent on the skills of the few technical specialists who are assigned directly to the project. The ability of the PM to negotiate for skilled technicians as well as for the timely delivery of services from functional departments is a key determinant of success.

Project Management in Practice The Empire Uses Floating Multidisciplinary Teams

200

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

Lucasfilm Ltd., the creators of Star Wars, needs quickmoving, flexible, multidisciplinary teams of insiders and freelance outsiders to execute short-lived, rapidly forming and dissolving projects. Standard project management approaches are too slow for this kind of environment. They need the ability to quickly assemble teams to execute specific functions and then reassemble to fit the next set of tasks. To do this, Lucasfilm moved all their disparate units into a $350 million single-roofed complex so they can all interact as

5.8

Source: B. Hindo, “The Empire Strikes at Silos,” Business Week 2007.

HUMAN FACTORS AND THE PROJECT TEAM

PMBOK Guide Chapter 9

the tasks of the moment require. Managers are rootless, sweeping through office suites scattered throughout the building, depending on the talents needed for the next project. As the relentless pressure of meeting higher performance levels with tighter schedules and budgets increases for projects, this model may be the future for project management organization and leadership.

With a reminder of the need for the PM to possess a high level of political sensitivity, we can discuss some other factors in managing project teams, all the while remembering that the principles and practices of good, general management also apply to the management of projects. We discuss them from the viewpoint of the PM as an individual who must cope with the personal as well as the technical victories and frustrations of life on a project. The issues of managing the project team are mainly included in the Human Resource Management knowledge area of PMBOK®. Meeting schedule and cost goals without compromising performance appears to be a technical problem for the PM. Actually, it is only partly technical because it is also a human problem—more accurately, a technical problem with a human dimension. Project professionals tend to be perfectionists. It is difficult enough to meet project goals under normal conditions, but when, out of pride of workmanship, the professionals want to keep improving (and thus changing) the product, the task becomes almost impossible. Changes cause delays. Throughout the project, the manager must continue to stress the importance of meeting due dates. It also helps if the PM establishes, at the beginning of the project, a technical change procedure to ensure control over the incidence and frequency of change. (It would not, however, be wise for the PM to assume that everyone will automatically follow such a procedure.) Another problem is motivating project team members to accomplish the work of the project. Unfortunately, the PM often has little control over the economic rewards and promotions of the people working on the project. This is especially true when the matrix is weak. This does not, however, mean that the PM cannot motivate members of the project team. Frederick Herzberg, who studied what motivates technical employees such as engineers, scientists, and professionals on a project team, contends that recognition, achievement, the work itself, responsibility, advancement, and the chance to learn new skills are strong motivators (see Herzberg, 1968). It is the PM’s responsibility to make sure that project work is structured in such a way as to emphasize these motivational factors. We have also found that the judicious use of “thank you” notes from the PM to those functional managers who have supplied the project with capable and committed individuals and/or effective and efficient capacity is a potent motivator—copies to the relevant individuals and to the functional manager’s boss, of course. (It is also important not to write such notes if the performance was mediocre or poor.) The use of participative management is also a way of motivating people. This is not a new theory. The concept suggests that the individual worker (or team) should play a significant role in deciding what means should be employed in meeting desired ends, and in finding better ways of accomplishing things. Recent participative programs such as Six

5.8

HUMAN FACTORS AND THE PROJECT TEAM

201

Sigma, Total Quality Management (TQM), continuous improvement teams (CIT), selfdirected work teams (SDWT), and more recently, agile project management teams may have slightly different structures and vary somewhat in the amount of decision-making authority and autonomy exercised by the team, but they are all aimed at improving worker performance as well as improving production methods and product quality. We will discuss agile project management further in Chapter 6. The adoption of such methods empowers the team (as well as its individual members) to take responsibility and to be accountable for delivering project objectives. Some advantages of empowerment for project teams are: 1. It harnesses the ability of the team members to manipulate tasks so that project objectives are met. The team is encouraged to find better ways to do things. 2. Professionals do not like being micromanaged. Participative management does not tell them how to work but, given a goal, allows them to design their own methods (usually within some constraints on their authority). 3. The team members know they are responsible and accountable for achieving the project deliverables. 4. There is a good chance that synergistic solutions will result from team interaction. 5. Team members get timely feedback on their performance. 6. The PM is provided a tool for evaluating the team’s performance. All of these items serve to increase motivation among members of the project team. Informal discussions with many project team leaders lead us to the same conclusions, but the success of SDWTs (and all other teams) is ultimately dependent on a clear statement of what the team is expected to accomplish. Senior management must “make the effort to clearly delineate project goals, responsibilities, and authority” in order to reap the advantages of project teams (Ford et al., 1992, p. 316; Nelson, 1998, p. 43). Finally, it is important to remember that giving a project to a team does not supersede the need for competent project management skills. In Chapter 6, we cover the process of planning projects in detail, and we emphasize the use of the work breakdown structure (WBS) to organize the activities of the project. It is a detailed planning and scheduling technique directed toward achievement of the objectives of the project. The PM (and sometimes the client) works with members of the project team and a comprehensive set of written plans is generated by this process. The resulting document is not only a plan, but also a control mechanism. Because the system of developing the plan is participative and makes team members accountable for their specific parts of the overall plan, it motivates them, and also clearly denotes the degree to which team members are mutually dependent. The importance of this latter outcome of the planning process is not well recognized in the literature on team building. However, bringing people together, even when they belong to the same organization and contribute their efforts to the same objectives, does not necessarily mean that they will behave like a team. Organizing the team’s work in such a way that team members are mutually dependent, and recognize it, will produce a strong impetus for the group to form a real team. Project success will be associated with teamwork, and project failure will surely result if the group does not work as a team.* If many or most of the team members are

*Though team formation is not even mentioned, a reading of A. S. Carlisle’s (1976) article, “MacGregor,” is instructive. The article is a classic on the power of delegation and was clearly the inspiration for Blanchard and Johnson’s The One Minute Manager. The Carlisle paper reports on a plant manager who delegates most operating decisions to his subordinates and insists that they help in solving one another’s problems. As a result, they form a team that would be the envy of any project manager.

202

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.

also “problem oriented,” the likelihood of the group forming an effective team is further increased. In an extensive research study on the matter, Tippet et al. (1995) conclude that overall results show that companies are generally doing a poor job of team building. Lack of effective rewards, inadequate individual and team performance feedback mechanisms, and inadequate individual and team goal-setting are all weak areas (Tippet, 1995, p. 35). Finally, Lencioni (2002) has written a wonderful little book on team building that he describes as “a leadership fable.” If one can read only one work on teams, this would be our first choice. The use of matrix project organizations raises an additional problem. Team members come and go. The constant turnover of team members makes it difficult to build and maintain a team (Bushe, 2010). When a new member of the team arrives, he or she must be brought up to date on the project. Almost always, this job is left to experienced team members, who are often beset with the pressure of their own work and resent the interruption. Some things can be done to help, if not totally solve the problem. The PM should identify some team members who are personally outgoing and knowledgeable. These individuals can be asked to meet with new members and help them engage the technical aspects of the project. The PM must, of course, make sure that this additional work can be accommodated in the schedules of the old hands. Interpersonal contact is often made easier for all parties through the use of software (Underwood, 2008). Also, increased specialization can reduce the amount of information that must be passed along, and can result in an emphasis on the fact that all team members are dependent on other team members for success. A sense of mutual dependency will also tend to raise the level of cohesiveness and commitment to all members of the project. Another behavioral problem for the PM is interpersonal conflict. The problem is so pervasive that conflict between project team members, and between team members and outsiders (including the client) seems to be the natural state of existence for projects. It is our strong feeling that the PM who cannot manage conflict is doomed to failure. Negotiation, as we have indicated before, is the PM’s primary tool for resolving conflict, but we caution the reader once again that conflict can also be a highly creative force in a project team, particularly when it is controlled by an astute PM. In 1975, Thamhain et al. (1975) published the definitive work on the focus and nature of conflict in projects. We have found their insights just as relevant today as they were in 1975. Table 5-1, based on Thamhain et al., relates the most likely focus of conflict to specific stages of the project life cycle. The table also suggests some solutions. When the project is first organized, priorities, procedures, and schedules all have roughly equal potential as a focus of conflict. During the buildup phase, priorities become significantly more important than any other conflict factor; procedures are almost entirely established by this time. In the main program phase, priorities are finally established and schedules are the most important cause of trouble within the project, followed by technical disagreements.

5.8

HUMAN FACTORS AND THE PROJECT TEAM

203

Getting adequate support for the project is also a point of concern. At project finish, meeting the schedule is the critical issue, but interpersonal tensions that were easily ignored early in the project can suddenly erupt into conflict during the last hectic weeks of the life cycle. Worry about reassignment exacerbates the situation. Both Tables 5-1 and 5-2 show conflict as a function of stage in the project life cycle as well as by source of the conflict, but Table 5-2 also shows the frequency of conflict by source and stage of the life cycle. It seems clear to us that most of the conflict on project teams is the result of individuals focusing on the project through the eyes of their individual discipline or department (de Laat, 1994; Hughes, 1998). Such people are not problem oriented and thus are rarely effective members of project teams. Dewhurst (1998, p. 34) defines a group of individuals working independently as a “Name-Only-Team” or a “NOT.” If teamwork

Table 5-1

Major Sources of Conflict during Various Stages of the Project Life Cycle Major Conflict Source and Recommendations firr Minimizing Dysfunctional Consequences

Life Cycle Phase

Conflict Source

Project formation

Priorities Procedures

Schedules Buildup phase

Priorities Schedules

Main program

Procedures Schedules

Technical

Labor Phaseout

Schedules

Personality and labor Source: Thamhain et al., 1975.

Recommendations Clearly defined plans. Joint dceision making and/or consultation with affected parties. Stress importance of project to organization goals. Develop detailed administrative operating procedures to be followed in conduct of project. Secure approval from key administrators. Develop statement of understanding or charter. Develop schedule commitments in advance of actual project commencement. Forecast other departmental priorities and possible impact on project. Provide effective feedback to support areas on forecasted project plans and needs via status review sessions. Schedule work breakdo w n pae kages (proj ee t su buni ts) i n c oopera tio n w i t h functional groups. Contingency planning on key administrative issues. Continually monitor work in progress. Communicate results to affected parties. Forecast problems and consider alternatives. Identify potential trouble spots needing closer surveillance. Early resolution of technical problems. Communication of schedule and budget restraints to technical personnel. Emphasize adequate, early technical testing. Facilitate early agreement on final designs. Forecast and communicate staffing requirements early. Establish staffing requirements and priorities with functional and staff groups. Close schedule monitoring in project life cycle. Consider reallocation of available staff to critical project areas prone to schedule slippages. Attain prompt resolution of technical issues that may affect schedules. Develop plans for reallocation of people upon project completion. Maintain harmonious working relationships with project team and support groups. Try to loosen up high-stress environment.

204

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

Table 5-2

Number of Conflicts during a Sample Project

is vital to success, then for a NOT, the “work group math (is) 2 2 3 or less.” The infighting that results when discipline-oriented individuals introduce conflict to a project team is perceived by most team members to be “political.” If the PM allows project decisions to be dictated by the infighting, the project is apt to fail (de Laat, 1994; Pinto, 1997, p. 31). Conflict can be handled in several ways, but one thing is certain: Conflict avoiders do not make successful project managers. On occasion, compromise appears to be helpful, but most often, gently confronting the conflict is the method of choice. Much has been written about conflict resolution and there is no need to summarize that literature here beyond noting that the key to conflict resolution rests on the manager’s ability to transform a win-lose situation into win-win.

Project Management in Practice South African Repair Success through Teamwork

When a fire broke out in the carbonate regeneration column in a major facility of Sasol, a leading South African coal, chemical, and crude-oil company, it was crucial to get it fixed immediately. It was determined that the damaged portion of the 19-foot-wide, 231-foot-long column would have to be cut out and replaced before the facility could operate again. Time was of the essence, and only 40 days were allowed for the repair project. To achieve this unheard-of schedule, a number of special ground rules were established:

• • •

The project is to be schedule-driven, not cost-driven There is no float anywhere on the project Always plan to reduce scheduled times, not meet them

• • • •

Resources are not to be considered as a limitation Communication will be continuous across all levels Safety will not be compromised Quality will not be compromised

In addition, special effort was directed toward making the project team strive to reduce time on the project. First, it was made clear that a higher premium would be placed on team performance than on individual performance. The “soft” aspects of management were always taken into consideration: making sure transport was available, accommodations were acceptable, food was available, excessive overtime was avoided, communication forms matched

SUMMARY

205

each member’s preferences (verbal, phone, written, etc.), and so on. A communication board was installed and updated twice daily to communicate project progress, and especially time saved on the schedule with the person’s name who achieved it. There were both twice-daily shift change meetings, where each shift communicated with the previous shift about progress and problems, and twice-daily planning meetings where the work activities of the next two days were planned in minute detail. The response to this level of project team attention was overwhelming. People raised ideas for saving even five minutes on the schedule. Enthusiasm for the project, and saving project time, became the dominant culture. As a result, the project was completed in only 25 days, 15 days early, with a corresponding cost savings of over $21 million out of an $85 million budget. Source: I. Boggon, “The Benfield Column Repair Project,” PM Network, Vol. 10.

SUMMARY This chapter described the various organizational structures that can be used for projects, and detailed their advantages. An appropriate procedure for choosing the best form was described and two examples were given. The chapter then moved into a discussion of the role of the Project Management Office. Following this, discussion turned to the project team itself, describing the organization of the project office staff and the human issues, such as motivation and conflict, the project manager will face. Specific points made in the chapter were these: If the projectized is to be included in a functional organization, it should be placed in that unit with the greatest interest in its success or the unit that can provide the most help. Though there are advantages in this mode of organizing, the disadvantages are greater. The projectized form of organizing has its advantages and disadvantages. Though the disadvantages are not as severe as with the functional form, they are nevertheless significant. The matrix organization combines the functional and projectized forms in an attempt to reap the advantages of each. While this approach has been fairly successful, it also has its own unique disadvantages. There are many variants of the pure forms of organization, and various staff and “mixed” structures are commonly used to handle special projects. The best form for a particular case requires consideration

of the characteristics of the project compared with the various advantages and disadvantages of each form. A useful procedure for selecting an organizational form for a project is: 1. Identify the specific outcomes desired. 2. Determine the key tasks to attain these outcomes and identify the units within the parent organization where these tasks would normally be assigned. 3. Sequence the key tasks and group them into logical work steps. 4. Determine which project subsystems will be assigned which steps, and which subsystems must closely cooperate. 5. Identify any special firm or project characteristics, constraints, or problems that may affect how the project should be organized. 6. Consider all the above relative to the pros and cons of each organizational form as a final decision is made. Every project should have a project office, even if it must be shared with another project. Larger, more complex projects may include, in addition to the PM, a project engineer, manufacturing engineer,

206

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

field manager, contract administrator, project controller, and support service manager. If an organization engages in multiple projects, a Project Management Office (or EPMO) may also be warranted. Those on the project team who should report directly to the PM are the project engineer and project controller as well as: 1. Senior team members who will have a long-term relationship with the project. 2. Those with whom the PM will be continuously or closely communicating. 3. Those with rare skills needed for project success.

Perfectionism, motivation, and conflict are often the major behavioral problems facing the PM. Participative management programs can be a useful tool for addressing the first two, while gentle confrontation usually works best for the latter. Sources of project conflict are often priorities and policies at first, schedule and technical problems during the main phase, and schedule and personal issues near termination. In the next chapter, we move from organizational issues to project planning tasks. We address the topics of coordination, interface management, and risk management. We also present some major project management concepts and tools such as the work breakdown structure and RACI chart.

GLOSSARY Concurrent/Simultaneous Engineering Originally, the use of a design team that included both design and manufacturing engineers, now expanded to include staff from quality control, purchasing, and other relevant areas. Functional Management The standard departments of the organization that represent individual disciplines such as engineering, marketing, purchasing, and so on. Holistic The whole viewed at one time rather than each piece individually. Matrix Organization A method of organizing that maintains both functional supervisors as well as project supervisors. A strong matrix operates closer to a projectized organization while a weak matrix operates more like a functional organization. Mixed Organization This approach includes both functions (disciplines) and projects in its hierarchy. Parent Organization The firm or organization within which the project is being conducted. Program Manager This person is typically responsible for a number of related projects, each with its own project manager.

Projectized Organization This form of organizing is characterized by projects being the main subdivisions of the organization, and general administrative functions common to all projects being a staff office reporting to the President or CEO. Project Management Office An office to deal with multiple projects and charged with improving the project management maturity and expertise of the organization, as well as increasing the success rate of projects. Projectitis A social phenomenon, inappropriately intense attachment to the project. Subcontract Subletting tasks out to smaller contractors. Suboptimization The optimization of a subelement of a system, perhaps to the detriment of the overall system. War Room A project office where the latest detail on project progress is available. It may also be a source of technical assistance in managing the project. Work Breakdown Structure A basic project document that describes all the work that must be done to complete the project and forms the basis for costing, scheduling, and work responsibility (see Chapter 6).

QUESTIONS Material Review Questions

1. What is a program manager? How does this job differ from that of a project manager? 2. Identify the advantages and disadvantages of the matrix form of organization. 3. Name the four basic types of project organization and list at least one characteristic, advantage, and disadvantage of each.

4. Give some major guidelines for choosing an organizational form for a project. 5. Why is the project management office so important? 6. Identify three ways of dealing with a conflict associated with projects. 7. What are some advantages and disadvantages of housing a project in a functional form?

QUESTIONS

8. What are the systems architect’s duties? 9. What are the major sources of conflict throughout the life cycle?

207

10. What are the major tasks of a Project Management Office?

Class Discussion Questions

11. Discuss some of the differences between managing professionals and managing other workers or team members. 12. Human and political factors loom large in the success of projects. Given the general lack of coverage of this subject in engineering and science education, how might a PM gain the ability to deal with these issues? 13. A disadvantage of the projectized organization has to do with the tendency of project professionals to fall behind in areas of technical expertise not used on the project. Name several ways that a project manager might avoid this problem. 14. Discuss the effects of the various organizational forms on coordination and interaction, both within the project team and between the team and the rest of the firm. 15. Describe, from Table 5-2, the probable reasons for the changing number of conflicts over the course of the project in the following areas: (a) Priorities (b) Administrative procedures (c) Technical trade-offs (d) Schedules 16. How would you organize a project to develop a complex new product such as a new color fax–copy– scanner–printer machine? How would you organize if the product was simpler, such as a new disk drive? 17. What do you think may be the purpose of a work breakdown structure? How might it aid the PM in organizing the project? 18. Why do you think the average total conflict increases during the “early program phase” (Figure 5-7)? 19. What should be the role of the project manager in conflict management? 20. Is it ethical to employ participative management solely as a way to motivate employees? 21. What are the pros and cons of the head of a Project Management Office reporting to senior management? To departmental management? 22. Merck & Co., manufacturers of Vioxx, took a major financial hit when they decided to discontinue manufacture and sale of the drug. What do you think were the major items in their likely cost/benefit analysis? Reorganizing for Project Management at Prevost Car

23. Surely this was not the first time Prevost needed to make a significant change in their firm. Why do you

think this was the first time the VP called upon a project management consulting firm? 24. Do you expect there was some concern among top management that no bulldozer was working the next day? 25. This example well illustrates the trend to using project management to do everything in organizations that used to be done in other ways. Can everything be better executed using project management? If not, what are the characteristics of those tasks that cannot? South African Repair Success through Teamwork

26. Of the special ground rules, which ones do you think really gave impetus to the speed of the project? 27. What do you think was the primary factor that changed the culture for this project? 28. Given that this project cut about 40 percent off the schedule and 25 percent off the cost, what is the message about the importance of teamwork? A Project Management Office Success for the Transportation Security Administration

29. What is surprising about the success of this non-profit agency? 30. Is the role of the PMO in this case unusual? The Empire Uses Floating Multidisciplinary Teams

31. Do you think this might be the future of project management? 32. Would this approach work for most of today’s projects? Trinatronic, Inc.

33. Consider the applicability of a “lightweight” team structure for this project. 34. Consider the applicability of a “heavyweight” or “balanced” structure. Software Firm Yunio Avoids Complex Technologies

35. Does managing virtual teams require more attention to communication technology? 36. Would communicating by example work for nonvirtual project managers? 37. What are the trade-offs project managers should consider when trying to select the most effective communication medium?

208

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

INCIDENTS FOR DISCUSSION Shaw’s Strategy

Hydrobuck

Colin Shaw has been tapped to be an accounting project manager for the second time this year. Although he enjoys the challenges and opportunity for personal development afforded to him as a project manager, he dreads the interpersonal problems associated with the position. Sometimes he feels like a glorified baby-sitter handing out assignments, checking on progress, and making sure everyone is doing his or her fair share. Recently Colin read an article that recommended a very different approach for the project manager in supervising and controlling team members. Colin thought this was a useful idea and decided to try it on his next project. The project in question involved making a decision on whether to implement an activity-based costing (ABC) system throughout the organization. Colin had once been the manager in charge of implementing a process costing system in this same division, so he felt very comfortable about his ability to lead the team and resolve this question. He defined the objective of the project and detailed all the major tasks involved, as well as most of the subtasks. By the time the first meeting of the project team took place, Colin felt more secure about the control and direction of the project than he had at the beginning of any of his previous projects. He had specifically defined objectives and tasks for each team member and had assigned completion dates for each task. He had even made up individual “contracts” for each team member to sign as an indication of their commitment to completion of the assigned tasks per schedule dates. The meeting went very smoothly, with almost no comments from team members. Everyone picked up a copy of his or her “contract” and went off to work on the project. Colin was ecstatic about the success of this new approach.

Hydrobuck is a medium-sized producer of gasoline-powered outboard motors. In the past it has successfully manufactured and marketed motors in the 3- to 40-horsepower range. Executives at Hydrobuck are now interested in larger motors and would eventually like to produce motors in the 50- to 150-horsepower range. The internal workings of the large motors are quite similar to those of the smaller motors. However, large, highperformance outboard motors require power trim. Power trim is simply a hydraulic system that serves to tilt the outboard motor up or down on the boat transom. Hydrobuck cannot successfully market the larger outboard motors without designing a power trim system to complement the motor. The company is financially secure and is the leading producer of small outboard motors. Management has decided that the following objectives need to be met within the next two years:

Question: Do you think he will feel the same way six weeks from now? Compare this approach with his previous approach.

1. Design a quality power trim system. 2. Design and build the equipment to produce such a system efficiently. 3. Develop the operations needed to install the system on the outboard motor. The technology, facilities, and marketing skills necessary to produce and sell the large motors already exist within the company. Questions: What alternative types of project organization would suit the development of the power trim system? Which would be best? Discuss your reasons for selecting this type of organization.

CONTINUING INTEGRATIVE CLASS PROJECT The job of organizing the project for speedy, competent execution on budget is a major factor in the success of every project. We are not concerned here with where the project resides in the college and who it reports to— it reports to the Instructor—but rather the internal organization of the project. It can be handled as a set of tasks where everyone in the class has some given responsibilities and a specified time to deliver the results, or through a set of teams responsible for different sets of project tasks.

If the class is small the former may be adequate, but for a larger class, it may be more efficient and practical to set up subteams (though probably NOT a third layer of subsub teams). For a class of say 35, five or six subteams may be optimal. This gives a uniform set of about five to seven direct reports for each manager, including the PM. Of course, some subteams may need fewer workers and others more, but they should be close to the right size. Again, recall that one constraint on the organization is that the

BIBLIOGRAPHY

subteams cannot all be completely independent. There are two reasons for this. One is that doing some of the work across all the chapters will be more valuable to an individual student (e.g., answering all the Review Questions) than doing all the work for just one chapter and then being ignorant of all the other topics. The second is that in real

209

projects there is typically considerable interaction, even conflict. If the project could be divided into a set of tasks that can all be done by different departments without interacting with each other, there is no need to set up a project to do the work!

BIBLIOGRAPHY Adams, J. R., and L. L. Adams. “The Virtual Project: Managing Tomorrow’s Team Today.” PM Network, January 1997. Baker, B. “In Common.” Project Management Journal, September 2007. Block, T. R. “The Seven Secrets of a Successful Project Office.” PM Network, April 1999. Block, T. R., and J. D. Frame. “Today’s Project Office: Gauging Attitudes,” PM Network, August 2001. Bushe, G. R., “When People Come and Go.” The Wall Street Journal. New York: August 23, 2010. Carlisle, A. S. “MacGregor.” Organizational Dynamics. New York: AMACOM, Summer 1976. Cleland, D. I. Strategic Management of Teams. New York: Wiley, 1996. de Laat, P. B. “Matrix Management of Projects and Power Struggles: A Case Study of an R&D Laboratory.” IEEE Engineering Management Review, Winter 1995, reprinted from Human Relations, Vol. 47, No. 9, 1994. Dewhurst, H. D. “Project Teams: What Have We Learned?” PM Network, April 1998. Dinsmore, P. C. “Converging on Enterprise Project Management.” PM Network, October 1998. Ford, R. C., and F. S. McLaughlin. “Successful Project Teams: A Study of MIS Managers.” IEEE Transactions on Engineering Management, November 1992. Gale, S. F. “The PMO Survival Guide.” PM Network, November 2010. Grant, R. M. “The Future of Management: Where Is Gary Hamel Leading Us?” Long Range Planning, 2008, pp. 469–482. Gratton, L. “Working Together . . . When Apart.” Wall Street Journal, June 16–17, 2007. Herzberg, F. H. “One More Time: How Do You Motivate Employees?” Harvard Business Review, January–February 1968. Hughes, T. P. Rescuing Prometheus. New York: Pantheon, 1998.

IEEE Engineering Management Review, 1st Qtr. (33:1) 2005. Kalu, T. Ch. U. “A Framework for the Management of Projects in Complex Organizations.” IEEE Transactions on Engineering Management, May 1993. Kotter, J. P. “Leading Change: Why Transformation Efforts Fail.” Harvard Business Review, March/April 1995. Reprinted in IEEE Engineering Management Review, Spring 1997. Lencioni, P. The Five Dysfunctions of a Team. San Francisco: Jossey-Bass, 2002. Levine, H. A. “Enterprise Project Management: What Do Users Need? What Can They Have?” PM Network, July 1998. Liu, L. and P. Yetton. “The Contingent Effects of Project Performance of Conducting Project Reviews and Deploying Project Management Offices.” IEEE Transactions on Engineering Management, November, 2007. Likert, R J., and G. Likert. New Ways of Managing Conflict. New York: McGraw-Hill, 1976. Nelson, B. “Energized Teams: Real World Examples.” PM Network, July 1998. Pinto, J. K. “Twelve Ways to Get the Least From Yourself and Your Project.” PM Network, May 1997. Project Management Institute. “Survey Reveals How Organizations Succeed.” PMI Today, February 2011. Tennant, D. “PMO Failure: An Observation,” PM Network, October 2001. Thamhain, H. J., and D. L. Wilemon. “Conflict Management in Project Life Cycles.” Sloan Management Review, Summer 1975. Tippet, D. D., and J. F. Peters. “Team Building and Project Management: How Are We Doing?” Project Management Journal, December 1995. Underwood, R., “OK, Everybody, Let’s Do This! Managing Projects and Collaborating with Co-Workers.” Inc. Magazine, July 2008. Williams, G. “Implementing an Enterprise Project Management Solution.” PM Network, October 1997.

210

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

The following case describes an unusual organizational arrangement for an actual manufacturing firm. The company is largely run by the employees through teams. When projects are instituted, it is common to pass the idea through the relevant teams first, before any changes are made. However, not everything can be passed through all the teams that may be involved in the change, and this can be a source of trouble.

C

A

S

E

OILWELL CABLE COMPANY, INC.* Jack R. Meredith As Norm St. Laurent, operations manager for Oilwell Cable Company, pulled his Ford Expedition onto Kansas’ Interstate 70, he heard on the CB about the traffic jam ahead of him due to icy road conditions. Although the traffic was moving some, Norm decided to get off at the eastern offramp for Lawrence, rather than the more direct western offramp, to save time. While waiting for the offramp to come up, Norm’s mind drifted back to his discussion with Bill Russell, the general manager, on the previous day. Norm had been contemplating adding microprocessors to their rubber mixing equipment in order to save manual adjustments on these machines. This would improve throughput and reduce costs simultaneously, though without displacing any employees. Based on the data Norm had seen, it appeared that the microprocessors could cut the production time by 1 percent and reduce scrap from the current rate of 1 percent down to one-half of 1 percent. However, it seemed that this might be an issue that should first be submitted to the production team in charge of rubber mixing for their thoughts on the idea. Once before, an even simpler change had been made without their knowledge and it wound up causing considerable trouble. As the traffic wound around two cars in the ditch by the highway, Norm reflected on how difficult it was to make changes at this plant with their team management process, though there were advantages too. It probably stemmed from the way the company was originally set up.

History of Oilwell Cable Company (OCC) Originally known as the Chord Cable Company and located in New Jersey, the firm had been experiencing severe management difficulties. When acquired by new management in 1993, they renamed it Oilwell Cable Company and relocated in Lawrence, Kansas to be closer to their primary

*Reprinted with permission. Copyright J.R. Meredith.

customers in northeastern Oklahoma. Their product line consisted primarily of flat and round wire and cables for submersible pumps in oil wells. The manager chosen to head up the new enterprise, Gino Strappoli, gave considerable thought to the organization of the firm. Gino envisioned a company where everyone took some responsibility for their own management and the success of the business. Gino preferred this approach not only for personal reasons but because cable manufacturing is a continuous process rather than a job shop-type of activity. The dedicated allegiance of the relatively few employees in a process firm is crucial to staying competitive. In such industries, direct labor commonly constitutes only 5 percent of the cost of the product, with indirect labor being another 5 percent. By contrast, in a job shop the wages paid for labor are a major determinant to being cost-competitive, often running 30 percent of product cost, thus introducing a potential conflict between labor and management. Gino reasoned that if he could obtain the employees’ commitment to improving productivity, reducing scrap, being innovative with new technologies, and staying competitive in general, he would have a very viable firm. With the approval of the new owners, Gino initiated his plan. Of the original labor force, only a few moved to Kansas, including Gino and the firm’s controller, Bill Safford. All new equipment was purchased for the firm, and a local labor force was selectively recruited. As the firm was organized, the team management process was developed. Eleven teams were formed, six of which constituted the production area. The remainder included the management team; the resource team (support functions such as computing services, accounting, etc.); the technical team (including the lab employees, R & D, and so on); the administrative team (office and clerical); and the maintenance team. These teams basically set their own work schedules, vacation schedules, and job functions. They addressed common problems in their work area and interfaced with other teams when needed to solve problems or improve processes. With Gino’s enthusiastic encouragement, the team

CASE

approach grew and took on more responsibility such as handling grievances and reprimanding team members when needed. In January 1995 the firm became profitable and later that year came fully on-stream. Gino soon thereafter left for another position, and the operations manager, Bill Russell, was selected to succeed him. At this point, Norm was brought in to replace Bill as operations manager. Norm had years of experience in manufacturing and was a degreed mechanical engineer. (See Exhibit 1 for the organization structure.) As Norm recalled, from 1995 to 1999 the firm rapidly increased productivity, improving profits significantly in the process and increasing in size to 140 employees. In so doing, they became the low-cost leader in the industry and gained a majority of the market share. This resulted in a virtual fourfold increase in sales since the days of Chord Cable Co. They were now approaching almost $25 million in annual sales. In 2000, however, the recession hit the oilwell industry. Added to this was the slowdown in energy consumption, effective conservation, and the oil glut. For almost a year the company bided time and idle employees were paid for minimal production. Management felt a commitment to the employees to avoid a cutback, more so than in a normally organized firm. But finally, in late 2000, top management told the teams that they would have to choose a method for handling this problem. Alternatives were shortened workweeks, layoffs, and other such measures. The teams chose layoffs. Next, management drew up a list of names of “recommended” layoff personnel representing a vertical slice through the organization—a top management employee, some professional and technical people, and a number of production employees. These lists were given to the teams who then decided what names to change and what names to keep. Management largely went along with the teams’ recommendations, and the layoffs (about 20) took place. With a slimmer work force, the division increased their productivity even more significantly (see Exhibit 2), allowing them to cut their product prices from between 10

and 20 percent. As the country climbed out of the stagnant economy in 2001, the division was excellently poised to capitalize on the increased economic activity, although oil itself was still largely in the doldrums. Increased demand in mid-2001 forced the division to use overtime, and then temporary help. They didn’t want to get back in the same workforce predicament they were in earlier.

The Team Management Process The 2000 layoff was a traumatic situation for the teams and the team process. Following that episode, the employees were unsure whether the team management process might require too much responsibility on their part. They had faced reprimanding employees in the past, and had even asked one employee to leave who tried to deceive them. In general, they were very receptive to employees’ individual problems and had helped their colleagues through tough times on many occasions, but now they were unsure. Team size varied from a low of 3 to a high of 17. The advantages of the team process to the firm seemed significant, in the minds of the team members and area managers. One member of the maintenance team noted that the team process gave much more responsibility to the employee and allowed the firm to obtain the maximum talent from each person. The firm, in response, spends $1,000 per person per year on upgrading the skills of the employees in such areas as team effectiveness training, technical skill acquisition, communication skills, and general skill building. Bill Russell sees the major benefit of the team process as its production flexibility. Employees are also very receptive to change. Since the 2000 layoffs, the employees have become much more sensitive to outside threats to their jobs. This spurred quality and productivity gains of over 30 percent in 2001. The primary benefit of the team process to the employees is having a say in their own work schedule. A typical secondary benefit was the elimination of penalties for making an error. The employees feel that this is an

General manager Bill Russell

Controller Bill Safford

Accounting

Exhibit 1

Operations manager Norm St. Laurent

Purchasing Production Maintenance

211

Human resource manager Sheree Demming

Human resources

Organization Chart: Oilwell Cable Division

R&D manager Burt MacKenzie

Lab

Quality assurance

212

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

400

Productivity index

300

200

100

1996

1997

1998

1999

2000

Year

excellent place to work; absenteeism is only 0.7 percent, and only two people have left voluntarily since 1998. Overall, the employees seemed to feel that this process worked well but wasn’t utopian. “It doesn’t give away the store,” one employee commented. Two disadvantages of the process, according to the employees, were the time and energy it required on their part to make decisions. As an example, they noted that it required three full days for the teams to come up with the revised layoff lists. Normally the teams met once a week for an hour and a half. But when the teams made a decision, the implementation of the decision was virtually immediate, which was a big advantage over most management decisions. Although this process required more time on the part of the employees, the total amount of time from idea to full implementation was probably less than that in a traditional organization, and it was clearly more successful. When asked if he would ever be willing to work in a regular work environment again, one team member voiced the opinion that this process, while very good, really wasn’t that much different from a well-run, open, traditional organization. Teams realized that not every decision was put through them. They felt that this was appropriate, however. They also recognized the difficulty facing management when trying to decide whether something should come through the teams or if it was unnecessary to consult them. Though the teams met on company time, they were not eager to spend more time on team meetings. Especially after the layoff crisis, the teams realized that selfmanagement was a two-way street and frequently hoped that upper management would make the tough decisions for them.

2001

Exhibit 2

Productivity History

In summary, the teams felt that the process was based on trust, in both directions, and was working pretty well.

The Cable Production Process As Norm pulled his truck into the OCC parking lot, he noticed that there were quite a few empty spaces. This 2002 winter had been more severe than most people had expected, based on the November and December weather. The snow was almost over Norm’s boots as he slogged his way to the buildings. Upstairs in his small, jumbled office, Norm pulled out the microprocessor file from his desk drawer and sat down to review the production process. Their primary raw materials, which made up about 60 percent of the products’ cost, included copper rods, lead, polypropylene, nylon, and rubber. Inspection consisted of submerging the cable in water and charging it with 30,000 volts. To date, none of their products had ever been returned. However, just in case they were ever queried about a cable they had produced, they kept samples of all their cables for five years back. The firm considered itself very vulnerable to new technology, and hence kept an active R & D lab in continuous operation. Simple advances in process technology or insulation and jacketing materials could wipe out their market overnight, so they didn’t want to be caught napping. Other methods of oil extraction were also a constant threat. Since they competed in a world market, they were highly exposed to foreign competition, and the location of their competitors was often a major factor in sales.

DIRECTED READING

213

QUESTIONS 1. If Norm chooses to go ahead with the microprocessor conversion on the machinery without passing it by the team, what are the potential conflicts that might arise? What are the advantages of such a move? 2. If Norm decides to put the decision to the appropriate production team, what are the potential problems? What would be the advantages? 3. If the production team chooses to approve and implement this microprocessor conversion project, what form of project organization will this represent? 4. Given the size of this organization and the number of projects they deal with, would it make sense to institute

a Project Management Office? Is there another arrangement that might be a good alternative? 5. How much impact might microprocessors have on production costs? Assume that variable overhead represents the same percentage of costs as fixed overhead. Find the net present value if the microprocessors cost $25,000 and their installation runs another $5,000. Assume a 10% margin. 6. Compare Norm’s recollection of the division’s productivity gains between 1995 and 1999 to Exhibit 2. Explain the inconsistency. 7. What would you recommend that Norm do?

The following reading discusses a new phenomenon in the increasingly global competitive environment—geographically dispersed project teams. The competitiveness of global firms is often facilitated by new electronic technologies, and these technologies are also useful to the success of globally dispersed project teams, as described in the article. However, other aspects of such dispersed teams are more problematic, and the article illustrates these, as well as approaches used by project managers for circumventing them. Finally, some of the advice given in the article should be useful as well for project teams that aren’t geographically dispersed.

D I R E C T E D

R E A D I N G

THE VIRTUAL PROJECT: MANAGING TOMORROW’S TEAM TODAY* J. R. Adams and L. L. Adams

Extraordinary demands are placed on project personnel— demands that require extraordinary commitments in order to accomplish the task at hand. Generating this commitment through the process of team building is a primary responsibility of any project manager. The processes of team building have been studied extensively by both academics and practitioners for decades, but until recently nearly all of these studies were conducted within the bureaucratic setting: that is, the team members shared a common workplace, saw each other frequently, knew each other well, and expected to continue working together for an extended period of time. The team building concepts developed within such an environment naturally reflect these working conditions as either stated or implied assumptions, and the concepts derived

*Reprinted from PM Network with permission. Copyright Project Management Institute Inc.

from these studies can be assumed to hold only as long as these assumptions hold. These concepts still hold for projects intended to support and improve bureaucratic organizations. In the vast majority of cases, however, the working conditions experienced by modern projects differ greatly from those surrounding traditional bureaucratic work. Nevertheless, the basic definitions of team building continue to emphasize the assumption of typical bureaucratic working conditions. For example, one leading textbook in the field (Kast and Rosenzweig’s Organization and Management: A Systems and Contingency Approach, McGraw-Hill, 1985) states that “actual teamwork involves small groups of three to fifteen people that meet face-to-face to carry out their assignments.” Even in PMI’s current PMBOKGuide (pp. 99–100), one of the five basic “tools and techniques” of team development is called “collocation,” which involves “. . . placing all, or almost all, of the most active project team members in the same physical location to enhance

214

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

their ability to perform as a team.” In both of these publications, the concept of the virtual project is clearly ignored. In the new, “virtual project” environment, team members seldom share a common workplace, may rarely see each other, may never have worked together before, and may never work together again after the project is complete. For an ever-increasing number of organizations, the world is represented by an environment of rapid technological advancement, particularly in the area of communications; complex organizational structures needed to deal with tough global competition; and dynamic markets that demand short production runs of unique products. Downsizing, outsourcing, and employee empowerment have become facts of life in the climate of many organizations, while job security is rapidly becoming a thing of the past. The survival of many organizations depends on the ability of the organization to rapidly change its structure, culture, and products to match the changing demands of the environment. Let’s explore the conditions faced by the modern project manager in developing an effective and productive project team within a “virtual project.” The Virtual Project The virtual project, also known as a “distributed team,” is one in which the participants are geographically distributed to an extent that they may seldom, if ever, meet face-to-face as a team. The geographical distances involved do not have to be great; individuals who work in the same industrial complex may be functioning in a virtual project if their schedules do not allow them to meet face-to-face. As distances increase, however, the difficulties of communicating and building teams increase significantly. When team members are spread across several time zones, opportunity for direct communication is severely limited, and the associated costs of both face-toface and electronic communications increase dramatically. Electronic communication takes on much more importance in virtual projects because electronic systems must assume the burden of making the development of effective project teams possible. It is beyond the scope of this article to discuss at length the issues that are generating the need for virtual projects. Suffice it to say that the environmental conditions described above are precisely those that require project teams to be dispersed. Jaclyn Kostner has written extensively on the virtual project. In Knights of the TeleRound Table (Warner Books, 1994), she documents the unique issues faced by project managers who must manage such a virtual or distributed project. The issues she defines are shown in the left-hand column of the accompanying sidebar. Developing trust is the greatest challenge to the remote project manager. It’s difficult for distant team members to get to know each other well; consequently, they tend to communicate poorly because they often are less than com-

fortable with each other. Both of these situations destroy the trust that is so essential to creating good teamwork. Developing a group identity across distances is also difficult because people normally associate with events that occur at their local level. Teams tend to have a problem sharing information effectively across distances. One reason for this may be the lack of informal opportunities for discussion at lunches or during coffee breaks. Developing clear structures is an issue for the virtual project manager because distant work groups need more than the traditional vision, mission, and goals that are important for all project groups. Members of virtual teams tend to develop relationships with those who are located with them rather than with those who are at distant sites. The formation of such “cliques” can create competition or antagonism between the project manager and/or team members located elsewhere. Lastly, each distributed team member tends to have information that is somewhat different from that held by others. More important, each team member views information from a different perspective. Such inequities of information frequently increase the opportunity for miscommunication among team members. If issues such as these are not dealt with, the virtual project experiences management difficulties far in excess of the more “typical” project with higher levels of collocation. Fortunately, the technology that has made virtual projects both possible and necessary also provides opportunities for dealing progressively with these problems. Implementing Virtual Project Teams The sidebar includes suggestions created by virtual project managers for using the advantages of project management team building to overcome virtual team difficulties. Generally, these suggestions encourage project managers to make creative use of modern communication technologies to bring the team together and encourage the participation and sense of ownership that generates commitment to the project and team objectives. Since it’s seldom possible in the virtual project to meet face-to-face, experienced project managers recommend using a variety of electronic communications. Trust seems to develop as the individual team member learns more about the project manager, other team members, and the project. It’s therefore essential that team members be encouraged to communicate with each other frequently, as well as with the project manager and the team as a whole. Virtual project managers use all forms of electronic communication— cellular phones, pagers, faxes, e-mail, Web pages, and computer-to-computer transmissions across local area and wide area networks—to distribute everything from key reports to jokes, logos, and mottoes. These communications are specifically intended to increase the common experiences shared by the team members and thus increase the bonds among them. Regularly scheduled video and telephone conference calls increase team members’ exposure to project information, as well as to each other.

DIRECTED READING

215

Virtual Project Management Suggestions Issues

Problems

Suggestions

Developing Trust

Irregular, inconsistent communication; lower level of comfort and familiarity among team members; “us vs. them” attitude.

Provide and use a variety of communication alternatives. Communicate electronically except when signatures are required. Make project management software available to all team members.

Developing Group Identity

Fewer shared experiences; lack of cohesion; little understanding of other members’ roles and responsibilities.

Conduct regular teleconference meetings when the need warrants. Manage the agenda to include a variety of participants and ensure everyone is involved in the discussion. Use logos, mottoes, and creative humor. Stay in contact when meetings are not required. Note: Do not exclude anyone from group discussions.

Sharing Information

Difficulty sharing adequate levels of information across distances; lack of formal opportunities to discuss work-related issues; lack of a common system to transmit information across distances.

Use technology to develop additional information-sharing opportunities: cellular phones, pagers, faxes, telephones, e-mail, Internet, and computer-tocomputer. Distribute all key reports to all team members. Put information at one central access point, e.g., a project Web page, a LAN account.

Developing Clear Structures

Use standard formats for meetings. Define Uncertain roles and responsibilities goals, objectives, problems, and conof team members; clashing culcerns at the kickoff meeting, and reitertures create different expectations, ate them frequently. Have participants few clearly defined processes for describe and define potential problems decision making. and concerns, and evaluate risks as a group.

Formation of “Cliques” or Informal Subgroups

The project manager can’t prevent them Cliques tend to create antagonism from forming, but can manage these and competition between the team subgroups. Identify and keep track of and the project manager, between them. Create subcommittees for dealteam members, or among the ing with problems, drawing members cliques themselves. from the different cliques. Look for opportunities to mix participants from the different cliques, and initiate or create these opportunities when necessary.

Understanding Information

Ask members to explain their viewpoints. Each team member has different Ask members to describe the actions information (inconsistent); each they plan to take, and solicit possible member has varying levels of impacts to other involved parties. information (incomplete); each Use different levels of information member has a different perspecfor different participants, as tive of the information. All = ineqappropriate. uities of information.

216

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

When cliques form as subgroups of the project team, these subgroups are managed, not ignored. Subcommittees are created to resolve project problems, specifically drawing members from different cliques together so that they learn more about each other. Team members are frequently asked to explain their viewpoints and to discuss their plans with the team at large to improve the common understanding of information about the project, its progress, and its prospects. Four specific types of electronic communication, which didn’t even exist just a few years ago, are being used extensively by managers of virtual projects to help overcome the lack of formal and informal personal contact among the team members. The Internet. As technology creates conditions that demand faster reactions, team building over extensive distances, and ever-more-extensive communications, that same technology provides new approaches with which to deal with these issues. The Internet provides a means for communicating quickly and inexpensively throughout the world. It is essential for all participants in virtual project teams to have access to the Internet and e-mail. The virtual project manager relies on e-mail to exchange project data with the dispersed team, especially when team members or clients are internationally located. E-mail is a particularly good tool for exchanging the detailed information necessary to update the status of project activities. This task is difficult to accomplish verbally via telephone or videoconference because of the detail involved and the difference in time zones. Transmitting such data by facsimile can be expensive due to the volume of data involved, the frequency of needed updates, and the requirement for consistent information flows. With e-mail as the primary mode of communication, information flows easier and faster, and the difference in time zones is less likely to be a critical failure factor. The ease of communication encourages the team to communicate more often and in more detail. Team members get to know each other more personally, and therefore develop more cohesive working relationships. One word of caution, however; many companies, in a misguided attempt to economize, are limiting the use of e-mail to “official” business, and eliminating personal comments, jokes, and other “nonessential” communications. It is precisely these “informal” transmissions that can at least partially make up for the lack of personal contact. Informal e-mail communications can replace some face-to-face contact and help generate the close working relationships, commitments, and friendships that are traditionally considered to be characteristic of successful project teams. The Pager. A byproduct of today’s business environment is that technical specialists (team members) frequently are working on multiple projects, and are considered highly valuable resources. The time of these “highly valuable

resources” may be quite limited. Though regularly scheduled project meetings are critical throughout the project life cycle, these valuable resources may often be required elsewhere, and the project manager may need to help conserve their time. One way to make the best use of a team member’s time is to use a paging system. Each team member carries a pager, and the pager numbers are published with the team roster. When agenda topics don’t directly relate to a particular team member or function, that person can be released from attendance, freeing up time that can then be used more productively. If an issue surfaces that requires that person’s attention, he or she can be “paged” into the teleconference call. This allows for quick responses to problems and issues, and limits the number of “open action items” on meeting minutes. This procedure must be established at the project’s kickoff meeting, when the project manager discusses team roles, responsibilities, and expectations. A culture must be developed within the project where each team member is expected to respond quickly to paging, especially when a 911 code, meaning an emergency needing immediate response, is attached to the pager number. Teleconferencing. Teleconferencing is not as new as some of the techniques noted above, but its use has expanded dramatically in recent years along with the increase of virtual projects. Everyone thinks they understand teleconferencing, but few are able to use it effectively. The lack of visual communication means that only the spoken word is available for the transfer of information, so individual speakers must identify themselves when contributing to the discussion. The medium was originally designed to provide communications between two people. When more people are added to the conference, managing the conversation flow rapidly becomes a complex issue. The goal is to assure that everyone has an opportunity to contribute and that all issues are dealt with in a reasonable period of time. Using telephony technology for communicating among several people requires careful management and control of the communication process. The project manager cannot manage the results of the communications, but must manage the process of getting to those results. The conference needs to be well-organized and structured. A detailed agenda is essential to a productive conference call. The project manager should schedule the call in advance so that an agenda can be published and distributed at least two to three days prior to the meeting. The agenda should always include specific items of information: purpose of the teleconference, day-date-time of the call, call-in number, expected duration of the call, chair of the meeting (the project manager), a detailed listing of items to be discussed, and the key participants for each item noted. The project manager can then facilitate discussion among these key players, solicit input from other team members,

DIRECTED READING

and maintain a solution-oriented attitude. This structure allows all essential persons to share in the conversation and present their viewpoints, while keeping the team focused on the critical issues at hand. The structure also prevents side conversations and keeps the team from straying from the intended topic until a solution has been achieved. The checklist in the accompanying sidebar is useful for developing a successful teleconference.

Teleconferencing Tips

Include an overall time limit for scheduling purposes (for yourself and for your team). Anything over 1.5 hours tends to become unproductive because of the high level of concentration required to communicate in an audio-only format. Organize the meeting in two sequential categories. In Category 1 are those activities that on the project plan should be completed by the time the meeting occurs. In Category 2 are those activities that need to be completed prior to the next meeting. Have one major agenda topic called “deliverables,” where the deliverables that are due or past-due are listed, along with who is responsible for completing those items. The items can be statused and assistance can be solicited from the team to expedite completion. Always have an “open discussion” section at the end of the agenda. Do a round-table roll call of each person to see if anyone has comments or concerns that need to be discussed or documented in the minutes. Putting the open discussion section last also keeps the focus on issues that are critical to the project, rather than on issues that may be critical to an individual. If time runs out, at least the necessities have been covered. Invite team members to call in or e-mail additional agenda topics, and then add these topics to the agenda for discussion. If people can’t submit topics prior to agenda distribution, introduce new items only during the open discussion section so that the flow of the meeting is not disrupted. Talk about any major changes to the schedule, such as slippages or early completions that affect the schedule or multiple departments, at the beginning of the conference. These changes could drastically affect the items on the agenda, the flow of the conference call, or even the flow of work for your whole project.

217

Videoconferencing. With a geographically dispersed team, the cost of travel, including the cost of team members’ time during travel, is too high to justify having the team involved in periodic face-to-face status meetings. However, current issues may be too critical to rely on e-mail, teleconferencing, and one-on-one voice contact. This is a time when videoconferencing is the most appropriate form of communication. A capability not present in other forms of electronic communication, videoconferencing allows participants to feel more involved with each other because they can communicate on many different levels. Body language and facial expressions can be observed and interpreted, in many cases transferring more meaning than the actual words. Full team participation in developing the initial work breakdown structure and the project plan, both of which occur in the kickoff meeting, is crucial to developing the commitment to the virtual project team. It is particularly appropriate to have the kickoff meeting in a site that is videoconference-accessible, if possible, so that if some people can’t attend then they can still be involved. Despite all its good points, there is a downside to videoconferencing. Some of the common problems and barriers are logistical. For example, all participants must be located at pre-arranged receiving/transmitting sites; and, although the cost has been decreasing slowly, videoconferencing is still quite expensive, especially when numerous sites and satellite-based communications are involved, so these sites may not be readily accessible. Also, even though technology is gradually moving forward and the signal transmission speed is increasing, videoconferencing uses a wide bandwidth, which translates into a significant delay in viewing the movements and expressions of participants. This delay as well as an individual’s tendency to be uncomfortable in front of a camera frequently combine to make the whole process somewhat stiff and stilted. This seems to be a particular problem in systems where the participants can see themselves and worry about how they look to the others. Since the purpose of this extraordinary use of electronic communications is to increase the stability of the virtual project, it is particularly important that all team members be able to work with the detailed project plan. All team members should have access to whatever software is being used to plan and control project activities. They should also have easy access to the project files. The liberal distribution of project documentation provides enhanced communication as well as an exposure to the project cultural structure. A basic knowledge of team building is essential to the effective management of any project. With the advent of the virtual project, however, the methods and techniques necessary for implementing the project team building process have changed. Face-to-face communications are obviously desirable, but they may no longer be possible

218

CHAPTER 5 / THE PROJECT IN THE ORGANIZATIONAL STRUCTURE

because of time or cost constraints. Fortunately, the same technologies that have made the virtual project a possibility also provide the methods for developing effective teams of dispersed project participants. Virtual project managers must be both knowledgeable and creative in using the modern communication technologies available to them for the purpose of enhancing the common experiences of their project team members, and hence the commitment that can be generated for the project’s objectives and goals. Perhaps more important, however, is to recognize that the ability to effectively use all of the current electronic communication techniques available to the project manager is rapidly becoming a mandatory skill for anyone likely to be involved in virtual projects. This topic deserves some extensive research in order to help the virtual project manager develop more effective methods and techniques for dealing with the task of

building effective project teams from dispersed project participants. Questions 1. Which virtual project problems are unique to the phenomenon of being dispersed and which are common project problems in any project? 2. What new electronic technologies have contributed to the problems, and solutions, of virtual project teams? 3. Of the solutions to virtual team problems, which would apply to regular project teams also? 4. Which problems described in the article are the most serious for virtual projects? Which might be fatal? 5. How might the difficulties of matrix organization change when implementing virtual projects?

P

A

R

T

II PROJECT PLANNING

In Part II we discuss project planning in terms of planning the activities, budget, and schedule for the project, as shown in the accompanying figure. Chapter 6 deals with project activity and risk planning and presents tools useful in organizing and staffing the various project tasks. It also contains a short discussion of phase-gate management systems and other ways of dealing with

the problems that arise with complex projects. Budgeting, the planning and control of costs, is addressed next in Chapter 7. We also include a section on the treatment of risks in budgeting through simulation. Scheduling, a crucial aspect of project planning, is then described in Chapter 8, along with the most common scheduling models such as the Program

Project Management

Ch1: Projects in Contemporary Organizations

Project Initiation

Project Planning

Project Execution

Ch2: Strategic Management and Project Selection

Ch6: Project Activity and Risk Planning

Ch10: Monitoring and Information Systems

Ch3: The Project Manager

Ch7: Budgeting: Estimating Costs and Risks

Ch11: Project Control

Ch4: Conflict Management and the Art of Negotiation

Ch8: Scheduling

Ch12: Project Auditing

Ch5: The Project in the Organizational Structure

Ch9: Resource Allocation

Ch13: Project Termination

219

220

PART II / PROJECT PLANNING

Evaluation and Review Technique (PERT) and precedence diagramming. Concluding Part II, the effect of resource allocation on the project schedule is covered in Chapter 9. For single projects, we discuss how the resource allocation problem concerns resource leveling to minimize the cost of the resources while still

remaining on schedule. But for multiple projects, we learn that the issue is how to allocate limited resources among several projects in order to achieve the objectives of each. This chapter also describes project crashing (by the Critical Path Method) and scheduling insights from the concept of the Critical Chain.

C

H

A

P

T

E

R

6 Project Activity and Risk Planning

PMBOK Guide Chapters 6, 11, 8

This chapter initiates our discussions of Time, Quality, and Risk Management, PMBOK knowledge areas 3, 5, and 8, respectively. Time management is an extensive topic which is further discussed in Chapters 8, 10, and 11. Similarly, risk will be discussed further in Chapters 7 and 8, and quality will be discussed again in Chapter 12. In the Reader’s Digest (March 1998, p. 49) Peter Drucker is quoted on planning: “Plans are only good intentions unless they immediately degenerate into hard work.” To make such a transformation possible is no easy task. Inadequate planning is a cliché in project management. Occasionally, articles appear in project management periodicals attesting to the value of good planning. Project managers pay little attention. PMs say, or are told, that planning “takes too much time,” “customers don’t know what they want,” “if we commit we will be held accountable,” and a number of similar weak excuses (Bigelow, 1998, p. 15). Tom Peters, well-known seeker of business excellence, was quoted in the Cincinnati Post: “Businesses [believe] a lot of dumb things. . . . The more time you spend planning, the less time you’ll need to spend on implementation. Almost never the case! Ready. Fire. Aim. That’s the approach taken by businesses I most respect.” We strongly disagree and, as we will report below (and in Chapter 13), there is a great deal of research supporting the view that careful planning is solidly associated with project success—and none, to our knowledge, supporting the opposite position. On the other hand, sensible planners do not kill the plan with overanalysis. This leads to the well-known “paralysis by analysis.” In an excellent article, Langley (1995) finds a path inbetween the two extremes. Thus far, we have dealt with initiating a project. Now we are ready to begin the process of planning the work of the project in such a way that it may be translated into the “hard work” that actually leads to the successful completion of the project. There are several reasons why we must use considerable care when planning projects. The primary purpose of planning, of course, is to establish a set of directions in sufficient detail to tell the project team exactly what must be done, when it must be done, what resources will be required to produce the deliverables of the project successfully, and when each resource will be needed. As we noted in Chapter 1, the deliverables (or scope, or specifications, or objectives) of a project are more than mere descriptions of the goods and/or services we promise to deliver to the client at a quality level that will meet client expectations. The scope of a project also includes the time and cost required to complete the project to the client’s satisfaction. The plan

221

222

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

must be designed in such a way that the project outcome also meets the objectives, both direct and ancillary, of the parent organization, as reflected by the project portfolio or other strategic selection process used to approve the project. Because the plan is only an estimate of what and when things must be done to achieve the scope or objectives of the project, it is always carried out in an environment of uncertainty. Therefore, the plan must include allowances for risk and features that allow it to be adaptive, i.e., to be responsive to things that might disrupt it while it is being carried out. One frequent such disruption—“scope creep,” or the tendency of project objectives to be changed by the client, senior management, or individual project workers with little or no discussion with the other parties actively engaged in the work of the project—is particularly common in software projects. In addition, the plan must also contain methods to ensure its integrity, which is to say it must include means of controlling the work it prescribes. Finally, and quite apart from the deliverables required by the project itself, the plan must include any constraints on activities and input materials proscribed by law and society. Among the many sources of outside constraints are the Food and Drug Administration, the Occupational Health and Safety Administration, other federal and state laws and regulations, various engineering societies, labor unions, and the “Standard Practices” of many different industries. Such constraints are meant to protect us all from unsafe or harmful structures, machines, rugs, equipment, services, and practices.

Project Management in Practice Beagle 2 Mars Probe a Planning Failure

As the Beagle 2 Mars probe designed jointly by the European Space Agency and British National Space Center headed to Mars in December of 2003, contact was lost and it was never heard from again. In

retrospect, it appears that inadequate project planning (and replanning) was to blame. Excessive pressure on time, cost, and weight compromised the mission right from the start. With insufficient public funding, the

PROJECT ACTIVITY AND RISK PLANNING

design team had to spend much of their time raising private funds instead of addressing difficult technical issues. In addition, late changes forced the team to reduce the Beagle’s weight from 238 pounds to 132 pounds! And when the three airbags failed to work properly in testing, a parachute design was substituted but inadequately tested due to lack of time. A review commission recommended that in the future:

Requisite financing be available at the outset of a project

• • • •

223

Formal project reviews be conducted on a regular basis Milestones should be established where all stakeholders reconsider the project Expectations of potential failure should be included in the funding consideration Robust safety margins should be included and funded for uncertainties

Source: Project Management Institute. “Mars or Bust,” PM Network, Vol. 18.

There is an extensive literature on project planning. Some of it is concerned with the strategic aspects of planning, being focused on the choice of projects that are consistent with the organization’s goals. Another group of works is aimed at the process of planning individual projects, given that they have been chosen as strategically acceptable. Most fields have their own accepted set of project planning processes. Except for the names given to the individual processes, however, they are all similar, as we shall soon see. The purpose of planning is to facilitate later accomplishment. The world is full of plans that never become deeds. The planning techniques covered here are intended to smooth the path from idea to accomplishment. It is a complicated process to manage a project, and plans act as a map of this process. The map must have sufficient detail to determine what must be done next but be simple enough that workers are not lost in a welter of minutiae. In the pages that follow we discuss a somewhat formal method for the development of a project charter (similar to a proposal, or preliminary plan) and final project plan. Almost all project planning techniques differ only in the ways they approach the process of planning. Most organizations, irrespective of the industry, use essentially the same processes for planning and managing projects, but they often call these processes by different names. What some call “setting objectives,” others call “defining the scope” of the project, or “identifying requirements.” What some call “evaluation,” others call “test and validation.” No matter whether the project is carried out for an inside or outside client, the project’s “deliverables” must be “integrated” into the client’s processes. We have adopted an approach that we think makes the planning process straightforward and fairly systematic, but it is never as systematic and straightforward as planning theorists would like. At its best, planning is tortuous. It is an iterative process yielding better plans from not-so-good plans, and the iterative process of improvement seems to take place in fits and starts. The process may be described formally, but it does not occur formally. Bits and pieces of plans are developed by individuals, by informal group meetings, or by formalized planning teams (Paley, 1993), and then improved by other individuals, groups, or teams, and improved again, and again. Both the plans themselves and the process of planning should start simple and then become more complex. If the appropriate end product is kept firmly in mind, this untidy process yields a project plan. In this chapter we focus on designing the physical aspects of the project, defining what the project is supposed to accomplish, and who will have to do what for the project’s desired output to be achieved. Here we describe the actual process of project planning. Organizing the work of the project, acquiring a project manager, and forming a project team are parts of project initiation. The project’s budget and schedule are major

224

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

parts of the project plan, but we delay discussion of them until Chapters 7 and 8. Indeed, what must be done to test and approve project outputs at both interim and final stages, and what records must be kept are both parts of the project plan and these are covered in later chapters, as is the part of the plan that covers terminating the project. There is nothing sacrosanct about this sequence. It is simply in the order that these parts of the project plan tend to develop naturally.

6.1

INITIAL PROJECT COORDINATION AND THE PROJECT CHARTER It is crucial that the project’s objectives be clearly tied to the overall mission, goals, and strategy of the organization, such as might be reflected in the project portfolio process. In the project charter, senior management should delineate the firm’s intent in undertaking the project, outline the scope of the project, and describe how the project’s desired results reinforce the organization’s goals. Without a clear beginning, project planning (and later progress) can easily go astray. It is also vital that a senior manager call and be present at the project launch meeting, an initial coordinating meeting, as a visible symbol of top management’s commitment to the project. The individual leading the launch meeting is first to define the scope of the project as detailed in the charter. The success of the project launch meeting is absolutely dependent on the existence of a well-defined set of objectives. Unless all parties to the planning process have a clear understanding of precisely what it is the project is expected to deliver, planning is sure to be inadequate or misguided. At the launch meeting, the project is discussed in sufficient detail that potential contributors develop a general understanding of what is needed. If the project is one of many similar projects, the meeting will be short and routine, a sort of “touching base” with other interested units. If the project is unique in most of its aspects, extensive discussion may be required. It is useful to also review the major risks facing the project during the launch meeting. The known risks will be those identified during the project selection process. These are apt to focus largely on the market reaction to a new process/product, the technical feasibility of an innovation, and like matters. The risk management plan for the project must be started at the launch meeting so that further risk identification can be extended to include the technology of the process/product, the project’s schedule, resource base, and a myriad of other risks facing the project but not really identifiable until the project plan has begun to take form. In addition to the matters discussed below, one of the outcomes of the project planning process will be the formulation of the project’s risk management group and the initial risk management plan that the group develops during the process of planning the project. While various authors have somewhat different expectations for the project launch meeting (e.g., see Knutson, 1995; Martin et al., 1998), we feel it is important not to allow plans, schedules, and budgets to go beyond the most aggregated level, especially if the project deliverables are fairly simple and do not require much interdepartmental coordination. To fix plans in more detail at this initial meeting tends to prevent team members from integrating the new project into their ongoing activities and from developing creative ways of coordinating activities that involve two or more organizational units. Worse still, departmental representatives will be asked to make “a ballpark estimate of the budget and time required” to carry out this first-blush plan. Everyone who has ever worked on a project is aware of the extraordinary propensity of preliminary estimates to metamorphose instantaneously into firm budgets and schedules. Remember that this is only one of a series of meetings that will be required to plan projects of more than minimal complexity. It is critical to the future success of the project to

6.1

INITIAL PROJECT COORDINATION AND THE PROJECT CHARTER

225

take the time required to do a technically and politically careful job of planning. “If this means many meetings and extensive use of participatory decision making, then it is well worth the effort” (Ford et al., 1992, p. 316). Whatever the process, the outcome must be that: (1) technical scope is established (though perhaps not “cast in concrete”); (2) basic areas of performance responsibility are accepted by the participants; (3) any tentative delivery dates or budgets set by the parent organization are clearly noted; and (4) a risk management group is created. Each individual/unit accepting responsibility for a portion of the project should agree to deliver, by the next project meeting, a preliminary but detailed plan about how that responsibility will be accomplished. Such plans should contain descriptions of the required tasks, and estimates of the budgets (labor and resources) and schedules.

Project Management in Practice Child Support Software a Victim of Scope Creep

In March 2003, the United Kingdom’s Child Support Agency (CSA) started using their new £456 million ($860 million) software system for receiving and disbursing child support payments. However, by the end of 2004 only about 12 percent of all applications had received payments, and even those took about three times longer than normal to process. CSA thus threatened to scrap the entire system and withhold £1 million ($2 million) per month in service payments to the software vendor. The problem was thought to be due to both scope creep and the lack of a risk management strategy. The vendor claimed that the project

was disrupted constantly by CSA’s 2500 change requests, while CSA maintained there were only 50, but the contract did not include a scope management plan to help define what constituted a scope change request. And the lack of a risk management strategy resulted in no contingency or fallback plans in case of trouble, so when project delays surfaced and inadequate training became apparent, there was no way to recover. Source: Project Management Institute. “Lack of Support,” PM Network, Vol. 19.

226

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

PMBOK Guide Chapter 11

Simultaneous with these planning activities, the risk management group develops a risk management plan that includes proposed methodologies for managing risk, the group’s budget, schedule, criteria for dealing with risk, and required reports. Further, necessary inputs to the risk data base are described and various roles and responsibilities for group members are spelled out, as noted in PMBOK (Project Management Institute, 2008). It must be emphasized that the process of managing risk is not a static process. Rather, it is ongoing, with constant updating as more risks are identified, as some risks vanish, as others are mitigated—in other words as reality replaces conjecture—and new conjecture replaces old conjecture. The various parts of the project plan, including the risk management plan, are then scrutinized by the group and combined into a composite project plan. The composite plan, still not completely firm, is approved by each participating group, by the project manager, and then by senior organizational management. Each subsequent approval hardens the plan somewhat, and when senior management has endorsed it, any further changes in the project’s scope must be made by processing a formal change order. If the project is not large or complex, informal written memoranda can substitute for the change order. The main point is that no significant changes in the project are made, without written notice, following top management’s approval. The definition of “significant” depends on the specific situation and the people involved. The PM generally takes responsibility for gathering the necessary approvals and assuring that any changes incorporated into the plan at higher levels are communicated to, and approved by, the units that have already signed off on the plan. Nothing is as sure to enrage functional unit managers as to find that they have been committed by someone else to alterations in their carefully considered plans without being informed. Violation of this procedure is considered a betrayal of trust. Several incidents of this kind occurred in a firm during a project to design a line of children’s clothing. The anger at this change without communication was so great that two chief designers resigned and took jobs with a competitor. Because senior managers are almost certain to exercise their prerogative to change the plan, the PM should always return to the contributing units for consideration and reapproval of the plan as modified. The final, approved result of this procedure is the project plan, also sometimes known as the baseline plan. When the planning phase of the project is completed, it is valuable to hold one additional meeting, a postplanning review (Martinez, 1994). This meeting should be chaired by an experienced project manager who is not connected with the project (Antonioni, 1997). The major purpose of the postplanning review is to make sure that all necessary elements of the project plan have been properly developed and communicated.

Outside Clients When the project is to deliver a product/service to an outside client, the fundamental planning process described above is unchanged except for the fact that the project’s scope cannot be altered without the client’s permission. A common “planning” problem in these cases is that marketing has promised deliverables that engineering may not know how to produce on a schedule that manufacturing may be unable to meet. This sort of problem usually results when the various functional areas are not involved in the planning process at the time the original proposal is made to the potential client. We cannot overstate the importance of a carefully determined set of deliverables, accepted by both project team and client (Martin et al., 1998). Two objections to such early participation by engineering and manufacturing are likely to be raised by marketing. First, the sales arm of the organization is trained to sell and is expected to be fully conversant with all technical aspects of the firm’s products/services. Further, salespeople are expected to be knowledgeable about design and manufacturing lead

6.1

INITIAL PROJECT COORDINATION AND THE PROJECT CHARTER

227

times and schedules. On the other hand, it is widely assumed by marketing (with some justice on occasion) that manufacturing and design engineers do not understand sales techniques, will be argumentative and/or pessimistic about client needs in the presence of the client, and are generally not “housebroken” when customers are nearby. Second, it is expensive to involve so much technical talent so early in the sales process—typically, prior to issuing a bid or proposal. It can easily cost a firm more than $10,000 to send five technical specialists on a short trip to consider a potential client’s needs, not including a charge for the time lost by the specialists. The willingness to accept higher sales costs puts even more emphasis on the selection process.

Project Management in Practice Shanghai Unlucky with Passengers

To speed passengers to Shanghai’s new international airport, China built a magnetic levitation (maglev) train that runs every 10 minutes from Shanghai’s business center to the Pudong International Airport. Reaching speeds over 300 miles an hour, it whisks people to the airport 20 miles away in less than 8 minutes. However, according to the vice-director of the train company, “We are not lucky with ticket sales.” since the trains are virtually empty. The reason is because to meet the project’s time deadline and budget, the train station was located 6 miles

outside the city center, requiring lengthy public transportation to get there. So in spite of the technical, budget, and timing success of the project, it failed to meet the needs of the passengers. China is currently investigating extending the line to the downtown area, but that will be a much more expensive and time-consuming project.

Source: Project Management Institute. “A Derailed Vision,” PM Network, Vol. 18.

228

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

The rejoinder to such objections is simple. It is almost always cheaper, faster, and easier to do things right the first time than to redo them. When the product/service is a complex system that must be installed in a larger, more complex system, it is appropriate to treat the sale like a project, which deserves the same kind of planning. A great many firms that consistently operate in an atmosphere typified by design and manufacturing crises have created their own panics. (Software producers and computer system salespeople take note!) In fairness, it is appropriate to urge that anyone meeting customers face to face should receive some training in the tactics of selling.

Project Charter Elements

PMBOK Guide 4.1

Given a project charter, approvals really amount to a series of authorizations. The PM is authorized to direct activities, spend monies (usually within preset limits), request resources and personnel, and start the project on its way. Senior management’s approval not only signals its willingness to fund and support the project, but also notifies subunits in the organization that they may commit resources to the project. The process of developing the project charter varies from organization to organization, but should contain the following elements as described in PMBOK®:

• •

PMBOK Guide Chapter 12

Purpose This is a short summary directed to top management and those unfamiliar with the project. It contains a statement of the general goals of the project and a brief explanation of their relationship to the firm’s objectives (i.e., the Business Case). The Business Case includes not only market opportunities and profit potentials but also the needs of the organization, any customer requests for proposals, technological advancement opportunities, and regulatory, environmental, and social considerations. Objectives This contains a more detailed statement of the general goals of the project, what constitutes success, and how the project will be terminated. The statement should include profit and competitive aims from the Business Case as well as technical goals based on the Statement of Work (SOW). Overview This section describes both the managerial and the technical approaches to the work. The technical discussion describes the relationship of the project to available technologies. For example, it might note that this project is an extension of work done by the company for an earlier project. The subsection on the managerial approach takes note of any deviation from routine procedure—for instance, the use of subcontractors for some parts of the work. Schedules This section outlines the various schedules and lists all milestone events and/or phase-gates. Each summary (major) task is listed, with the estimated time obtained from those who will do the work. The projected baseline schedule is constructed from these inputs. The responsible person or department head should sign off on the final, agreed-on schedule. Resources There are three primary aspects to this section. The first is the budget. Both capital and expense requirements are detailed by task, which makes this a project budget, with one-time costs separated from recurring project costs. Second, is a complete list and description of all contractual items such as customer-supplied resources, liaison arrangements, project review and cancellation procedures, proprietary requirements, purchasing/procurement contracts (knowledge area 9 in PMBOK), any specific management agreements (e.g., use of subcontractors), as well as the technical

6.1

INITIAL PROJECT COORDINATION AND THE PROJECT CHARTER

229

deliverables and their specifications, delivery schedules, and a specific procedure for changing any of the above. Third, are the cost monitoring and control procedures. In addition to the usual routine elements, the monitoring and control procedures must also include any special resource requirements for the project such as special machines, test equipment, laboratory usage or construction, logistics, field facilities, and special materials. Personnel This section lists the expected personnel requirements of the project, especially the project manager and the sponsor/approver of the project. In addition, any special skill requirements, training needed, possible recruiting problems, legal or policy restrictions on work force composition, and security clearances, should be noted here. It is helpful to time-phase personnel needs to the project schedule, if possible. This makes clear when the various types of contributors are needed and in what numbers. These projections are an important element of the budget, so the personnel, schedule, and resources sections can be cross-checked with one another to ensure consistency. Risk Management Plans This covers potential problems as well as potential lucky breaks that could affect the project. One or more issues such as subcontractor default, unexpected technical break-throughs, strikes, hurricanes, new markets for the technology, and sudden moves by a competitor are certain to occur—the only uncertainties are which, when, and their impact. In fact, the timing of these disasters and benefits is not random since there are definite times in every project when progress depends on subcontractors, the weather, or timely technical successes. Plans to deal with favorable or unfavorable contingencies should be developed early in the project’s life. No amount of planning can definitively solve a potential crisis, but preplanning may avert or mitigate some. As Zwikael et al. (2007) report, in high-risk projects better project planning improved success on four measures: schedule overrun, cost overrun, technical performance, and customer satisfaction. They conclude that improving the project plan is a more effective risk management approach than using the usual risk management tools. Evaluation Methods Every project should be evaluated against standards and by methods established at the project’s inception, allowing for both the direct and ancillary goals of the project, as described in Chapter 1. This section contains a brief description of the procedures to be followed in monitoring, collecting, storing, auditing, and evaluating the project, as well as in the post-project (“lessons learned”) evaluation following project termination.

These are the elements that constitute the project charter and are the basis for more detailed planning of the budgets, schedules, work plan, and general management of the project. Once this project charter is fully developed and approved, it is disseminated to all interested parties. Before proceeding, we should reiterate that this formal planning process just described is required for relatively large projects that cannot be classified as “routine” for the organization. The time, effort, and cost of the planning process is not justified for routine projects such as most plant maintenance projects. Admittedly, no two routine maintenance projects are identical, but they do tend to be quite similar. It is useful to have a generic plan for such projects, but it is meant to serve as a template that can easily be modified to fit the specific routine project at hand.

230

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

Project Management in Practice Facebook Risks Interruption to Move a Terabyte

Working on the bleeding edge of innovation is standard procedure for Facebook. To do so however, speed is critical to their operation, and the combination of speed and innovation brings with it high risk. But Facebook is used to handling risk. For example, a recent project involved a multimillion dollar effort to move a terabyte of data from a near-capacity data center to a new, higher-capacity data warehouse by the end of the year, only a hundred days away, at the time. A terabyte (that is, a trillion bytes, or a million megabytes) is equivalent to 250 billion “Likes” on Facebook—a lot of data! The project involved two phases: building and outfitting the new warehouse, and then transferring the data. The new data warehouse was designed so the servers could handle four times as much data

as the current ones, and the processors and software were upgraded as well, with the result that the new data warehouse could hold eight times more data and move and manage it more efficiently, all of which represented a savings of millions of dollars in energy costs. Given the short timeline and the importance of the hardware and software working together without a hitch, the project team took many steps to reduce the risks. First, they set clear expectations with both the vendors and internal stakeholders up front so everyone could fit their objectives into those of Facebook’s. Also, they conducted round-the-clock testing of the hardware, the software, and the ability of both to work together to deliver the speed, volume, and accuracy Facebook was depending on.

6.1

INITIAL PROJECT COORDINATION AND THE PROJECT CHARTER

To transfer the data to the new warehouse, they had a choice between loading the data onto the equipment before physically moving it to the warehouse (but risking lost or damaged equipment in the move), versus moving and checking the equipment first, and then flowing the data directly to the new site (but risking a network outage or a site crash disrupting their entire website). They took the risk of the latter, but planned multiple risk avoidance steps. First they had to calculate how long it would take to flow the terabyte of data, assuming no network failures or power outages—three weeks! But there was still a risk that the data flow

231

would use too much network capacity and affect the website. To avoid this, the team built a customer application to throttle the data by limiting and monitoring the bandwidth throughout the entire 3-week data flow. They also performed constant error-checking and data-level corrections to keep the flow synchronized, and alert the team if problems arose. Their up-front detailed planning, constant monitoring, and risk avoidance measures paid off in a successful data move to the new warehouse, on time with no delays or downtime. Source: S. F. Gale, “A Closer Look,” PM Network, Vol. 24.

Project Planning in Action Project plans are usually constructed by listing the sequence of activities required to carry the project from start to completion. Not only is this a natural way to think about a project; it also helps the planner decide the necessary sequence of things—a necessary consideration for determining the project schedule and duration. In a fascinating paper, Aaron and his colleagues (1993) describe the planning process used at a telecommunications firm. Using a planning process oriented around the life-cycle events common for software and hardware product developers, they divide the project into nine segments:

• • • • • • • • •

Concept evaluation Requirements identification Design Implementation Test Integration Validation Customer test and evaluation Operations and maintenance

Each segment is made up of activities and milestones (significant events). As the project passes through each of the segments, it is subjected to a series of “quality gates” (also known as “phase gates,” “toll gates,” etc.) that must be successfully passed before proceeding to the next segment. Note that the planning process must pass through the quality gates as well as the physical output of the project itself. For example, the requirements identification segment must meet the appropriate quality standards before the design segment can be started, just as design must be approved before implementation can begin. Beginning in Chapter 1, we have argued that quality should be an inherent part of the project’s specification/deliverables. The approach taken by Aaron et al. (1993) is a direct embodiment of our position. Indeed, it “goes us one better,” by applying quality standards to the process of managing the project as well as to the project’s deliverables.

232

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

6.2

STARTING THE PROJECT PLAN: THE WBS

PMBOK Guide 4.2

In this and the following sections of this chapter, and in Chapters 7 and 8 on budgeting and scheduling, we move into the details of (and some tools for) developing the project plan, essentially an elaboration of the elements of the project charter. As PMBOK® points out, the project charter is one of the major inputs to the project plan. We need to know exactly what is to be done, by whom, and when. All activities required to complete the project must be precisely delineated and coordinated. The necessary resources must be available when and where they are needed, and in the correct amounts. Some activities must be done sequentially, but some may be done simultaneously. If a large project is to come in on time and within cost, a great many things must happen when and how they are supposed to happen. Yet each of these details is uncertain and thus each must be subjected to risk management. In this section, we propose a conceptually simple method to assist in sorting out and planning all this detail. It is a hierarchical planning system—a method of constructing a work breakdown structure (WBS). To accomplish any specific project, a number of major activities must be undertaken and completed. Make a list of these activities in the general order in which they would occur. This is Level 1. A reasonable number of activities at this level might be anywhere between 2 and 20. (There is nothing sacred about these limits. Two is the minimum possible breakdown, and 20 is about the largest number of interrelated items that can be comfortably sorted and scheduled at a given level of aggregation.) Now break each of these Level l items into 2 to 20 tasks. This is Level 2. In the same way, break each Level 2 task into 2 to 20 subtasks. This is Level 3. Proceed in this way until the detailed tasks at a level are so well understood that there is no reason to continue with the work breakdown; this will usually be at the individual worker level. It is important to be sure that all items in the list are at roughly the same level of task generality. In writing a book, for example, the various chapters tend to be at the same level of generality, but individual chapters are divided into finer detail. Indeed, subdivisions of a chapter may be divided into finer detail still. It is difficult to overstate the significance of this simple dictum. It is central to the preparation of most of the planning documents that will be described in this chapter and those that follow. The logic behind this simple rule is persuasive. We have observed both students and professionals in the process of planning. We noted that people who lack experience in planning tend to write down what they perceive to be the first activity in a sequence of activities, begin to break it down into components, take the first of these, break it further, until they have reached a level of detail they feel is sufficient. They then take the second step and proceed similarly. If they have a good understanding of a basic activity, the breakdown into detail is handled well. If they are not expert, the breakdown lacks detail and tends to be inadequate. Further, we noted that integration of the various basic activities was poor. An artist of our acquaintance explained: When creating a drawing, the artist sketches in the main lines of a scene, and then builds up the detail little by little over the entire drawing. In this way, the drawing has a “unity.” One cannot achieve this unity by drawing one part of the scene in high detail, then moving to another part of the scene and detailing it. He asked a young student to make a pen-and-ink sketch of a fellow student. Her progress at three successive stages of her drawing is shown in Figure 6-1. This illustrates the “hierarchical planning process.” The PM will probably generate the most basic level (Level 1) and possibly the next level as well. Unless the project is quite small, the generation of additional levels will be delegated to the individuals or groups who have responsibility for doing the work. Maintaining the “hierarchical planning” discipline

6.2

STARTING THE PROJECT PLAN: THE WBS

233

Figure 6-1 Hierarchical planning.

will help keep the plan focused on the project’s deliverables rather than on the work at a subsystem level. Some project deliverables may be time sensitive in that they may be subject to alteration at a later date when certain information becomes available. A political campaign is an example of such a project. A speech may be rewritten in whole or in part to deal with recently released data about the national economy, for instance. This describes a planning process that must be reactive to information or demands that change over time. This type of process is sometimes called “rolling wave planning.” Nevertheless, the overall structure of the reactive planning process still should be hierarchical. Sometimes a problem arises because some managers tend to think of outcomes when planning and others think of specific tasks (activities). Many mix the two. The problem is to develop a list of both activities and outcomes that represents an exhaustive, nonredundant set of results to be accomplished (outcomes) and the work to be done (activities) in order to complete the project. In this hierarchical planning system, the objectives are taken from the project charter. This aids the planner in identifying the set of required activities for the objectives to be met, a critical part of the project plan. Each activity has an outcome (event) associated with it, and these activities and events are decomposed into subactivities and subevents, which, in turn, are subdivided again.

234

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

Figure 6-2

A form to assist hierarchical planning.

Assume, for example, that we have a project whose purpose is to acquire and install a large copy machine in a hospital records department. In the hierarchy of work to be accomplished for the installation part of the project, we might find such tasks as “Develop a plan for preparation of the floor site” and “Develop a plan to maintain records during the installation and test period.” These tasks are two of a larger set of jobs to be done. The task “. . . preparation of the floor site” is subdivided into its elemental parts, including such items as “Get specifics on copy machine mounting points,” “Check construction specifications on plant floor,” and “Present final plan for floor preparation for approval.” A form that may help to organize this information is shown in Figure 6-2. (Additional information about each element of the project will be added to the form later when budgeting and scheduling are discussed.)

The Work Breakdown Structure (WBS)

PMBOK Guide 5.3

Using this hierarchical planning process results in a work breakdown structure known as a WBS. The WBS is the main tool for managing the project scope as described in PMBOK®. The WBS is not one thing. It can take a wide variety of forms that, in turn, serve a wide variety of purposes. In many ways, the WBS is a simplified form of the project plan focused on the actual tasks of the project. It often shows the organizational elements associated with a project subdivided into hierarchical units of tasks, subtasks, work packages, etc. Figure 6-3 is such a WBS for a conference. The Food group in the Facilities staff has responsibility for meals and drinks, including coffee breaks and water pitchers in the conference rooms. Five different food functions are shown, each presumably broken down into more detailed tasks. In this case, the account numbers for each task are shown so that proper charges can be assigned for each piece of work done on the project. Professor Andrew Vazsonyi has called this type of diagram a Gozinto chart, after the famous Italian mathematician Prof. Zepartzat Gozinto (of Vazsonyi’s invention). Readers will recognize the parallel to the basic organizational chart depicting the formal structure of an organization, or the Bill of Materials in a Materials Requirements Planning (MRP) system.

6.2

235

STARTING THE PROJECT PLAN: THE WBS

Levels Conference (10.00.00)

Location (11.00.00)

Sites (11.01.00)

Dates (11.02.00)

Entertainment (13.00.00)

Facilities (12.00.00)

Equip. (12.01.00)

Food (12.02.00)

Building (12.03.00)

Types

Timer & Rates

Coffee breaks (12.02.01)

Sessions (14.00.00)

Papers

Panels

Staffing (15.00.00)

Home office

Local

1

2

3

Breakfasts (12.02.02)

Lunches (12.02.03)

Dinners (12.02.04)

Drinks (12.02.05)

Figure 6-3 Work breakdown structure (account numbers shown).

Another form of the WBS is an outline with the top organizational (Level 1) tasks on the left and successive levels appropriately indented. Most current project management software will generate a WBS on command. Microsoft’s Project®, for example, links the indented activity levels with a Gantt chart that visually shows the activity durations at any level. In general, the WBS is an important document and can be tailored for use in a number of different ways. It may illustrate how each piece of the project contributes to the whole in terms of performance, responsibility, budget, and schedule. It may, if the PM wishes, list the vendors or subcontractors associated with specific tasks. It may be used to document that all parties have signed off on their various commitments to the project. It may note detailed specifications for any work package, establish account numbers, specify hardware/software to be used, and identify resource needs. It may serve as the basis for making cost estimates or estimates of task duration. Largely, the WBS is a planning tool but it may also be used as an aid in monitoring and controlling projects. Again, it is important to remember that no single WBS contains all of the elements described and any given WBS should be designed with specific uses in mind. Its uses are limited only by the needs of the project and the imagination of the PM. No one version of the WBS will suit all needs, so the WBS is not a document, but any given WBS is simply one of many possible documents. However, in constructing the WBS, all work package information should be reviewed with the individuals or organizations who have responsibility for doing or supporting the work in order to verify the WBS’s accuracy. Resource requirements, schedules, and subtask relationships can now be aggregated to form the next higher level of the WBS, continuing on

236

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

to each succeeding level of the hierarchy. At the uppermost level, we have a summary of the project, its budget, and an estimate of the duration of each work element. For the moment, we are ignoring uncertainty in estimating the budget and duration of work elements. As we noted, the actual form the WBS takes is not sacrosanct. Figure 6-4 shows a partial WBS for a college “Career Day” which includes the activities, who is responsible, the time each task is expected to take, which tasks must precede each task, and any external resources needed for that task. However, not all elements of the WBS shown in Figure 6-4 may be needed in other cases. In some cases, for example, the amounts of specific resources required may not be relevant. In others, “due dates” may be substituted for activity durations. The appearance of a WBS will probably differ in different organizations. In some plans, numbers may be used to identify activities; in others, letters. In still others, combinations of letters and numbers may be used. An example of a WBS to acquire a subsidiary is illustrated in WBS Career Day Steps 1. Contact Organizations a. Print forms b. Contact organizations c. Collect display information d. Gather college particulars e. Print programs f. Print participants' certificates

Responsibility

Time (weeks)

Secretary Program manager Office manager Secretary Secretary Graduate assistant

6 15 4 4 6 8

l.a l.b l.b l.d -

2. Banquet and Refreshments a. Select guest speaker b. Organize food c. Organize liquor d. Organize refreshments

Program manager Program manager Director Graduate assistant

14 3 10 7

l.b l.b l.b

3. Publicity and Promotion a. Send invitations b. Organize gift certificates c. Arrange banner d. Contact faculty e. Advertise in college paper f. Class announcements g. Organize posters

Graduate assistant Graduate assistant Graduate assistant Program manager Secretary Graduate assistant Secretary

2 5l5 5 1.5 5 1 43

l.d l.d l.d 3.d l.d

Print shop Word processing Newspaper Registrar's office Print shop

4. Facilities a. Arrange facility for event b. Transport materials

Program manager Office manager

25 .5

1 .c 4.a

Movers

Figure 6-4

Partial WBS for college “Career Day.”

Prec.

Resources Print shop Word processing

Print shop Print Shop

Caterer Dept. of Liquor Control Purchasing

Word processing

6.2

STARTING THE PROJECT PLAN: THE WBS

237

Figures 6-5a and 6-5b. A verbal “WBS” was written in the form of a memorandum, Figure 6-5a, and was followed by the more common, tabular plan shown in Figure 6-5b. Only one page of a five-page plan is shown. The individuals and groups mentioned developed similar plans at a greater level of detail. (Names have been changed at the request of the firm.) Occasionally, planners attempt to plan by using “Gantt charts,” a network device commonly used to display project schedules (see Figure 6-6). The Gantt chart was invented as a scheduling aid. In essence, the project’s activities are shown on a horizontal bar chart with the horizontal bar lengths proportional to the activity durations. The activity bars are connected to predecessor and successor activities with arrows. The project schedule integrates the many different schedules relevant to the various parts of the project. It is comprehensive and may include contractual commitments, key interfaces and sequencing, milestone events, and progress reports. In addition, a time contingency reserve for unforeseeable delays might be MEMO To allow Ajax to operate like a department of Instat,, we must do the following by the dates indicated. September 24 Ajax Management to be advised of coming under Instat operation. The Instat sales department will begin selling Ajax Consumer Division production effective Jan. 1,1996. There will be two sales groups: (1) Instat, (2) Ajax Builder Group.

November 5 Instat regional managers at Ajax for sales training session.

October 15 Instat Regional Managers advised—Instat sales department to assume sales responsibility for Ajax products to distribution channels, Jan. 1, 1996.

November 30 Data Processing (Morrie Reddish) and Mfg. Engineering (Sam Newfield): Request DP tapes from Bob Cawley, Ajax, for conversion of Ajax to Instat eng. records: master inventory file, structure bill of materials file, where-used file, crossreference Instat to Ajax part numbers, etc. Allow maximum two weeks until December 14, 1995, for tapes to be at Instat.

October 15 file, Ajax regional managers advised of sales changes effective Jan. 1,1996. October 15 Instat Management, Bob Carl, Van Baker, and Val Walters visit Ajax management and plant. Discuss how operations will merge into Instat. October 22 Ajax regional managers advise Ajax sales personnel and agents of change effective Jan. 1,1996. October 24 Brent Sharp and Ken Roadway visit Instat to coordinate changeover. October 29 Instat regional managers begin interviewing Ajax sales personnel for possible positions in Instat's sales organization. Figure 6-5a

November 26 Walters visits Ajax to obtain more information.

December 3 ADMINISTRATIVE (Val Walters): Offer Norwood warehouse for sublease. December 3 SALES (Abbott and Crutchfield): Week of sales meeting . . . Instruction of salespeople in Ajax line . . . including procedure in writing Ajax orders on separate forms from Instat orders... temporarily, adding weight and shipping information, and procedure below: Crutchfield to write procedure regarding transmission of orders to Instat, credit check, and transmission of order information to shipping point, whether Norwood, San Francisco, or, later, Instat Cincinnati.

Partial WBS for merger of Ajax Hardware into Instat Corp (page 1 of 5).

238

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

WBS Objective: Merger of Ajax Hardware into Instat Corp. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

Steps Ajax management advised of changes Begin preparing Instat sales dept. to sell Ajax Consumer Division products effective 1/1/96 Prepare to create two sales groups: (1) Instat, (2) Ajax Builder Group effective 1/1/96 Advise Instat regional managers of sales division changes Advise Ajax regional managers of sales division changes Visit Ajax management and plan to discuss merger of operations Advise Ajax sales personnel and agents Visit Instat to coordinate changeover Interview Ajax sales personnel for possible position Sales training sessions for Ajax products Visit Ajax again Request DP tapes from Bob Cawley for conversion Offer Norwood warehouse for sublease Write order procedures Sales meeting (instruction— product line and procedures) DP tapes due for master inventory file, bill of materials, structure file

Due Date September 24

Responsibility Bob Carl, Van Baker

September 24

Bob Carl

1

September 24

Bob Carl

1

October 15

Bob Carl

2,3

October 15

Van Baker

2,3

October 15

4,5

October 22

Bob Carl, Van Baker, Val Walters Van Baker

October 24

Brent Sharp, Ken Roadway

6

October 29

Instat regional managers

7

November 5

Instat regional managers

9

November 26 November 30

Val Walters Morrie Reddish, Sam Newman Val Walters

8,10 6

Doug Crutchfleld Fred Abbott, Doug Crutchfleld Bob Cawley

10 14

December 3 December 3 December 3 December 14

Precedent —

6

11

12

Figure 6-5b Tabular partial WBS for Ajax-Instat merger based on Figure 6-5a.

included. While it is a useful device for displaying project progress, it is somewhat awkward for project planning. At this point, it might be helpful to sum up this section with a description of how the planning process actually works in many organizations. Assume that you, the PM, have been given responsibility for developing the computer software required to transmit medical X-rays from one location to another over the Internet. There are several problems that must be solved

6.2

Subproject Determine need

Task A1 Find operations that benefit most

Project Eng.

I.E.

Solicit quotations

B1

Contact vendors & review quotes

P.E.

Fin., I.E., Purch.

Write appropriation request

C1

Determine tooling costs

Tool Design

I.E.

C2

Determine labor savings

I.E.

I.E.

C3

Actual writing

P.E.

Tool Dsgn., Fin., I.E.

D1 Order robot

Purchasing

P.E.

D2 Design and order or manufacture tooling

Tool Design

Purch., Tooling

D3 Specify needed gauges and order or mfg.

Q.C.

Tool Dsgn., Purch.

E1

Install robot

Plant Layout

Millwrights

E2

Train employees

Personnel

P.E. Mfg.

E3

Runoff

Mfg.

Q.C.

Installation and startup

239

Responsible Dependent 2011 2012 Dept. Dept. J F M A M J J A S O N D J F M A M J J A S O N D Industrial

A2 Approx. size and type needed

Purchase machine tooling, and gauges

STARTING THE PROJECT PLAN: THE WBS

Legend: * Project completion Contractual commitment Planned completion ▲ Actual completion Status date Milestone planned ● Milestone achieved Planned progress Actual progress Note: As of Jan. 31, 2012, the project is one month behind schedule. This is due mainly to the delay in task C1, which was caused by the late completion of A2.

*

Figure 6-6 Project schedule displayed as a Gantt chart.

to accomplish this task. First, the X-ray image must be translated into computer language. Second, the computerized image must be transmitted and received. Third, the image must be displayed (or printed) in a way that makes it intelligible to the person who must interpret it. You have a team of four programmers and a couple of assistant programmers assigned to you. You also have a specialist in radiology assigned part-time as a medical advisor. Your first action is to meet with the programmers and medical advisor in order to arrive at the technical requirements for the project. From these requirements, the project mission statement and detailed specifications will be derived. (Note that the original statement of your “responsibility” is too vague to act as an acceptable mission statement.) The basic actions needed to achieve the technical requirements for the project are then developed by the team. For example, one technical requirement would be to develop a method of measuring the density of the image at every point on the X-ray and to represent this measurement as a numerical input for the computer. This is the first level of the project’s WBS.

240

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

Responsibility for accomplishing the first level tasks is delegated to the project team members who are asked to develop their own WBS for each of the first level tasks. These are the second level WBS. The individual tasks listed in the second level plans are then divided further into third level WBS detailing how each second level task will be accomplished. The process continues until the lowest level tasks are perceived as “units” or “packages” of work appropriate to a single individual. Early in this section, we advised the planner to keep all items in a WBS at the same level of “generality” or detail. One reason for this is now evident. The tasks at any level of the WBS are usually monitored and controlled by the level just above. If senior managers attempt to monitor and control the highly detailed work packages several levels down, we have a classic case of micromanagement. Another reason for keeping all items in a given level of the WBS at the same level of detail is that planners have an unfortunate tendency to plan in great detail all activities they understand well, and to be dreadfully vague in planning activities they do not understand well. The result is that the detailed parts of the plan are apt to be carried out and the vague parts of the plan are apt to be given short shrift. In practice, this process is iterative. Members of the project team who are assigned responsibility for working out a second, third, or lower-level WBS generate a tentative list of tasks, resource requirements, task durations, predecessors, etc., and bring it to the delegator for discussion, amendment, and approval. This may require several amendments and take several meetings before agreement is reached. The result is that delegator and delegatee both have the same idea about what is to be done, when, and at what cost. Not uncommonly, the individuals and groups that make commitments during the process of developing the WBS actually sign-off on their commitments. The whole process involves negotiation and, of course, like any managers, delegators can micromanage their delegatees, but micromanagement will not be mistaken for negotiation—especially by the delegatees.

6.3

HUMAN RESOURCES: THE RACI MATRIX AND AGILE PROJECTS To identify the personnel needed for the project, it may be useful to create a table that shows the staff, workers, and others needed to execute each of the WBS tasks. One such approach, called an Organizational Breakdown Structure (OBS), displays the organizational units responsible for each of the various work elements in the WBS, or who must approve or be notified of progress or changes in its scope, since the WBS and OBS may well not be identical. That is, some major section of the WBS may be the responsibility of two or more departments, while for other sections of the WBS, two or more, say, may all be the responsibility of one department. Such a document can be useful for department managers to see their total responsibilities for a particular project.

The Responsibility (RACI) Matrix

PMBOK Guide 9.1.2

Another approach to identifying the human resources needed for the project is to use the RACI (Responsible, Accountable, Consult, Inform) matrix. This approach is recommended by PMBOK® in its Human Resources Management chapter. This type of chart is also known as a responsibility matrix, a linear responsibility chart, an assignment matrix, a responsibility assignment matrix, and similar such names. The matrix shows critical interfaces between units that may require special managerial coordination. With it, the PM can keep track of who must approve what, who must be notified, and other such relationships. Such a chart is illustrated in Figure 6-7. If the project is not too complex, the responsibility chart can be elaborated with additional roles (see Figure 6-8). As a final example of this tool, Figure 6-9 shows one page of

6.3

HUMAN RESOURCES: THE RACI MATRIX AND AGILE PROJECTS

Responsibility WBS Subproject Determine need Solicit quotations Write approp. request.

Project Office Task A1 A2 B1 C1 C2 C3 " " "

Project Manager A I A

Contract Admin.

I C

Field Oper.

A I

Project Eng. C R R

Industrial Eng. R C

R C I

A A R

C R

Field Manager

C

I

Vice-president

General manager

Project manager

Manager engineering

Manager software

Manager manufacturing

Manager marketing

Subprogram manager manufacturing

Subprogram manager software

Subprogram manager hardware

Subprogram manager services

" " " Legend: R Responsible C Consult I Inform A Accountable Figure 6-7 RACI matrix.

6

2

1

3

3

3

3

4

4

4

4

Define WBS

5

1

3

3

3

3

3

3

3

3

Establish hardware specs

2

3

1

4

4

4

Establish software specs

2

3

4

1

Establish interface specs

2

3

1

4

Establish project plan

4 4

4

Establish manufacturing specs

2

3

4

4

1

4

Define documentation

2

1

4

4

4

4

3

5

4

4

4

1

3

1

1

1

1

1

1

Establish market plan

5

Prepare labor estimate Prepare equipment cost estimate

3

4

4

4

4

4

4

4

4

Prepare material costs

3

1

1

1

4

4

4

4

Make program assignments

3

1

1

1

4

4

4

4

3

1

1

4

4

4

4

Establish time schedules

5

1

3

1 Actual responsibility 2 General supervision 3 Must be consulted

Figure 6-8 Simplified responsibility chart.

4 May be consulted 5 Must be notified 6 Final approval

241

242

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

1. Recommend distribution system to be used.

Mktg Officers

Mktg Officers

Mktg Officers

2. Determine provisions of salescompensation programs (e.g., commissions, subsidies, fringes).

3. Ensure cost-effectiveness testing of sales compensation programs. 4. Establish territorial strategy for our primary distribution system. 5. Determine territories for agency locations and establish priorities for starting new agencies. 6. Determine agencies in which advanced sales personnel are to operate.

ILI & IHI LOB MCs M-A Cttee VP&Agcy Dir Group LOB MC M-A Cttee VP & Agcy Dir IA LOB MC M-A Cttee VP&Agcy Dir

Compensation Task Force Compensation Task Force Compensation Task Force Compensation Task Force

Mktg, S&S & Eqty Prod Offrs Mktg, S&S & Eqty Prod Offrs Mktg, S&S & Eqty Prod Offrs Mktg, S&S & Eqty Prod Offrs

VP&Agcy Dir

Dir MP&R M-A Cttee Dir MP&R M-A Cttee

VP&Agcy Dir

Dir Ret Plnng Sls Dir Adv Sls

VP S & S

Sr VP Mktg

Sr VP Mktg

Sr VP Mktg

President

President President

Sr VP Mktg Sr VP Mktg

Sr VP Mktg

Legend: IA, ILI,IHI: Product lines LOB: Line of business MC: Management committee M-A Cttee: Marketing administration committee S&S: Sales and service MP&R: Marketing planning and research

Figure 6-9

Verbal responsibility chart.

a verbal responsibility chart developed by a firm to reorganize its distribution system. In this case, the chart takes the form of a 30-page document covering 116 major activities.

Agile project planning and management Thus far we have been discussing the traditional method for planning projects. This method has been proven to work well for most projects. There are, however, projects for which the traditional methods do not suffice, mainly because they assume that the scope of the project can be well determined and the technology of developing the scope is well understood. This is not always the case.

6.3

HUMAN RESOURCES: THE RACI MATRIX AND AGILE PROJECTS

243

From time to time we have mentioned the fact that software and IT projects have had a very high failure rate—over budget, over schedule, and delivering less than the desired output. When compared to construction projects, for example, software projects are characterized by a much higher degree of uncertainty about the exact nature of the desired output, and often by a client (user) who does not understand the complexity of the projects and lacks the knowledge to communicate fully with the project team. The result, understandably, has a high probability of client dissatisfaction with the completed project. (Much of the following description is based on Hass, 2007.) The major source of the problem appears to be the complexity of modern business organizations. They are involved in complex relationships with each other, with multiple governments and external stakeholders, with customers, with suppliers, and operate in an environment of rapid technological change and intense global competition. Their need for complex information systems is a result of the complexity in which they operate. Agile Project Management (APM) was developed to deal more effectively with this problem. It is distinguished by close and continuing contact between clients (users) and software developers, and an iterative and adaptive planning process. Project requirements are a result of client/developer interaction, and the requirements change as the interaction leads to a better understanding on both sides of the project requirements, priorities, and limitations. Agile IT project teams are typically small, located at a single site, composed of a PM, the client/end user, an IT architect, two code writers, and a business analyst in the client’s industry. Project team membership will, of course, vary with the nature of the project’s deliverables. As noted above, the group develops the project requirements and priorities. One requirement is selected, usually the highest value or priority or most complex item, and the team tackles that item. The resulting output is tested by a test case developed as the requirement is developed. The entire team collaborates in dealing with the requirements. The PM’s role is to “facilitate” rather than to “control” the process.

Project Management in Practice Using Agile to Integrate Two Gas Pipeline Systems When TransCanada acquired American Natural Resources Co. of the U.S.A., they were faced with the problem of integrating 21,000 miles of American’s natural gas pipelines with their own Canadian system within a 2-year time frame. Different pipeline regulatory procedures between the two countries meant establishing new processes and governance procedures to certify the integrity of the complete network. The project team consisted of 14 engineers and one software manager, each with their own sub-teams to integrate the pipelines. The project started with a big Gantt chart for task scheduling, but since the team wasn’t fully dedicated to this project and still had their normal responsibilities, task due dates often were not met. In addition, as the team

acquired more data, the project parameters and scope kept changing. To respond to these constant changes, the project team moved toward a more agile management process. Although they didn’t adopt all the tools of agile, they did make use of some that were especially needed for this project. For example, there were daily 15-minute sub-team “stand-ups” (less talking when no chairs), and weekly meetings with the entire project team. This gave the workers the latest information on changes, problems, manpower availability, priorities, and other information to identify and solve roadblocks. The meetings promoted the needed inter-communication to keep the project moving while adapting to the constant changes.

244

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

To track actual progress, the project manager created a high-level list of the project’s tasks and, because he could trust the skill of the senior engineering sub-task managers, then regularly updated the amount of hours left to complete each of the tasks (note: not hours put in). Such daily reporting helped the sub-teams keep their focus on the results while aware of the daily changes that might affect them. This constant updating of information came in handy when the project was thrown off schedule by a vendor delay, but the ability of the project manager to alert the project’s stakeholders far in advance was positively received. Even though the project ran late, management was nevertheless pleased to know about the problem far ahead of time and why it occurred.

The project manager here pointed out that agile is simply a way to deal with projects that are in constant flux by shortening the feedback loops and keeping everyone apprised of changes so they can coordinate their efforts. Thus, it is best for organizations working in dynamic, turbulent environments. It isn’t particularly useful on projects with standard processes for completing them (like building a new pipeline), or with a project team that has workers who are inexperienced, unskilled, or unfamiliar with each other. The team needs to be able to trust the judgment of each of its members, and be able to collaborate and coordinate with them.

Source: C. Hildebrand, “The Sweet Spot,” PM Network, Vol. 24.

6.4

INTERFACE COORDINATION THROUGH INTEGRATION MANAGEMENT

245

Given several requirements, the team deals with them one at a time, each iteration being called a “sprint” during which the client agrees to “freeze” the scope. Not uncommonly, the solution to a second or third requirement may depend on altering the solution to the first requirement. One IT consultant notes (Hunsberger, 2011) that if the client changes the requirements, “we just deliver the new requirements” and ignore the previous ones. If the client wants more, they simply expand the engagement. Although agile provides flexibility, the trade-off is a loss of efficiency. This iterative process is not only collaborative, it must also be adaptive. It is also obvious that problem-oriented team members who have the interpersonal skills needed for collaboration are a necessity. The willingness of team members to share knowledge is an essential condition for agile projects. Not incidentally, the willingness to share knowledge is also a key to success in traditionally organized projects (Chi-Cheng, 2009). A PM who attempts to control an agile project as he might control a traditional project is most certainly the wrong person for the job (Fewell, 2010). The details of conducting an agile project are available through any chapter of the PMI, and the applicability of APM is much broader than just the software/IT area; this might even be the template for the future of project management for most industries. Any project that has a high-risk technology or a rapidly changing business environment is a candidate for APM, but success requires personnel who are qualified by personality, knowledge, and a desire for the APM experience (Hildebrand, 2010).

6.4

INTERFACE COORDINATION THROUGH INTEGRATION MANAGEMENT

PMBOK Guide Chapters 4, 11

This section covers the PMBOK® knowledge area 1 concerning Project Integration Management. The most difficult aspect of implementing the plan for a complex project is the coordination and integration of the various elements of the project so that they meet their joint goals of scope, schedule, and budget in such a way that the total project meets its goals. As projects become more complex, drawing on knowledge and skills from more areas of expertise—and, thus, more subunits of the parent organization as well as more outsiders—the problem of coordinating multidisciplinary teams (MTs) becomes more troublesome. At the same time, and as a result, uncertainty is increased. As the project proceeds from its initiation through the planning and into the actual process of trying to generate the project’s deliverables, still more problems arise. One hears, “We tried to tell you that this would happen, but you didn’t pay any attention.” This, as well as less printable remarks, are what one hears when the members of an MT do not work and play well together—in other words, when the various individuals and groups working on the project are not well integrated. Rather than operating as a team, they work as separate and distinct parts, each of which has its own tasks and is not much interested in the other parts. The intricate process of coordinating the work and timing of the different groups is called integration management. The term interface coordination is used to denote the process of managing this work across multiple groups. The RACI matrix discussed earlier is a useful aid to the PM in carrying out this task. It displays the many ways the members of the project team (which, as usual, includes all of the actors involved, not forgetting the client and outside vendors) must interact and what the rights, duties, and responsibilities of each will be. Recent work on managing the interfaces focuses on the use of MTs to plan the project as well as design the products/services the project is intended to produce. There is general agreement that MT has a favorable impact on product/service design and delivery. Work by Hauptman et al. (1996, p. 161) shows that MTs have had a “favorable impact . . . on attainment of project budget goals, but achieves this without any adverse impact on quality, cost or schedule.” The process also was associated with higher levels of team job satisfaction.

246

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

Project Management in Practice Trying to Install a Wind Farm in the Middle of the North Sea

Denmark’s objective of supplying half its national power needs through wind energy by 2025 counted heavily on DONG (Dansk Olie og Naturgas) Energy’s “Horns Rev 2” 209-megawatt offshore wind farm, the largest in the world, to be located 30 kilometers (19 miles) off the western Jutland, Denmark coast in the North Sea. Over 600 people and seven suppliers, all led by 7 project managers plus a quality control manager and a commissioning manager, constituted the multidisciplinary project team for this effort. The project consisted of installing 91 turbines over a 35 square kilometer (14 square mile) area. The 50+ meter-long blades that catch the wind and turn the turbines are mounted on shafts 115 meters (377 feet) above the surface of the water. The electricity generated by the wind farm at capacity could supply 200,000 homes. Even though the point was to locate the farm where there was a strong, constant wind, this created

the major problem facing the team—the difficulty of working in these 36 kilometer winds and icy, 3 meter-high (10-foot) waves out in the rough sea. Traveling to the site could take up to three hours, and labor and supplies had to be unloaded and unpacked in the harsh weather. The difficult conditions limited the time the teams could work, and increased the risk and complexity of every decision. In addition, safety issues became top priority because the work was under such extreme conditions, and far from medical care. As a result, it was critical to eliminate errors and risks because once offshore, the team was coping with weather, logistics, and time, which increased the scale of any problems tenfold! Hence, massive attention was paid to quality planning on-shore, before heading out to sea. There was a quality plan for every key event to ensure equipment and tasks would meet requirements. Every part that

6.4

INTERFACE COORDINATION THROUGH INTEGRATION MANAGEMENT

was delivered was rigorously inspected and anything that was missing or wrong had to be corrected before being sent out to sea. And when any troubles were encountered, they were addressed immediately. In one case, a problem arose that was going to take the supplier two months to repair; through creative troubleshooting, the team came up with a plan that would combine two tasks and in the process reduce the time to two weeks. The focus on creative problem solving

247

among the multidisciplinary teams rather than placing blame allowed the project to be completed successfully. And ancillary benefits included bringing new knowledge and working practices to the company, plus enabling many members of the team to move into higher-ranking positions, including two engineers who are becoming project managers themselves. Source: S. F. Gale, “A Closer Look,” PM Network, Vol. 24.

The use of MTs in product development and planning is not without its difficulties. Successfully involving cross-functional teams in project planning requires that some structure be imposed on the planning process. The most common structure is simply to define the task of the group as having the responsibility to generate a plan to accomplish whatever is defined as the project scope. There is considerable evidence that this is not sufficient for complex projects. Using MT creates what Kalu (1993) has defined as a virtual project. In Chapter 4, we noted the high level of conflict in many virtual projects (cf. de Laat, 1994). It follows that MT tends to involve conflict. Conflict raises uncertainty and thus requires risk management. Obviously, many of the risks associated with MT involve intergroup political issues. The PM’s negotiating skill will be tested in dealing with intergroup problems, but the outcomes of MT seem to be worth the risks. At times, the risks arise when dealing with an outside group. For an interesting discussion of such issues and their impact on project scope, see Seigle (2001). Bailetti et al. (1994) attacks the problem of interface management by defining and mapping all interdependencies between various members of the project team. Because the nature of these interfaces may differ during different phases of the product/service design/production process, they map each major phase separately. The logic of this approach to structuring MT is strong. The WBS and RACI matrix are a good initial source of information on interfaces, but they do not reflect the uncertainty associated with tasks on large, complex projects. Further, they implicitly assume that interfaces are stable within and across project phases—an assumption often contrary to fact. This does not ignore the value of the WBS, PERT/CPM networks, and similar tools of longstanding use and proven value in project management. It simply uses interface maps as a source of the coordination requirement to manage the interdependencies. The fundamental structure of this approach to interface management is shown in Figure 6-10. System responsibility

Coordination structure

Work breakdown structure Proposed feedback

Event and activity based scheduling models

Conventional feedback

Changes or difficulties

Figure 6-10 Coordination structure model of project management. Source: Bailetti et al., 1994.

248

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

Managing Projects by Phases and Phase-Gates In addition to mapping the interfaces (a necessary but not sufficient condition for MT peace), the process of using MTs on complex projects must be subject to some more specific kinds of control. One of the ways to control any process is to break the overall objectives of the process into shorter term phases (or milestones) and to focus the MT on achieving the milestones, as is done in agile project management. If this is done, and if multidisciplinary cooperation and coordination can be established, the level of conflict will likely fall. At least there is evidence that if team members work cooperatively and accomplish their short-term goals, the project will manage to meet its long-term objectives; moreover, the outcome of any conflict that does arise will be creative work on the project. The project life cycle serves as a readily available way of breaking a project up into component phases, each of which has a unique, identifiable output. Cooper et al. (1993) developed such a system with careful reviews conducted at the end of each “phase” of the life cycle. A feature of this system was feedback given to the entire project each time a project review was conducted. Another attack on the same problem was tied to project quality, again, via the life cycle (Aaron et al., 1993). They created 10 phase-gates associated with milestones for a software project. To move between phases, the project had to pass a review. (They even note that in the

Project Management in Practice An Acquisition Failure Questions Recommended Practice

When the Belgian bank Fortis joined with the Royal Bank of Scotland and the Spanish Banco Santander to acquire the Dutch bank ABN Amro, the integration project involved over 6000 people and was expected to take 3-4 years to complete. The objective was to evaluate what each side brought to the table and select the best technologies through extensive communication and brainstorming. The first nine months were spent evaluating every system and project that would be affected by the merger, resulting in a portfolio of 1000 projects that needed to be accomplished. A third of the projects were IT system choices which were to be based on multiple criteria such as functionality, cost, maintainability, etc. The plan was to make the choices based on facts instead of emotions, relying on ABN Amro’s data and including them in the decision making. The biggest set of system projects involved mapping and integrating the IT systems. But ABN Amro had thousands of applications and resisted sharing their information, which led to constant conflicts, delays, and artificial obstacles. The result was that Fortis spent thousands of hours to complete even the simplest projects. The years-long project duration also hindered

progress since the longer a project takes, the more conflicts, especially cultural (that can’t be solved simply with additional resources), will arise. Eventually, the problems and delays depleted Fortis’ capital, and, exacerbated by the global credit crisis, they went bankrupt. Fortis was then sold to the French bank BNP Paribas. In contrast to Fortis’ approach, BNP set up an 18 month project to phase out all of Fortis’ systems and move Fortis’ accounts and data into their own system. They integrated the Fortis team into their own organizational structure and put their own people into the key roles—there was no discussion, just work to do. It was a top-down approach that was easier, faster, and more efficient, though it didn’t sit well with the Fortis employees. After the integration was complete, BNP refocused on rebuilding any lost morale. For example, most of the Fortis people kept their jobs, and BNP opened four global centers in Brussels (called BNP Paribas Fortis) to show their interest in strengthening the bank’s national and global presence.

Source: S. F. Gale, “A Closer Look,” PM Network, Vol. 24.

6.4

INTERFACE COORDINATION THROUGH INTEGRATION MANAGEMENT

249

early stages of the project when there is no “inspectable product,” that “ . . . managing quality on a project means managing the quality of the subprocesses that produce the delivered product.” Emphasis in the original.) While feedback is not emphasized in this system, reports on the finding of project reviews are circulated. The quality-gate process here did not allow one phase to begin until the previous phase had been successfully completed, but many of the phasegate systems allow sequential phases to overlap in an attempt to make sure that the output of one phase is satisfactory as an input to the next. Another approach that also overlaps phases is called “fast tracking,” and here the phases are run in parallel as much as possible to reduce the completion time of the project; of course, this also increases the project risk as well. (The use of the phase-gate process for project control is demonstrated in Chapter 11, Section 11.2.) There are many such interface control systems, but the ones that appear to work have two elements in common. First, they focus on relatively specific, short-term, interim outputs of a project with the reviews including the different disciplines involved with the project. Second, feedback (and feedforward) between these disciplines is emphasized. No matter what they are called, it must be made clear to all involved that cooperation between the multiple disciplines is required for success, and that all parties to the project are mutually dependent on one another. Finally, it should be stressed that phase-gate management systems were not meant as substitutes for the standard time, cost, and scope controls usually used for project management. Instead, phase-gate and similar systems are intended to create a process by which to measure project progress, to keep projects on track and aligned with the current strategy, and to keep senior management informed about the current state of projects being carried out.

250

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

6.5

PROJECT RISK MANAGEMENT

PMBOK Guide Chapter 11

This section covers the PMBOK® knowledge area 8, concerning Project Risk Management. The Project Management Institute’s (PMI) publication A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 3rd Edition, 2004, states that risk management is “the systematic process of identifying, analyzing, and responding to project risk”* and consists of six subprocesses, and as we shall see below, a seventh subprocess needs to be added.

Project Management in Practice Risk Analysis vs. Budget/Schedule Requirements in Australia

Sydney, Australia’s M5 East Tunnel was constructed under strict budgetary and schedule requirements, but given the massive traffic delays now hampering commuters, the requirements may have been excessive. Due to an inexpensive computer system with a high failure rate, the tunnel’s security cameras frequently fail, requiring the operators to close the tunnel due to inability to react to an accident, fire, or excessive pollution inside the tunnel. The tunnel was built to handle 70,000 vehicles

a day, but it now carries 100,000, so any glitch can cause immediate traffic snarls. A managerial risk analysis, including the risk of overuse, might have anticipated these problems and mandated a more reliable set of computers once the costs of failure had been included.

Source: Project Management Institute. “Polluted Progress,” PM Network, Vol. 19.

*It is important for the reader to recall that the word “risk” has two meanings. One relates to the probability that an event will occur. The other is associated with danger or threat. The proper meaning of the word is determined by the context in which it is used.

6.5

PMBOK Guide 11.2.3

PROJECT RISK MANAGEMENT

251

1. Risk Management Planning—deciding how to approach and plan the risk management activities for a project. 2. Risk Identification—determining which risks might affect the project and documenting their characteristics. 3. Qualitative Risk Analysis—performing a qualitative analysis of risks and conditions to prioritize their impacts on project objectives. 4. Quantitative Risk Analysis—estimating the probability and consequences of risks and hence the implications for project objectives. 5. Risk Response Planning—developing procedures and techniques to enhance opportunities and reduce threats to the project’s objectives. 6. Risk Monitoring and Control—monitoring residual risks, identifying new risks, executing risk reduction plans, and evaluating their effectiveness throughout the project life cycle. We add here a seventh subprocess, based on the discussion concerning the identification of risks in PMBOK®. 7. The Risk Management Register—creating a permanent register of identified risks, methods used to mitigate or resolve them, and the results of all risk management activities. We treat each subprocess in turn, including useful tools and techniques where appropriate.

1. Risk Management Planning It is never too early in the life of a project to begin managing risk. A sensible project selection decision cannot be made without knowledge of the risks associated with the project. Therefore, the risk management plan and initial risk identification must be carried out before the project can be formally selected for support. The risk management group must, therefore, be formed as soon as a potential project is identified. At first, project risks are loosely defined—focusing for the most part on externalities such as the state of technology in the fields that are important to the project, business conditions in the relevant industries, and so forth. The response to external risks is usually to track the pertinent environments and estimate the chance that the project can survive various conditions. Not until the project is in the planning stage will such risks as those associated with project technology, schedule, budget, and resource allocation begin to take shape. Because risk management often involves analytic techniques not well understood by PMs not trained in the area, some organizations put risk specialists in a project office, and these specialists staff the project’s risk management activities. For a spectacularly successful use of risk management on a major project, see Christensen et al. (2001), a story of risk management in a Danish bridge construction project. Ward (1999) describes a straightforward method for conducting PMBOK®’s six subprocesses that includes a written report on risk management, if not the creation of a risk register. Two major problems in the way that risk management is carried out by the typical organization are that (1) risk identification activities routinely fail to consider risks associated with the project’s external environment; and (2) they focus on misfortune, overlooking the risk of positive things happening.

2. Risk Identification The risks faced by a project are dependent on the technological nature of the project, as well as on the many environments (economic, cultural, etc.) in which the project exists. Indeed, the manner in which the process of risk management is conducted depends on how one or more environments impact the project. The corporate culture is one such environment.

252

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

So consider, for instance, the impact of a strong corporate “cost-cutting” emphasis on how risk managers identify project risks—they will probably focus on the project’s cost elements, such as personnel and resource allocation. (Note that this culture will carry over to the process of risk management as well—carrying out the six or seven subprocesses—not merely to the identification of risks.) The need to consider the many environments of almost any project is clear when one examines the recent articles on risk management (e.g., Champion, 2009; Taleb, 2009). It is typical to consider only the internal environment of the project, e.g., the technical and interpersonal risks, and occasionally, negative market risks for the project. Articles on risks in IT and software projects rarely go beyond such matters—Jiang et al. (2001) is an example. This is a thoughtful development of a model for generating numerical measures for IT project risks. The specific user of the IT and the institutional setting of the project are considered, but competitors, the IT market, user industries, the legal environment, and several other relevant environments are ignored. In Chapter 2 we described the use of the Delphi method (Dalkey, 1969) for finding numeric weights and criteria scores for the important factors in selecting projects for funding. The Delphi method is also useful when identifying project risks and opportunities for risk analysis models. Indeed, one of the first applications was forecasting the time period in which some specific technological capability would become available. The Delphi method is commonly used when a group must develop a consensus concerning such items as the importance of a technological risk, an estimate of cash flows, a forecast of some economic variable, and similar uncertain future conditions or events. Other such methods are “brainstorming,” “nominal group” techniques, checklists, attribute listing, and other such creativity and idea generation methods (see the website of this book for descriptions). Cause-effect (“fishbone”) diagrams (see Figure 6-11), flow charts, influence diagrams, SWOT analysis, and other operations management techniques (Meredith et al., 2010) may also be useful in identifying risk factors. The flexibility of cause-effect diagrams makes them a useful tool in many situations. For example, the outcome of “failure” of the project can be the outcome on the right side of the fishbone and then the major factors that could cause that—bad economy, performance weakness, high pricing, competing products, etc.—can be the stems that feed into this failure, and the reasons for these various factor failures can be added to the stems. Similarly, we could put the failure factor “performance weakness” as the outcome on

Staffing Shared staffing Lack of funding

Scheduling

Lack of coordination and communication

Special education Reading

Additional activities Pull-out programs

Math

State mandates

Figure 6-11

No priority for classroom instruction time

Fishbone diagram to identify potential factors

Lack of teaching time in grade 5

6.5

PROJECT RISK MANAGEMENT

253

the right and list the factors that might cause that: weak engineering, poor materials, etc. Alternatively, we might look at the “risk” that the project might be a great success, much better than we had expected, and the factors that might cause that to occur: beat competing products to the market, booming economy, exceptionally low price, and other such positive reasons.

3. Qualitative Risk Analysis The purpose of qualitative risk analysis is to prioritize the risks identified in the previous step so attention can be directed to the most important ones. The qualitative nature of this process makes it quite flexible, useful, and quick to apply; also, it can be used for both threats and opportunities. A subjective (or if available, objective) estimate of the probability of the risk occurring is needed, perhaps from a Delphi approach used with a group of experts in the risk area. The probability values need not be precise, and for that matter could just be a rank on a 1-5 scale, or even simply “low,” “medium,” or “high.” A sense of the impact of the threat or opportunity is also needed, and should consider all important objectives of the project, including cost, timing, scope, and ancillary objectives. To attain an overall measure of the impact, each objective should be scaled and weighted in importance. Then the impact of the threat on each objective can be found in a fashion similar to the “Getting Wheels” scoring model described in Chapter 2 with the result being a percentage of 100, a number from 1 to 5, or again just “low, medium, or high.” Once the probability and impact levels are found, a Risk Matrix can be constructed as in Figure 6-12. Here we just show the simplest version with nine cells corresponding to “low, medium, and high” categories, but a 1 to 5 range would have 25 cells to consider and a percentage of 100 range could be divided into as many cells as would be useful. As we see in Figure 6-12, for example, we have identified as “critical” those threats with a high value on one measure and a medium or high value on the other measure: in this case, high probability– medium impact, high on each, and medium probability–high impact. The other cells can be categorized in a similar fashion, and here we used just three categories in a symmetrical manner: “critical,” “monitor,” and “ignore.” However, for some threats it may be appropriate to use four, or perhaps just two, categories, and the cells may be categorized differently for each

3. Client changes scope

2. Can’t acquire tech knowledge

Medium

Probability

High

1. Tight schedule

4: Costs escalate

Low

5:Recession

Low

Medium

High

Impact Critical threats

Figure 6-12

Risk Matrix

Monitor threats

Ignore threats

254

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

threat. Conversely, if the Risk Matrix cell categories seem appropriate for all threats, then one matrix can be used to illustrate the distribution of all threats, as we have done in Figure 6-12 by listing the five threats (for example) in their corresponding cells. Finally, the same approach can be used for opportunities, considering the possibility of positive impacts. In this case, the matrix shows which risk opportunities are most important to focus attention on and try to bring about and which to ignore. The responses to both critical threats and critical opportunities will be discussed in Step 5.

4. Quantitative Risk Analysis A quantitative risk analysis is sometimes conducted after the qualitative risk analysis has identified the critical (and perhaps some of the “monitor”) risks facing a project. It is more precise (using more precise quantitative data) and typically more accurate, if the data are available. We include here three techniques: Failure Mode and Effect Analysis (FMEA) is a more rigorous approach to the Risk Matrix and includes an additional factor in the process, decision tree analysis using expected monetary values, and simulation. Failure Mode and Effect Analysis (FMEA) FMEA (Stamatis, 2003) is the application of a scoring model such as those used for project selection in Chapter 2. It is straightforward and extensively used, particularly in engineering, and is easily applied to risk by using six steps. 1. List the possible ways a project might fail. 2. Evaluate the severity (S) of the impact of each type of failure on a 10-point scale where “1” is “no effect” and “10” is “very severe.” 3. For each cause of failure, estimate the likelihood (L) of its occurrence on a 10-point scale where “1” is “remote” and 10 is “almost certain.” 4. Estimate the inability to detect (D) a failure associated with each cause. Using a 10-point scale, “1” means detectability is almost certain using normal monitoring/control systems and “10” means it is practically certain that failure will not be detected in time to avoid or mitigate it. 5. Find the Risk Priority Number (RPN) where RPN S L D. 6. Consider ways to reduce the S, L, and D for each cause of failure with a significantly high RPN. (We discuss this in Step 5: Risk Response Planning.) Table 6-1 illustrates the use of FMEA for the same five threats we considered in Step 4 previously, but here we use more precise data. As we see from the RPN numbers, the biggest threats are: 2. Can’t acquire tech knowledge, and 3. Client changes scope. Threat 2 has a great severity, should it occur, and threat 3 is quite likely, though the severity is much less damaging. The cost threat (4) and the recession threat (5) can probably be ignored for now since their likelihoods are so low. The tight schedule (1) will have some repercussions and is also quite likely, but we will see it coming early and can probably take steps to avoid or mitigate it. Table 6-1

A FMEA example

Threat

Severity, S

Likelihood, L

Ability to Detect, D

RPN

1. Tight schedule

6

7.5

2

90

2. Can’t acquire tech knowledge

8.5

5

4

170

3. Client changes scope

4

8

5

160

4. Costs escalate

3

2

6

36

5. Recession

4

2.5

7

70

6.5

PROJECT RISK MANAGEMENT

255

Project Management in Practice Ignoring Risk Contrasted with Recognizing Risk in Two Industries

Everyone is familiar with the U.S. oil well disaster when BP’s Deepwater Horizon oil platform blew up and sank, releasing a massive oil spill into the Gulf of Mexico. BP immediately faced public and governmental questioning about whether the accident could have been prevented, whether corners had been cut, how much oil was leaking into the Gulf, what risk management procedures were followed, and many others. Unfortunately, BP didn’t respond well and the oil disaster became a public relations disaster as well. Oil and disaster experts point out that since the Exxon Valdez oil spill in Alaska 21 years previously, there has been no improvement in pollution cleanup technology. The same booms and skimmers are being used now as they used then. Yet, it was clear that sooner or later, there would be another big spill; yet, the oil industry was completely unprepared for this certainty. Amazingly, these firms do not seem to consider even the most basic risk management techniques, like Murphy’s Law: “What can go wrong, will go wrong.” Surely, it would have been wise to use some common sense such as employing redundant

valves, testing the casings and well equipment as they went, such as the blowout preventer. Huffington Post tech blogger Philip Neches makes some interesting contrasts by describing how NASA handles such risks when they design their extremely complex spacecraft and missions. How might it fail? How likely is it to fail in this way? How serious is the failure if it does fail; is there little impact, or is it “mission critical?” A billion dollar effort, plus the lives of any astronauts, are at risk here. In contrast, BP’s mission of drilling a well 5000 feet below the surface of the sea, clearly a challenge, is still much simpler. But any oil company should know that if they choose to engage in such risky projects, they will also need a plan to recover if a spill occurs, and then handle the massive negative public relations and media attention. In the long run, it’s much easier to evaluate the risks up front, make the right decisions, and monitor and test as you go.

Source: S. F. Gale, “Crude Awakening,” PM Network, Vol. 24.

256

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

Decision Tree Analysis This tool (Meredith et al., 2002) is simple in concept and especially useful for situations where sequential events happen over time. For example, it would be appropriate for calculating the probability of getting one head and one tail in two tosses of a fair coin, or perhaps the probability of getting a head on the first toss and a tail on the second toss (which would have a different probability), or just the probability of getting a tail on the second toss. If we are only interested in probabilities, we call the tree a probability tree. But if there are some actions we are considering anywhere along the tree—before the first probability event, say, or between events—and we want to evaluate which action(s) would be best, then it is called a decision tree. Figure 6-13 illustrates such a tree (a solved one, here), but a very simple one with only one set of actions to choose from and one set of events; however, it could be extended to multiple actions and/or events, if desired, quite easily. A decision tree is created from the left, with either a decision node (a square) or a probability node (a circle) occurring first. In the example shown, we are interested in deciding whether to invest in bonds, stocks, or time deposits (at a bank, for example) for some period of time (say, a year), so there are three alternatives emanating from the decision node, each one posing some risk and opportunity depending on what the economy does in the coming year. Then there is some event that affects the returns we get; in this case we have simplified the results of the economy into three simple categories of “solid growth,” “stagnation,” or “inflation.” (Note that the probabilities of each economic outcome are identical for each decision choice because the decision we make does not affect the economy.) Under each possible outcome of the event (whose probabilities we need to be able to estimate), our decision choice will result in a different payoff, shown on the far right. Note, for example, that if we choose to invest in stocks and there is economic inflation, we will effectively lose two units of yield. To evaluate each of these outcomes and make a decision, we need a decision rule. If our rule was to “never invest in any alternative where we might lose money,” then this 2 outcome would rule out the stocks decision alternative. Another rule, if we were optimists, might be to invest in whichever alternative allows us the greatest opportunity for maximizing our payoff, in which case we would choose stocks with a maximum payoff of 15 from “solid growth.” Yield (payoffs) p1 0.5 Solid growth EMV 8.4

12

0.3 Stagnation 6

2 0.2 Inflation

3

Bonds a1

0.5 Solid growth 15

EMV 8.0

EMV 8.4

0.3 Stagnation 1

3

3 Stocks a2

0.2 Inflation

2

0.5 Solid growth

Time deposits a3

6.5 0.3 Stagnation 4 EMV = 6.5

Figure 6-13

6.5 0.2 Inflation

Decision tree based on expected monetary value (EMV).

6.5

6.5

PROJECT RISK MANAGEMENT

257

However, we normally use a different rule, called Expected Monetary Value (abbreviated EMV) because this maximizes our return over the indefinite future, that is, the long run average. The process of “solving” the decision tree is to work from the right, with the outcomes (yields, in this case), and multiply each outcome times the probability of the event resulting in that outcome, called the expected value of that outcome, and then adding up all the expected values for that event node-decision choice combination. For example, the EMV for event node 2 would be (0.5 12) (0.3 6) (0.2 3) 8.4, which we write on the tree next to its event node. When we have done this with all of the event nodes for that decision, we compare them, double strike the lesser valued decision choices, and can then choose the best alternative choice for that decision node, in this case, “Bonds.” The use of decision trees for risk analysis easily handles both threats and opportunities, as seen in the example. The tool is attractive because it visually lays out everything that may happen in the future (that is, all risks and all decision choices). The tree can be used for individual risks, if they are independent, or joint risks on the same tree. For example, in our earlier use of FMEA, we might have interdependencies between risk 2 (can’t acquire tech knowledge) and risk 3 (client changes scope). Perhaps we have a middle route to acquiring knowledge that is sufficient for the initial scope of the project, but if the client later increases the scope, this route will be inadequate. We can portray this as a decision node (alternatives to acquiring the knowledge) followed by the event node (risk) probabilities that this action will or won’t be sufficient (note that in this case, as opposed to our example above, these probabilities may differ for each decision alternative), followed by the probability the client increases the scope. Monte Carlo Simulation Like decision trees, simulation (see Meredith et al., 2002) can also handle both threats and opportunities, and sequential events as well. We start with a model; for example, “Estimated Revenues minus Estimated Costs equals Expected Profits.” The advantage of simulation is that we don’t need to divide probabilistic events into a limited number of categories. Instead, we estimate optimistic, typical, and pessimistic values for each probabilistic input, and use standard distributions for these events. We then randomly select inputs from these distributions a thousand or more times to generate a frequency distribution of outcomes. The frequency distributions thereby give us the probabilities of losing more than a certain amount of money, or making at least a certain amount, or taking longer, or shorter, than a certain amount of time to complete the project, and other such important information. We include two examples of this approach. In Chapter 7 we simulate project cash flows and inflation rates that are uncertain and thus subject the project to monetary risk. Then in Chapter 8 we simulate the task times of project activities to determine the effect on the overall project completion time and the risk probability of being late. Dealing with Project Disasters Thus far, we have focused mainly on risks that might be considered normal for any firm undertaking projects. We have dealt with these risks by using an “expected value” approach, as in the PsychoCeramic Sciences example; that is, the estimated loss (or gain) associated with a risky output times the probability that the loss (or gain) will occur. We might also compare the expected loss associated with a risk to the associated expected cost of mitigating or preventing the loss associated with the risk. If the reduction in expected loss due to risk mitigation or prevention is greater than its cost, we would invest in the risk mitigation/prevention. But what about the case when the loss is catastrophic, even potentially ruinous, though it may have a very low probability of occurring; e.g., a run on a bank; a strike at a critical supplier’s plant; a flood that shuts down a construction project; an attack by a terrorist group on a building; or the discovery that a substance in a complex drug might cause toxic side effects? In many such cases, the cost of the risk may be massive, but the likelihood that it will occur is so small that the expected cost of the disaster is much less than many smaller, more common risks

258

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

with far higher probabilities of occurring. This is typical of situations for which we purchase insurance, but what if such insurance is unavailable (usually because the pool of purchasers interested in such insurance is too small)? In the Reading: Planning for Crises in Project Management at the end of this chapter, the authors suggest four approaches for project disaster planning: risk analysis, contingency planning, developing logic charts, and tabletop exercises. An excellent book, The Resilient Enterprise (Sheffi, 2005), deals with risk management concerning many different types of disasters. The book details the methods that creative businesses have used to cope with catastrophes that struck their facilities, supply chains, customer bases, and threatened their survival. The subject is more complex than we can deal with here, but we strongly recommend the book.

5. Risk Response Planning There are four standard approaches for dealing with risk threats, and somewhat equivalently, for enhancing risk opportunities. For threats, the four are: avoid, transfer, mitigate, and accept. For opportunities they are: exploit, share, enhance, and accept. We describe the threat responses first.

Avoid The idea here is to eliminate the threat entirely. This might be accomplished by using alternative resources, or adding contingent resources, at some cost of course. If the threat is client scope creep, up-front avoidance by adding scope change procedures to the contract might avoid the threat. If the threat is cost overrun, up-front de-scoping of project objectives in agreement with the client might avoid the threat. If the threat is schedule delay, contingency planning for schedule extensions might be written into the project contract. The extreme solution, of course, is to cancel the project if the threat is too great, such as bankruptcy. Transfer Although this approach does not eliminate the threat, it does remove the project contractor from the danger of the threat. The classic approach here for monetary risk is insurance, but other approaches are also available: warranties, bonding, cost-plus contracting, etc. For nonmonetary threats such as performance, or schedule, one alternative is for the client to contract (not subcontract) with another vendor for the portions of the project that are threatened, responsibility to the client resting with the other contractor, of course. In fact, the safest approach is to let the client perform some of these portions of the project themselves. Mitigate This is a “softening” of the danger of the threat, either through reducing the likelihood it will occur, or through reducing its impact if it does occur. Ways to reduce the likelihood are to do research or testing to improve our understanding of the probability elements of the threat and then spend some effort (and money) on reducing the more probable threats. Such efforts might involve using better materials, employing more reliable sources, simplifying the processes, shifting task times to more reliable periods, and so on, all of which usually require some investment and increase costs. For reducing the impact, similar approaches can be employed such as providing backup resources, authorizing parallel efforts, including redundancy in a system, and other such approaches, which can also be expensive. Accept The risk is accepted, either because no other response is available or because the responses are deemed too costly relative to the risk threat. This might be appropriate for non-critical threats, such as those in the “ignore” category of the risk matrix. For the critical threats, the project contractor should create a “contingency plan” so that if the threat does arise, everyone knows what actions will be taken to handle the threat. This might take the form of additional monetary or human resources, but

6.5

PROJECT RISK MANAGEMENT

259

the conditions for invoking the plan should be decided in advance so there is no confusion about whether the plan should be invoked. We now consider the approaches for opportunities. Our discussion follows that for threat risks and many of the same ideas and examples discussed there can be applied here also.

• • •

Exploit The goal here is to try to increase the probability the opportunity will occur. This might be done with higher quality resources, such as equipment, materials, or human skills, again at a cost. Share This involves partnering with another party or parties who can better capture the value of the opportunity, or at least reduce the cost of exploiting the opportunity. Joint ventures and risk-sharing partnerships are good examples of this approach. Enhance Like “mitigate” above, this involves either increasing the probability the opportunity risk will occur, or increasing its impact if it does. Again, additional resources are typically required, such as increasing the quality of the resources or the number of resources to either increase the probability or the impact of the opportunity, or both. Accept Here the project firm is prepared to capitalize on the opportunity should it occur (a contingency plan), but is not willing to invest the resources to improve the probability or impact of the opportunity occurring.

6. Risk Monitoring and Control The topic of monitoring will be covered in detail in Chapter 11 and control in Chapter 12, so we defer our discussion of risk monitoring and control until we reach those chapters.

7. The Risk Management Register If the risk management system has no memory, the task of risk identification will be horrendous. But the system can have a memory—at least the individuals in the system can remember. Relying on the recollections of individuals, however, is itself “risky.” To ensure against this particular risk, the risk management system should maintain an up-to-date data register that includes, but is not restricted to, the following:

• • • • • • •

identification of all environments that may impact on the project identification of all assumptions made in the preliminary project plan that may be a source of risk for the project a list of all risks identified by the risk management group, complete with their estimated impacts on the project and estimates of their probability of occurring a complete list of all “categories” and “key words” used to categorize risks, assumptions, and environments so that all risk management groups can access past work done on risk management the details of all qualitative and quantitative estimates made on risks, on states of the project’s environment, or on project assumptions, complete with a brief description of the methods used to make such estimates minutes of all group meetings including all actions the group developed to deal with or mitigate each specific risk, including the decision to ignore a risk the actual outcomes of identified risks and, if a risk came to occur, the results of actions taken to mitigate or transfer the risk or invoke the contingency plan

260

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

PMBOK Guide 11.2, 11.6

If all this work on data collection is going to be of value to the parent organization beyond its use on the project at hand, the risk register must be available to anyone proposing to perform risk management on a project for the organization. Almost everything a risk management group does for any project should be retained in the risk register. Second, all risks must be categorized, the environments in which projects are conducted must be identified, and the methods used to deal with or mitigate them must be described. The use of multiple key words and categories is critical because risk information must be available to managers of widely varied disciplines and backgrounds. Organizations may be conducting a great many projects at any given time. If each risk management team has to start from scratch, without reference to what has been learned by previous groups, the management of risk will be extremely expensive, take a great deal of time, and will not be particularly effective. Rest assured that even with all the experience of the past readily available, mistakes will occur. If past experience is not available, the mistakes of the past will be added to those of the future. Unfortunately, the literature on project risk management rarely mentions the value of system memory. (An exception to this generalization is Royer (2000) and the latest versions of PMBOK®.) A final question remains. How well does risk management contribute to project success? In the IT industry, risk management is not associated with success, probably because it is rarely used (de Bakker et al., 2010). In those cases where it is used, with senior management support, it is influential in identifying risk. In the IT industry, however, identification rarely leads to the management of risk. In general, more attention is paid to risk identification than to responding to it or controlling it. One final warning is appropriate to users of quantitative risk analysis methods. To quantify risk via simulation or any other scientific method is a reasonable picture of reality only to the extent that the assumptions made about the input data are accurate. Even if they are, such a picture of the future is not the same as managing it. As we have said elsewhere, models do not make decisions, people do. Risks should be understood, and once understood, people must decide what to do about them. Without this last step, risk identification and analysis are useless.

SUMMARY In this chapter we initiated planning for the project in terms of identifying and addressing the tasks required for project completion. We emphasized the importance of initial coordination of all parties involved and the smooth integration of the various systems required to achieve the project objectives. Then we described some tools such as the Work Breakdown Structure (WBS), the RACI matrix, and the Gozinto chart to aid in the planning process. We also briefly investigated several methods for controlling and reducing conflict in complex projects that use multidisciplinary teams. Last, we covered the process of risk management, for both threats and opportunities. Specific points made in the chapter are these:

The preliminary work plans are important because they serve as the basis for personnel selection, budgeting, scheduling, and control.

Top management should be represented in the initial coordinating meeting where technical objectives are

established, participant responsibility is accepted, and preliminary budgets and schedules are defined.

The approval and change processes are complex and should be handled by the project manager.

Common elements of the project charter are the overview, statement of objectives/scope, general approach, contractual requirements, schedules, resources, personnel, risk management plans, and evaluation procedures.

The hierarchical approach to project planning is most appropriate and can be aided by a tree diagram of project subsets, called a Gozinto chart, and a Work Breakdown Structure (WBS). The WBS relates the details of each subtask to its task and provides the final basis for the project budget, schedule, personnel, and control.

A RACI matrix is often helpful to illustrate the relationship of personnel to project tasks and to identify where coordination is necessary.

GLOSSARY

When multifunctional terms are used to plan complex projects, their task interfaces must be integrated and coordinated. The use of milestones and phasegates throughout the project’s schedule can help with this integration process. Risk management for both threats and opportunities has become increasingly important as projects become more complex and ill-defined. The seven subprocesses involved in managing the risks include

261

helpful tools such as cause-effect diagrams, the risk matrix, FMEA, decision trees, simulation, a risk register, and a set of standard risk responses. This topic completes our discussion of project activity planning. Next, we address the subject of budgeting and look at various budgeting methods. The chapter also addresses the issues of cost estimation and its difficulty, and simulation to handle budgetary risk of both costs and revenues.

GLOSSARY Agile Project Planning An approach developed for software projects that interfaces with the customer on a short-cycle, iterative basis for constant replanning. Bill of Materials The set of physical elements required to build a product. Cause-Effect (Fishbone) Diagram A chart showing all the factors and subfactors that can lead to a particular threat or opportunity. Control Chart A graph showing how a statistic is changing over time compared to its average and selected control limits. Decision (or Probability) Tree A visual diagram showing the decision choices, event possibilities, and outcomes from the combination of both. The tree is solved by working backwards to identify the best choice. Deliverables The physical items to be delivered from a project. This typically includes reports and plans as well as physical objects. Earned Value A measure of project progress, frequently related to the planned cost of tasks accomplished. Effectiveness Achieving the objectives set beforehand; to be distinguished from efficiency, which is measured by the output realized for the input used. Engineering Change Orders Product improvements that engineering has designed after the initial product design was released. Failure Mode and Effect Analysis (FMEA) A risk assessment process that multiplies the levels of probability, impact, and inability to detect the risk to arrive at an overall risk priority number. Gozinto Chart A pictorial representation of a product that shows how the elements required to build a product fit together. Hierarchical Planning A planning approach that breaks the planning task down into the activities that must be done at each managerial level. Typically, the upper level sets the objectives for the next lower level.

Integration Management Managing the problems that tend to occur between departments and disciplines, rather than within individual departments. Materials Requirements Planning (MRP) A planning and material ordering approach based on the known or forecast final demand requirements, lead times for each fabricated or purchased item, and existing inventories of all items. Milestones Natural sub-project ending points where payments may occur, evaluations may be made, or progress may be reassessed. Phase-Gates Preplanned points during the project where progress is assessed and the project cannot resume until re-authorization has been approved. Project Charter A proposal for a project that summarizes the main aspects of the project for approval. Project Plan The nominal plan for the entire project to which deviations will be compared. RACI Matrix A table showing, for each project task, who is responsible, accountable, who can be consulted, and who needs to be informed. (Also known as a responsibility or assignment chart.) Risk Matrix A chart showing probability on one side and impact on the other where threats and opportunities can be segmented into critical, monitor, or ignore cells. Risk Register A database of risk information created by and available to project managers for their projects. Simulation A process where the structure of a situation is programmed and the probability distributions of the events are selected to give a probability distribution for the variable of interest, such as time or cost. Work Breakdown Structure (WBS) A description of all the tasks to complete a project, organized by some consistent perspective and containing a variety of information needed for that perspective. Work Statement A description of a task that defines all the work required to accomplish it, including inputs and desired outputs.

262

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

QUESTIONS Material Review Questions

1. Describe the approach of agile project management and how it differs from the normal approach. 2. Any successful project charter must contain nine key elements. List these items and briefly describe the composition of each. 3. What are the general steps for managing each work package within a specific project? 4. Describe the “hierarchical planning process” and explain why it is helpful. 5. What is shown on a RACI matrix? How is it useful to a PM? 6. What should be accomplished at the initial coordination meeting? 7. Why is it important for the functional areas to be involved in the project from the time of the original proposal?

8. What are the basic steps to design and use the Work Breakdown Structure? 9. What is the objective of interface management? 10. Contrast the Project Plan, the Project Charter, and the WBS. 11. Contrast milestones with phase-gates. 12. Describe how a risk matrix is constructed. 13. How would a decision tree be useful for a project manager? 14. Is the FMEA table more valuable than the risk matrix? Why (not)? 15. How far should the cause-effect diagram be broken down into subfactors? 16. Contrast the risk responses for threats and for opportunities.

Class Discussion Questions

17. What percentage of the total project effort do you think should be devoted to planning? Why? 18. Why do you suppose that the coordination of the various elements of the project is considered the most difficult aspect of project implementation? 19. What kinds of risk categories might be included in the project charter? 20. In what ways may the WBS be used as a key document to monitor and control a project? 21. Describe the process of subdivision of activities and events that composes the tree diagram known as the Work Breakdown Structure or Gozinto chart. Why is the input of responsible managers and workers so important an aspect of this process? 22. Why is project planning so important? 23. What are the pros and cons concerning the early participation of the various functional areas in the project plan? 24. Task 5-C is the critical, pacing task of a rush project. Fred always nitpicks anything that comes his way, slowing it down, driving up its costs, and irritating everyone concerned. Normally, Fred would be listed as “Notify” for task 5-C on the responsibility matrix, but the PM is considering “forgetting” to make that notation on the chart. Is this unethical, political, or just smart management? 25. How might we plan for risks that we cannot identify in the risk management section of the project charter?

26. Might milestones and phase-gates both occur at the same point of a project? Will the same activities be happening? 27. Why was agile project management developed? Do you think this might be the way of the future for project management? 28. Compare the advantages of risk matrices vs. FEMA tables for project management use. 29. Contrast decision trees and probability trees. How might each be used by project managers? Which would be the more valuable? 30. Could a cause-effect chart be used for two different risks at the same time? Would the end “problem” be the result of one risk or both concurrently? 31. Are the risk responses for threats or opportunities more important for project managers? Why? Beagle 2 Mars Probe a Planning Failure

32. What should the project manager have done about the challenges facing this project? 33. Are the recommendations complete? Would you add anything else? Child Support Software a Victim of Scope Creep

34. What was the source of the problem here? 35. What would you suggest to recover the project? Shanghai Unlucky with Passengers

36. Was Shanghai unlucky or was it something else?

PROBLEMS

37. Why do you think they didn’t consider the situation of the passengers? Risk Analysis vs. Budget/Schedule Requirements in Australia

38. If striving to meet schedule or budget isn’t top priority, what is? 39. What type of risk analysis approach would have been most appropriate in this situation? Using Agile to Integrate Two Gas Pipeline Systems

40. The text mentions that in an IT project, the client or a representative of the client is a member of the team. Why was that not done here? 41. What aspects of agile (APM) were and were not used here? 42. What might be the problem of using agile for a standard project, or one with standard processes? An Acquisition Failure Questions Recommended Practice

43. Do long project durations in other industries also lead to conflicts and project problems? 44. Was the difficulty in this situation due to the upset ABN Amro employees, or were there more serious project planning problems? 45. Do you agree with the “solution” exemplified by BNP? Might there be some compromise plan?

263

Ignoring Risk Contrasted with Recognizing Risk in Two Industries

46. What do you think are the reasons BP took such a relaxed attitude toward the Gulf well compared to NASA? 47. Why hasn’t the oil industry funded research and technology for oil spill cleanup efforts, do you think? 48. Why didn’t a billion dollar firm have a public relations department prepared for the contingency of a massive oil spill? 49. Compare NASA’s approach with risk analysis as described in the chapter. Then with FMEA. What’s the same? What’s different? Facebook Risks Interruption to Move a Terabyte

50. Would you consider the completion of the first hardware phase a milestone or a phase-gate review? 51. What type of risk responses did Facebook use? 52. What other approaches might Facebook have used to handle the risks? (Hint: consider the seven risk sub-processes.) Trying to Install a Wind Farm in the Middle of the North Sea

53. Contrast the difficulties and risks of this project with those of NASA in the “Ignoring Risk . . .” PMIP sidebar. 54. How important was it to have just the right competencies and dependabilities on the multidisciplinary teams? 55. Relate the detail of their “quality planning for each key event” to what you might expect their WBS looked like.

PROBLEMS 1. Top administrators in a university hospital have approved a project to improve the efficiency of the pharmaceutical services department by the end of the fiscal year to satisfy new state regulations for the coming year. However, they are concerned about four potential threats: (1) The cost to implement the changes may be excessive, (2) The pharmacists may resist the changes, (3) The project may run much longer than expected and not be ready for the coming fiscal year, (4) The changes might reduce the quality of drug care in the hospital. The likelihood and negative impact of each threat have been solicited from the managers by a three-round Delphi process and are as follows, based on a seven-point scale where seven is the most likely and most negative impact:

Threat

Probability

Impact

1

5

3

2

6

5

3

3

4

4

4

7

Construct a risk matrix and identify what you would consider to be the “critical,” “monitor,” and “ignore” threats. Explain your reasoning. Recommend and justify a risk response for each threat. 2. The project manager for the project in Problem 1 has estimated the probabilities of not detecting the risks in time to react to them as follows, again on a seven-point

264

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

scale: Threat 1: 4, Threat 2: 1, Threat 3: 3, Threat 4: 6. Construct a FMEA table to determine which risks are now the “critical,” “monitor,” and “ignore” threats. How have they changed from Problem 1? Why? Does this new ranking seem more realistic? 3. Assume you are in a degree program in college and are concerned about getting your degree. Create a fishbone (cause–effect) diagram, with “failure to get degree” as the problem outcome. Identify at least four possible threat risks for this problem to occur. Then for each threat list at least three reasons/factors for how that threat could conceivably come to pass. Finally, review your diagram to estimate probabilities and impacts of each threat to getting your degree. Based on this analysis, what threats and factors should you direct your attention to, as the project manager of your project to get your degree. 4. The yearly demand for a seasonal, profitable item follows the distribution below:

Demand (units)

Probability

1,000

.20

2,000

.30

3,000

.40

4,000

.10

A manufacturer is considering launching a project to produce this item and could produce it by one of three methods: a. Use existing tools at a cost of $6 per unit. b. Buy cheap, special equipment for $1,000. The value of the equipment at the end of the year (salvage value) is zero. The cost would be reduced to $3 per unit. c. Buy high-quality, special equipment for $10,000 that can be depreciated over four years (one fourth of the cost each year). The cost with this equipment would be only $2 per unit. Set up this project as a decision tree to find whether the manufacturer should approve this project, and if so, which method of production to use to maximize profit. Hint: Compare total annual costs. Assume production must meet all demand; each unit demanded and sold means more profit. 5. Given the decision tree below for a two-stage (decision) project to enter a joint venture, find the best alternatives (among a1-a6 in the figure) and their expected values. The outcomes shown are revenues and the investment expenses are in parentheses. Node 4 represents the situation where alternative a1 was chosen, and then the top outcome with a 70% probability occurred; note that there is no choice of alternative if the 30% probability outcome occurred. Similarly with Node 5.

a3 3,000 0.7 a1 (500)

4 a4

2 0.3

1,000

2,000 0.2

1

500 0.4

5

0.3 0.5

a2 (1,000)

1,000 3,500

3 a5 0.6

3,000

6 a6

4,000

INCIDENTS FOR DISCUSSION

6. Medidata Inc. has identified three risk opportunities for their new medical database project. One is an opportunity to extend the database to include doctors as well as hospitals. This has a probability of a 3 and an impact on their profitability of a 3 on a 1–5 scale, where higher numbers are greater values of probability and profitability. Another is the opportunity to extend the database to other countries, particularly in Europe. For this, the probability is ranked only a 2 but the

265

profitability impact is considered to be 4 but to the higher social interest by European governments. Last, they might be able to interest nonusers such as pharmaceutical firms in using, or perhaps buying, their data. Here the probability is more certain, a 4, but the profitability would be only a 2. Construct an opportunity risk matrix, identify the “critical,” “monitor,” and “ignore” opportunities, and recommend risk responses for each opportunity.

INCIDENTS FOR DISCUSSION Ringold’s Pool and Patio Supply

John Ringold, Jr., just graduated from a local university with a degree in industrial management and joined his father’s company as executive vice-president of operations. Dad wants to break John in slowly and has decided to see how he can do on a project that John Sr. has never had time to investigate. Twenty percent of the company’s sales are derived from the sale of above-ground swimming pool kits. Ringold’s does not install the pools. John Sr. has asked John Jr. to determine whether or not they should get into that business. John Jr. has decided that the easiest way to impress Dad and get the project done is personally to estimate the cost to the company of setting up a pool and then call some competitors and see how much they charge. That will show whether or not it is profitable. John Jr. remembered a method called the work breakdown structure (WBS) that he thought might serve as a useful tool to estimate costs. Also, the use of such a tool could be passed along to the site supervisor to help evaluate the performance of work crews. John Jr.’s WBS is shown in Table A. The total cost John Jr. calculated was $185.00, based on 12.33 labor-hours at $15.00/labor-hour. John Jr. found that, on average, Ringold’s competitors charged $229.00 to install a similar pool. John Jr. thought he had a winner. He called his father and made an appointment to present his findings the next morning. Since he had never assembled a pool himself, he decided to increase the budget by 10 percent, “just in case.” Questions: Is John Jr.’s WBS projection reasonable? What aspects of the decision will John Sr. consider? Stacee Laboratories

Stacee Labs, the research subsidiary of Stacee Pharmaceuticals, Inc., has a long history of successful research and development of medical drugs. The work is conducted by standalone project teams of scientists that operate with little

Table A

Pool Installation WBS

in the way of schedules, budgets, and precisely predefined objectives. The parent company’s management felt that scientific research teams should not be encumbered with bureaucratic record-keeping chores, and their work should go where their inspiration takes them. A Special Committee of Stacee Pharm’s Board of Directors has completed a study of Stacee Labs and has found that its projects required a significantly longer time to complete than the industry average and, as a result, were significantly more expensive. These projects often lasted 10–15 years before the drug could be released to the market. At the same time, Stacee Labs projects had a very high success rate.

266

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

The board called in a management consultant, Ms. Millie Tasha, and asked her to investigate the research organization briefly and report to the board on ways in which the projects could be completed sooner and at lower expense. The board emphasized that it was not seeking nit-picking, cost-cutting, or time-saving recommendations that might lower the quality of Stacee Labs’s results. Ms. Tasha returned after several weeks of interviews with the lab’s researchers as well as with senior representatives of the parent firm’s Marketing, Finance, Government Relations, and Drug Efficacy Test Divisions, as well as the Toxicity Test Department. Her report to the Board began with the observation that lab scientists avoided contact with Marketing and Governmental Relations until they had accomplished most of their work on a specific drug family. When asked why they waited so long to involve marketing, they responded that they did not know what specific products they would recommend for sale until they had completed and tested the results of their work. They added that marketing was always trying to interfere with drug design and wanted them to make exaggerated claims or to design drugs based on sales potential rather than on good science. Ms. Tasha also noted that lab scientists did not contact the toxicity or efficacy testing groups until scientific work

was completed and they had a drug to test. This resulted in long delays because the testing groups were usually occupied with other matters and could not handle the tests promptly. It usually took many months to organize and begin both toxicity and efficacy testing. In Ms. Tasha’s opinion, the only way to make significant cuts in the time and cost required for drug research projects was to form an integrated team composed of representatives of all the groups who had a major role to play in each drug project and to have them involved from the beginning of the project. All parties could then follow progress with drug development and be prepared to make timely contributions to the projects. If this were done, long delays and their associated costs would be significantly reduced. Questions: Do you think Millie Tasha is right? If so, how should new drug projects be planned and organized? If Stacee Pharmaceutical goes ahead with a reorganization of lab projects, what are the potential problems? How would you deal with them? Could scope creep become more of a problem with the new integrated teams? If so, how should it be controlled?

CONTINUING INTEGRATIVE CLASS PROJECT It is now time to plan the project tasks and make assignments. First, create a work breakdown structure and a RACI matrix for the project. Identify any milestones and phase-gates. Evaluate

the risks using the seven subprocesses and any appropriate tools. Make sure everyone is aware of their role in the project, their specific deadlines, and the available resources.

BIBLIOGRAPHY Aaron, J. M., C. P. Bratta, and D. P. Smith. “Achieving Total Project Control Using the Quality Gate Method.” Proceedings of the Annual Symposium of the Project Management Institute, San Diego, October 4, 1993. Antonioni, D. “Post-Planning Review Prevents Poor Project Performance.” PM Network, October 1997. Bailetti, A. J., J. R. Callahan, and P. Di-Pietro. “A Coordination Structure Approach to the Management of Projects.” IEEE Transactions on Engineering Management, November 1994. Bigelow, D. “Planning Is Important—Why Don’t We Do More of It?” PM Network, July 1998.

Champion, D. “Managing Risk in the New World.” Harvard Business Review, October 2009. Chi-Cheng, H. “Knowledge Sharing and Group Cohesiveness on Performance: An Empirical Study of Technology R&D Teams in Taiwan.” Technovation, November 2009. Christensen, P. J., and Rydberg, J. “Overcoming Obstacles.” PM Network, November 2001. Cooper, R.G., and E. J. Kleinschmidt, “Stage-Gate Systems for New Product Success,” Marketing Management, Vol. 1, No. 4, 1993.

BIBLIOGRAPHY

Dalkey, N. C. The Delphi Method: An Experimental Study of Group Opinion (RM-5888-PR). Santa Monica, CA: The Rand Corporation, June 1969. de Bakker, K., A. Boonstra, and H. Wortmann, “Does Risk Management Contribute to IT Project Success? A MetaAnalysis of Empirical Evidence.” International Journal of Project Management. Vol. 28, No. 5, 2010. de Laat, P. B. “Matrix Management of Projects and Power Struggles: A Case Study of an R & D Laboratory.” IEEE Engineering Management Review, Winter 1995, reprinted from Human Relations, Vol. 47, No. 9, 1994. Fewell, J., “Led Astray.” PM Network, October 2010. Ford, R. C., and F. S. McLaughlin. “Successful Project Teams: A Study of MIS Managers.” IEEE Transactions on Engineering Management, November 1992. Hass, K. B. “The Blending of Traditional and Agile Project Management.” PM World Today, May 2007. Hauptman, O., and K. K. Hirji. “The Influence of Process Concurrency on Project Outcomes in Product Development: An Empirical Study of Cross-Functional Teams.” IEEE Transactions on Engineering Management, May 1996. Hildebrand, C. “Agile.” PM Network. August 2010. Hubbard, D. G. “Work Structuring,” in P. C. Dinsmore, ed., The AMA Handbook of Project Management. New York: AMACOM, 1993. Hunsberger, K. “Change Is Good.” PM Network. February 2011. Jiang, J. J., and G. Klein. “Software Project Risks and Development Focus.” Project Management Journal, March 2001. Kalu, T. Ch. U. “A Framework for the Management of Projects in Complex Organizations.” IEEE Transactions on Engineering Management, May 1993. Knutson, J. “How to Manage a Project Launch Meeting.” PM Network, July 1995. Langley, A. “Between ‘Paralysis by Analysis’ and ‘Extinction by Instinct.’ ” IEEE Engineering Management Review, Fall 1995, reprinted from Sloan Management Review, Spring 1995.

267

Martin, P. K., and K. Tate. “Kick Off the Smart Way.” PM Network. October 1998. Martinez, E. V. “Executives to Project Manager: Get a Plan.” PM Network, October 1994. Meredith, J. R., S. M. Shafer, and E. Turban. Quantitative Business Modeling. Cincinnati, OH: Southwestern, 2002. Meredith, J. R. and S. M. Shafer. Operations Management for MBAs. Hoboken, NJ: Wiley, 2010. Morris, W. T. Implementation Strategies for Industrial Engineers. Columbus, OH: Grid, 1979. Paley, A. I. “Value Engineering and Project Management: Achieving Cost Optimization,” in P. C. Dinsmore, ed., The AMA Handbook of Project Management. New York: AMACOM, 1993. Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3rd ed., Newtown Square, PA: Project Management Institute, 2004. Royer, P. S. “Risk Management: The Undiscovered Dimension of Project Management.” PM Network, September 2000. An extended version of this article appears in Project Management Journal, March 2000. Seigle, G. “Government Projects: Expect the Unexpected.” PM Network, November 2001. Sheffi, Y. The Resilient Enterprise. Cambridge, MA: MIT Press, 2005. Stamatis, D. H. Failure Mode and Effect Analysis: FMEA from Theory to Execution, 2nd ed. ASQ Quality Press, 2003. Taleb, N. N., D. G. Goldstein, and M. W. Spitznagel. “The Six Mistakes Executives Make in Risk Management.” Harvard Business Review, October 2009. Ward, S. “Requirements for an Effective Project Risk Management Process.” Project Management Journal, September 1999. Whitten, N. “Do Not Make Long-Term Project Commitments.” PM Network, February 2002. Zwikael, O., and A. Sadeh. “Planning Effort as an Effective Risk Management Tool,” Journal of Operations Management, Vol. 25, pp. 755–767, 2007.

The following case illustrates the development of a project planning, management, and control system for large capital engineering projects. Senior management’s goal in developing the system was primarily financial, in terms of keeping projects from exceeding budget and optimally allocate increasingly scarce investment funds. It is interesting to compare this system to that of Hewlett-Packard in the reading in Chapter 2.

268

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

C

A

S

E

HEUBLEIN: PROJECT MANAGEMENT AND CONTROL SYSTEM* Herbert F. Spirer and A. G. Hulvey Introduction Heublein, Inc., develops, manufactures, and markets consumer food and beverage products domestically and internationally. Their Group sales revenues are shown in Figure 1. The four major Groups use different manufacturing plants, equipment, and processes to produce their products. In the Spirits Group, large, continuous process bottling plants are the rule; in the Food Service and Franchising Group, small fast food restaurants are the “manufacturing plants.” The amount of spending for capital projects and support varies greatly among the Groups, as would be expected from the differences in the magnitude of sales revenues. The engineering departments of the Groups have responsibility for operational planning and control of capital projects, a common feature of the Groups. However, the differences among the Groups are reflected in differences in the sizes of the engineering departments and their support services. Similarly, financial tracking support varies from full external support to self-maintained records. Prior to the implementation of the Project Management and Control System (PM&C) described in this

Figure 1

Heublein, Inc.

*Copyright H. F. Spirer. Reprinted with permission.

paper, the capital project process was chiefly concerned with the financial justification of the projects, as shown in Figure 2. Highlights include:

• •

A focus on cost-benefit analysis. Minimal emphasis on execution of the projects; no mechanism to assure that non-financial results were achieved.

The following factors focused attention on the execution weaknesses of the process:

• •

Some major projects went over budget. The need for optimal utilization of capital funds intensified since depreciation legislation was not keeping pace with the inflationary rise in costs.

Responding to these factors, Heublein’s corporate management called for a program to improve execution of capital projects by implementing PM&C. Responsibility for this program was placed with the Corporate Facilities and Manufacturing Planning Department, which, in addition to reviewing all Capital Appropriation Requests, provided technical consulting services to the corporation.

CASE

Group recognizes need or opportunity

I

Group prepares a Capital Appropriation Request— primarily cost/benefit analysis

Having the key staff in place, ground rules were established as follows:

I

Group management reviews, approves/disapproves

I

Corporate Finance Department reviews, approves/disapproves

I

Corporate Facilities and Manufacturing Planning reviews, approves/disapproves

I

Corporate Management reviews, approves/disapproves

I I Group reports status monthly to Corporate I If significant cost variance occurs, Group prepares Group starts project

Capital Appropriation Revision and process repeated from step 3 \ Project completed Figure 2

Capital project progress prior to PM&C.

Feasibility Study Lacking specialized expertise in project management, the Director of Corporate Facilities and Manufacturing Planning decided to use a consultant in the field. Interviewing of three consultants was undertaken to select one who had the requisite knowledge, compatibility with the style and goals of the firm, and the ability to communicate to all levels and types of managers. The latter requirement was important because of the diversity of the engineering department structures and personnel involved. The first author was selected as the consultant. With the consultant selected, an internal program manager for PM&C was selected. The deferral of this choice until after selection of the consultant was deliberate, to allow for development of interest and enthusiasm among candidates for this position and so that both the selected individual and the selection committee would have a clear picture of the nature of the program. A program manager was chosen from the corporate staff (the second author).

269

The PM&C program would be developed internally to tailor it to the specific needs of the Groups. A “canned” or packaged system would limit this flexibility, which was deemed essential in this application of project management principles. The directors of the engineering departments of each of the Groups were to be directly involved in both the design and implementation of the PM&C system in total and for their particular Group. This would assure the commitment to its success that derives from ownership and guarantees that those who know the needs best determine the nature of the system.

To meet the above two ground rules, a thorough fundamental education in the basic principles of project management would be given to all involved in the system design. The emphasis was to be project planning as opposed to project control. The purpose of PM&C was to achieve better performance on projects, not catch mistakes after they have occurred. Success was the goal, rather than accountability or identification of responsibility for failure. Program Design The option of defining a uniform PM&C system, to be imposed on all engineering departments by corporate mandate, was rejected. The diversity of projects put the weight in favor of individual systems, provided planning and control was such that success of the projects was facilitated. The advantage to corporate staff of uniform planning and reporting was given second place to accommodation of the unique needs of each Group and the wholehearted commitment of each engineering manager to the effective use of the adopted system. Thus, a phased implementation of PM&C within Heublein was planned in advance. These phases were: Phase I. Educational overview for engineering department managers. A three-day seminar with two toplevel educational objectives: (1) comprehension by participants of a maximal set of project management principles and (2) explanation of the corporate objectives and recommended approach for any PM&C system. Phase II. PM&C system design. A “gestation period” of three weeks was deliberately introduced between

270

CHAPTER 6 / PROJECT ACTIVITY AND RISK PLANNING

Phases I and II to allow for absorption, discussion, and review of the project management principles and objectives by the engineering department managers. At the end of this period a session was called for the explicit purpose of defining the system. The session was chaired by the consultant, a deliberate choice to achieve the “lightning rod” effect whereby any negative concern was directed to an outsider. Also, the consultant—as an outsider—could criticize and comment in ways that should not be done by the engineering department managers who will have long-term working relationships among each other. It was agreed in advance that a consensus would be sought to the greatest possible extent, avoiding any votes on how to handle particular issues which leaves the “nay” votes feeling that their interests have been overridden by the majority. If consensus could not be achieved, then the issue would be sidestepped to be deferred for later consideration; if sufficiently important, then a joint solution could be developed outside the session without the pressure of a fixed closing time. Phase III. Project plan development. The output of Phase II (the set of consensus conclusions) represented both guidelines and specific conclusions concerning the nature of a PM&C system. Recognizing that the PM&C program will be viewed as a model project and that it should be used as such, serving as an example of what is desired, the program manager prepared a project plan for the PM&C program. The remainder of this paper is primarily concerned with the discussion of this plan, both as an example of how to introduce a PM&C system and how to make a project plan. The plan discussed in this paper and illustrated in Figures 3 to 11 is the type of plan that is now required before any capital project may be submitted to the approval process at Heublein. Phase IV. Implementation. With the plan developed in Phase III approved, it was possible to move ahead with implementation. Implementation was in accordance with the plan discussed in the balance of this paper. Evaluation of the results was considered a part of this implementation.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Introduction Project Objectives Project/Program Structure Project/Program Costs Network Schedule Resource Allocation Organization and Accountability Control System Milestones or Project Subdivisions

In major or critical projects, the minimal set of choices from the menu is specified by corporate staff (the definition of a “major” or “critical” project is a part of the PM&C procedure). For “routine” projects, the choice from the menu is left to the project manager. In the PM&C plan, items 6 and 7, Schedule and Resource Allocation, were combined into one section for reasons which will be described as part of the detailed discussions of the individual sections which follow. Introduction In this PM&C system, the Introduction is an executive summary, with emphasis on the justification of the project. This can be seen from the PM&C Program Introduction shown in Figure 3. It is to the advantage of everyone concerned with a project to be fully aware of the reasons for its existence. It is as important to the technicians as it is to the engineers or the corporate financial department. When the project staff clearly comprehends the reason for the project’s existence, it is much easier to enlist and maintain their support and wholehearted efforts. In the Heublein PM&C system, it is expected that the introduction section of a project plan will include answers to these questions: What type of project is involved? What is the cost-benefit relationship? What are the contingency plans? Why is it being done this way (that is, why were alternatives rejected)? Figure 3 not only illustrates this approach, but is the executive summary for the Heublein PM&C system.

Project Plan A feature of the guidelines developed by the engineering managers in Phase II was that a “menu” of component parts of a project plan was to be established in the corporate PM&C system, and that elements of this menu were to be chosen to fit the situational or corporate tracking requirements. The menu is:

Objectives Goals for a project at Heublein must be stated in terms of deliverable items. To so state a project objective forces the definition of a clear, comprehensible, measurable, and tangible objective. Often, deliverable items resulting from a project are documents. In constructing a residence,

CASE

271

External and internal factors make it urgent to ensure most efficient use of capital funds. Implementation of a project management and control ("PM&C") system has been chosen as one way to improve the use of capital funds. In March the Corporate Management Committee defined this need. Subsequenüy, Corporate Facilities and Manufacturing Planning performed a feasibility study on this subject. A major conclusion of the study was to develop the system internally rather than use a "canned" system. An internally developed system can be tailored to the individual Groups, giving flexibility which is felt to be essential to success. Another conclusion of the study was to involve Group engineering managers in the design and implementation of the system for better understanding and acceptance. This is the detailed plan for the design and implementation of a corporate-wide PM&C System. The short-term target of the system is major capital projects; the long-term target is other types of projects, such as new product development and R&D projects. The schedule and cost are: Completion Date: 1 year from approval. Cost: $200,000, of which $60,000 is out of pocket. Figure 3 Introduction to PM&C program project plan.

is the deliverable item “the house” or is it “the certificate of occupancy”? In the planning stages of a project (which can occur during the project as well as at the beginning), asking this question is as important as getting the answer. Also, defining the project in terms of the deliverables tends to reduce the number of items which are forgotten. Thus, the Heublein PM&C concept of objectives can be seen to be similar to a “statement of work” and is not meant to encompass specifications (detailed descriptions of the attributes of a deliverable item) which can be included as appendices to the objectives of the project. Figure 4 shows the objectives stated for the Heublein PM&C program. It illustrates one of the principles set for objective statement: that they be hierarchically structured, starting with general statements and moving to increasingly more detailed particular statements. When both particular and general objectives are defined, it is imperative that there be a logical connection; the particular must be in support of the general. Project Structure Having a definition of deliverables, the project manager needs explicit structuring of the project to:

• • •

Relate the specific objectives to the general. Define the elements which comprise the deliverables. Define the activities which yield the elements and deliverables as their output.

Show the hierarchical relationship among objectives, elements, and activities.

The work breakdown structure (WBS) is the tool used to meet these needs. While the WBS may be represented in either indented (textual) or tree (graphical) formats, the graphic tree format has the advantage of easy comprehension at all levels. The tree version of the WBS also has the considerable advantage that entries may be made in the nodes (“boxes”) to indicate charge account numbers, accountable staff, etc. Figure 5 is a portion of the indented WBS for the PM&C Program, showing the nature of the WBS in general and the structure of the PM&C Program project in particular. At this point we can identify the component elements and the activities necessary to achieve them. A hierarchical numbering system was applied to the elements of the WBS, which is always a convenience. The 22 Design Phase Reports (2100 series in Figure 5) speak for themselves, but it is important to note that this WBS is the original WBS: All of these reports, analyses, and determinations were defined prior to starting the program and there were no requirements for additional items. Project Costs The WBS provides a listing of the tasks to be performed to achieve the project objectives; with only the WBS in hand it is possible to assemble a preliminary project estimate. The estimates based only on the WBS are preliminary because they reflect not only uncertainty

272

CHAPTER 6 / PROJECT ACTIVITY AND RIS