Take home exam for project Managment

profilezazabzaz
Project_Management_for_Engineering_Busin.pdf

Project Management for Engineering, Business and Technology FIFTH EDITION

Project Management for Engineering, Business and Technology, 5th edition, addresses project management across all industries. First covering the essential background, from origins and philosophy to methodology, the bulk of the book is dedicated to concepts and techniques for practical application. Coverage includes project initiation and proposals, scope and task definition, scheduling, budgeting, risk analysis, control, project selection and portfolio management, program management, project organization, and all-important “people” aspects—project leadership, team building, conflict resolution and stress management.

The Systems Development Cycle is used as a framework to discuss project management in a variety of situations, making this the go-to book for managing virtually any kind of project, program or task force. The authors focus on the ultimate purpose of project management—to unify and integrate the interests, resources, and work efforts of many stakeholders, as well as the planning, scheduling, and budgeting needed to accomplish overall project goals.

This new edition features:

• Updates throughout to cover the latest developments in project management methodologies

• New examples and 18 new case studies to help students develop their understanding and put principles into practice

• A new chapter on agile project management and lean • Expanded coverage of program management, stakeholder engagement,

buffer management, and managing virtual teams and cultural differences in international projects.

• Alignment with PMBOK terms and definitions for ease of use alongside PMI certifications

• Cross-reference to IPMA, APM, and PRINCE2 methodologies • Extensive instructor support materials, including an Instructor’s Manual,

PowerPoint slides, answers to chapter review questions, problems and cases, and a test bank of questions.

Taking a technical yet accessible approach, Project Management for Business, Engineering and Technology, 5th edition, is an ideal resource and reference for all advanced undergraduate and graduate students in project management courses as well as for practicing project managers across all industry sectors.

John Nicholas, PhD, is Professor of Operations Management at Loyola University, Chicago, USA.

Herman Steyn, PhD, is a Professor in the Graduate School of Technology Management, University of Pretoria, South Africa where he specializes in project management.

“As a Professor who has taught Project Engineering for the last 14 years, I have also performed large scale Project Engineering throughout my first career (over 20 years) in Aerospace, Defense and Information Technology. When deciding on a textbook for my graduate Project Engineering class, I looked long and hard. I wasn’t finding what I was looking for and was going to write my own, until I found Project Management for Engineering, Business and Technology. This is the textbook I would have written. It is robust, complete and easy to follow. The graphics, charts and figures are all very descriptive and real. And my students like the paperback nature of the book. I highly recommend this textbook for anyone teaching Engineering, Business or Technology Project Management/Engineering. I also recommend it as a ‘keeper’ for students who will be guiding projects in the future.”

Mark Calabrese, University of Central Florida, USA

“The publication of the 5th edition of Project Management for Engineering, Business and Technology by John Nicholas and Herman Steyn is an important milestone in a continuing conversation between the authors and the current and future practitioners of project management around the world. This book has long been a comprehensive but accessible publication that provides valuable insights into the strategic and day-today management of projects both large and small. There are numerous publications in this field but Nicholas and Steyn have found the balance between the needs of experienced practitioners looking for ways to improve project outcomes, and the needs of students who are new to the project management field. The concepts are clearly and logically laid out, and the language is appropriate for a wide range of audiences. It continues to be a benchmark in a crowded field of publications offering both practical and strategic insights into the art and craft of project management.”

Barrie Todhunter, University of Southern Queensland, Australia

“I have been using the earlier editions of this book in my Project Management teaching to working executives of a major engineering company employing close to 40000 people in various types of projects. I have evaluated the current 5th edition of the book from the perspective of (a) a teaching resource (b) study material and (c) as a resource for case studies and references. I find that the 5th edition has been thoroughly revamped and incorporates several relevant resources and is presented in a very lucid and structured way. I have absolutely no hesitation in recommending this book as a standard resource for teaching students in a university set up and/or for working executives in a project environment. The book is also a good resource as a study material for certification courses.”

Krishna Moorthy, Ex-Dean, Larsen & Toubro Institute of Project Management, India

“Project Management for Engineering, Business and Technology is one of the most comprehensive textbooks in the field. Nicholas and Steyn explain the matter in a readable and easy-to-understand way, illustrated with interesting examples. The authors combine the ‘hard matter’ of project management with relevant behavioural aspects. Overall, a useful work for anyone new to the field or as reference for the more advanced project manager.”

Martijn Leijten, Delft University of Technology, The Netherlands

“Project management plays a vital role in achieving project objectives. Projects bring change and project management is recognised as the most effective way to managing such change. This book encourages readers to become interested and involved in the change towards renewed project management and management of projects.”

Benita Zulch, University of the Free State, South Africa

“A very comprehensive text. An excellent mix of materials to enable students to learn techniques and engage in discussion of scenarios.”

Richard Kamm, University of Bath, UK

Project Management for Engineering, Business and Technology

FIFTH EDITION

John M. Nicholas Loyola University Chicago

Herman Steyn University of Pretoria

Fifth edition published 2017

by Routledge

2 Park Square, Milton Park, Abingdon, Oxon OX14 4RN

and by Routledge

711 Third Avenue, New York, NY 10017

Routledge is an imprint of the Taylor & Francis Group, an informa business

© 2017 John Nicholas and Herman Steyn

The right of John Nicholas and Herman Steyn to be identified as authors of this work has been asserted by

them in accordance with sections 77 and 78 of the Copyright, Designs and Patents Act 1988.

All rights reserved. No part of this book may be reprinted or reproduced or utilised in any form or by any

electronic, mechanical, or other means, now known or hereafter invented, including photocopying and

recording, or in any information storage or retrieval system, without permission in writing from the

publishers.

Trademark notice: Product or corporate names may be trademarks or registered trademarks, and are used

only for identification and explanation without intent to infringe.

Fourth edition published by Routledge 2012

Third edition published by Elsevier Inc. 2008

British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library

Library of Congress Cataloging in Publication Data

A catalog record for this book has been requested

ISBN: 978-1-138-93735-2 (hbk)

ISBN: 978-1-138-93734-5 (pbk)

ISBN: 978-1-315-67631-9 (ebk)

Typeset in Joanna by Servis Filmsetting Ltd, Stockport, Cheshire

Visit the companion website: www.routledge.com/cw/nicholas

To Sharry, Julia, Joshua, and Abigail J.M.N.

To Karen and Janine H.S.

Brief Contents

Introduction

PART I: PHILOSOPHY AND CONCEPTS 1 What Is Project Management? 2 Systems Approach

PART II: PROJECT LIFE CYCLE 3 Project Life Cycle and Project Conception 4 Project Definition and System Definition

PART III: SYSTEMS AND PROCEDURES FOR PLANNING AND CONTROL 5 Basic Project Planning Techniques 6 Project Schedule Planning and Networks 7 Advanced Project Network Analysis and Scheduling 8 Cost Estimating and Budgeting 9 Project Quality Management 10 Project Risk Management 11 Project Execution, Monitoring, and Control 12 Project Evaluation, Communication, Implementation, and Closeout 13 Agile Project Management and Lean

PART IV: ORGANIZATION BEHAVIOR 14 Project Organization Structure and Integration 15 Project Roles and Stakeholders 16 Managing Participation, Teamwork, and Conflict

PART V: PROJECT MANAGEMENT IN THE CORPORATE CONTEXT 17 Meta-Management of Projects and Program Management

18 Project Selection and Portfolio Management 19 International Project Management

Appendix A: RFP for Midwest Parcel Distribution Company Appendix B: Proposal for Logistical Online System Project (LOGON) Appendix C: Project Evaluation Plan for Logistical Online System

Index

Contents

Cover Title Copyright Dedication Brief Contents Contents Preface Acknowledgements About the Authors Introduction

I.1 In the Beginning… I.2 What Is a Project? I.3 All Projects are Not the Same I.4 Project Management: The Need I.5 Project Goal: Time, Cost, and Performance I.6 Project Management: The Person, The Team, The Methodology I.7 Project Management Standards of Knowledge and Competencies I.8 About This Book I.9 Study Project Appendix: Relation Between Professional Standards and Chapters of This Book Review Questions Case I.1 The Denver Airport Questions About the Case

Endnotes

PART I: PHILOSOPHY AND CONCEPTS

1 What Is Project Management?

1.1 Functions of Management 1.2 Features of Project Management 1.3 Evolution of Project Management 1.4 Where is Project Management Appropriate? 1.5 Management by Project: A Common Approach 1.6 Different Forms of Project-Related Management 1.7 Project Environments 1.8 New Product and Systems Development Projects 1.9 Construction Projects 1.10 Service-Sector Projects 1.11 Public-Sector and Governmental Projects and Programs 1.12 Miscellaneous Projects 1.13 Summary Review Questions Questions About the Study Project Case 1.1 Disaster Recovery at Marshall Field’s Case 1.2 Flexible Benefits System Implementation at Shah Alam Medical Center Endnotes

2 Systems Approach

2.1 Systems and Systems Thinking 2.2 Systems Concepts and Principles 2.3 Systems Approach 2.4 Systems Engineering 2.5 Project Management: A Systems Approach 2.6 Summary

Review Questions Questions About the Study Project Case 2.1 Glades County Sanitary District Case 2.2 Life and Death of an Aircraft Development Project Case 2.3 Jubilee Line Extension Project Case 2.4 Santa Clara County Traffic Operations System and Signal Coordination Project Endnotes

PART II: PROJECT LIFE CYCLE

3 Project Life Cycle and Project Conception

3.1 Project Life Cycle 3.2 Systems Development Cycle 3.3 Phase A: Conception 3.4 Project Feasibility 3.5 The Project Proposal 3.6 Project Contracting 3.7 Summary Appendix: Kinds of Contracts Review Questions Questions About the Study Project Case 3.1 West Coast University Medical Center Case 3.2 X-Philes Data Management Corporation: RFP Matters Case 3.3 Proposal Evaluation for Apollo Spacecraft Case 3.4 Contract Mess-Up at Polanski Developers Endnotes

4 Project Definition and System Definition

4.1 Phase B: Definition 4.2 Project Definition

4.3 Phased (Rolling Wave) Project Planning 4.4 System Definition 4.5 Summary Appendix A: Stages of Systems Engineering Appendix B: Quality Function Deployment Review Questions Questions About the Study Project Case 4.1 Star-Board Construction and Santaro Associates: Requirements Snafu Case 4.2 Revcon Products and Welbar, Inc.: Client– Contractor Communication Case 4.3 Lavasoft.com: Interpreting Customer Requirements Case 4.4 Proposed Gold Mine in Canada: Phased Project Planning Endnotes

PART III: SYSTEMS AND PROCEDURES FOR PLANNING AND CONTROL

5 Basic Project Planning Techniques

5.1 Planning Steps 5.2 The Project Execution Plan 5.3 Scope and Statement of Work 5.4 Work Definition 5.5 Project Organization and Responsibilities 5.6 Scheduling 5.7 Planning and Scheduling Charts 5.8 Line of Balance (Linear Scheduling Method) 5.9 Procurement Management 5.10 Summary Review Questions Questions About the Study Project Case 5.1 Barrage Construction Company: Sean’s WBS

Case 5.2 Startrek Enterprises, Inc.: Deva’s Project Plan Case 5.3 Walter’s Project Plan Case 5.4 Planning the Boca Implementation at Kulczyński Products Endnotes

6 Project Schedule Planning and Networks

6.1 Network Diagrams 6.2 The Critical Path 6.3 Converting to Gantt Calendar Schedules 6.4 Management Schedule Reserve 6.5 Alternative Relationships 6.6 Scheduling with Resource Constraints 6.7 Criticisms of Network Methods 6.8 Summary Appendix A: AOA Diagrams Appendix B: Alternate Scheduling Method: Project Starts at Day 1 Review Questions and Problems Questions About the Study Project Case 6.1 Network Diagram for a Large Construction Project Case 6.2 Melbourne Construction Company, A Case 6.3 Melbourne Construction Company, B Case 6.4 Melbourne Construction Company, C Endnotes

7 Advanced Project Network Analysis and Scheduling

7.1 CPM and Time-Cost Tradeoff 7.2 Variability of Activity Duration 7.3 PERT 7.4 Allocating Resources and Multiple Project Scheduling

7.5 Theory of Constraints and Critical Chain Method 7.6 TOC Method for Allocating Resources to Multiple Projects 7.7 Discussion and Summary Summary List of Symbols Review Questions and Problems Questions About the Study Project Case 7.1 Bridgecon Contractors Case 7.2 LOGON Project Case 7.3 Papua Petera Village Project Endnotes

8 Cost Estimating and Budgeting

8.1 Cost Estimates 8.2 Cost Escalation 8.3 Cost Estimating and the Systems Development Cycle 8.4 Cost Estimating Process 8.5 Elements of Estimates and Budgets 8.6 Project Cost Accounting Systems 8.7 Budgeting Using Control (or Cost) Accounts 8.8 Cost Summaries 8.9 Cost Schedules and Forecasts 8.10 Life Cycle Costs 8.11 Summary Review Questions and Problems Questions About the Study Project Case 8.1 Life Cycle Costs for Fleet of Tourist Spaceships Case 8.2 Estimated Costs for the Chunnel Project Case 8.3 Fiona’s Estimate for the Gorgy Project Case 8.4 Melbourne Construction Company, D Endnotes

9 Project Quality Management

9.1 The Concept of Quality 9.2 Project Quality Management Processes 9.3 Techniques for Quality Assurance in System Development 9.4 Techniques for Quality Control 9.5 Summary Review Questions Questions About the Study Project Case 9.1 Ceiling Panel Collapse in the Big Dig Project Case 9.2 FIFA 2010 World Cup South Africa Case 9.3 Airbag Adversity Endnotes

10 Project Risk Management

10.1 Risk Concepts 10.2 Risk Identification 10.3 Risk Assessment 10.4 Risk Response Planning 10.5 Risk Monitoring and Response 10.6 Project Management Is Risk Management 10.7 Summary Appendix: Risk Analysis Methods Review Questions and Problems Questions About the Study Project Case 10.1 The Sydney Opera House Case 10.2 Infinity & Beyond, Inc. Case 10.3 The Nelson Mandela Bridge Endnotes

11 Project Execution, Monitoring, and Control

11.1 Phase C: Execution

11.2 Detail Design Stage 11.3 Production/Build Stage 11.4 Monitoring and Control Process 11.5 Work Packages and Control Accounts 11.6 Project Monitoring and Control Emphasis 11.7 Performance Analysis and Earned Value Management 11.8 Issue Management 11.9 Change Control 11.10 Contract Administration 11.11 Problems with Monitoring and Controlling Projects 11.12 Summary Summary of Variables Review Questions and Problems Questions About the Study Project Case 11.1 Cybersonic Project Case 11.2 SA Gold Mine: Earned Value After a Scope Change Case 11.3 Change Control Process at Dynacom Company Endnotes

12 Project Evaluation, Communication, Implementation, and Closeout

12.1 Project Evaluation 12.2 Project Communication Management 12.3 Project Management Information Systems 12.4 Informal Communication 12.5 Implementation Stage 12.6 Project Termination and Closeout 12.7 Project Summary Evaluation 12.8 After the Project—Phase D: Operation 12.9 Summary

Review Questions Questions About the Study Project Case 12.1 Status Report for the LOGON Project Case 12.2 SLU Information Central Building Case 12.3 Formal and Informal Communication Endnotes

13 Agile Project Management and Lean

13.1 Traditional Project Management 13.2 Agile Project Management, APM 13.3 Scrum 13.4 APM Controversy 13.5 Lean Production and Project Management 13.6 Summary Review Questions Questions about the Study Project Case 13.1 Grand Entry for Accent, Inc. Case 13.2 Technology to Track Stolen Vehicles Endnotes

PART IV: ORGANIZATION BEHAVIOR

14 Project Organization Structure and Integration

14.1 Formal Organization Structure 14.2 Organizational Design by Differentiation and Integration 14.3 Requirements of Project Organizations 14.4 Integration of Subunits in Projects 14.5 Liaison Roles, Task Forces, and Teams 14.6 Project Expeditors and Coordinators 14.7 Pure Project Organizations 14.8 Matrix Organizations 14.9 Selecting an Organization Form for Projects

14.10 Project Office and PMO 14.11 Integration in Large-Scale Projects 14.12 Integration in Systems Development Projects 14.13 Concurrent Engineering 14.14 Summary Review Questions Questions about the Study Project Case 14.1 Organization for the LOGON Project Case 14.2 Pinhole Camera and Optics, Inc.: Why Do We Need a Project Manager? Case 14.3 Implementing a Matrix Structure in an R&D Laboratory Endnotes

15 Project Roles and Stakeholders

15.1 The Project Manager 15.2 Project Management Authority 15.3 Project Manager Qualifications 15.4 Filling the Project Management Role 15.5 Roles in the Project Team 15.6 Roles Outside the Project Team 15.7 Project Stakeholder Engagement 15.8 Summary Review Questions Questions About the Study Project Case 15.1 The LOGON Project Case 15.2 Selecting a Project Manager at Nuwave Products Company Case 15.3 Stakeholders in Boston’s Big Dig Endnotes

16 Managing Participation, Teamwork, and Conflict

16.1 Leadership in Project Management

16.2 Participative Management 16.3 Teams in Project Management 16.4 The Team-Building Approach 16.5 Improving Ongoing Work Teams 16.6 Building New Teams 16.7 Intergroup Problem Solving 16.8 Virtual Teams 16.9 Conflict 16.10 Managing Group Conflict 16.11 Managing Emotional Stress 16.12 Summary Review Questions Questions About the Study Project Case 16.1 Wilma Keith Case 16.2 Mars Climate Orbiter Spacecraft Endnotes

PART V: PROJECT MANAGEMENT IN THE CORPORATE CONTEXT

17 Meta-Management of Projects and Program Management

17.1 Project Management Maturity and Maturity Models 17.2 Project Management Methodology 17.3 Managing Project Knowledge 17.4 Project Management Office 17.5 Program Management 17.6 Program Phases 17.7 Program Management Themes 17.8 Program Organization 17.9 Special Considerations 17.10 Summary Review Questions Questions About the Study Project

Case 17.1 Maxim Corporation America (MCA) Case 17.2 Motorola’s M-Gate Methodology and the RAZR Project Case 17.3 Tecknokrat Company Case 17.4 Mercury Exploration Program Endnotes

18 Project Selection and Portfolio Management

18.1 Project Portfolio Management 18.2 Framework for Project Selection and Portfolio Management 18.3 Methods for Assessing Individual Projects 18.4 Methods for Comparing and Selecting Projects 18.5 Integrating the Gating Process and Portfolio Management 18.6 Summary and Discussion Review Questions and Problems Question About the Study Project Case 18.1 Consolidated Energy Company Case 18.2 Proposed Cement Factory for PCS Company Endnotes

19 International Project Management

19.1 International Projects 19.2 Problems Managing International Projects 19.3 Local Institutions and Culture 19.4 Local Stakeholders 19.5 Geo-National Issues 19.6 Project Manager 19.7 Local Representative 19.8 Top Management, Steering Committee, and PMO 19.9 Team and Relationship Building 19.10 Project Definition

19.11 Project Monitoring 19.12 Communication 19.13 Risks and Contingencies 19.14 Summary Review Questions Questions About the Study Project Case 19.1 Mozal Project—International Investment in an Undeveloped Country Case 19.2 Spirit Electronics’ Puerto Rico Office Endnotes

APPENDIX A RFP for Midwest Parcel Distribution Company APPENDIX B Proposal for Logistical Online System Project (LOGON) APPENDIX C Project Execution Plan for Logistical Online System Index

Preface

When people see or use something impressive—a bridge arching high over a canyon, a space probe touching down on a distant planet, an animated game so realistic you think you’re there, or a nifty phone/camera/computer the size of your hand—they sometimes wonder, “How did they do that?” By they, of course, they are referring to the creators, designers, and builders, the people who created —thought up and made—those things. Seldom do they wonder about the leaders and managers, the people who organized and led the efforts that brought those astounding things from concept to reality and without whom most neat ideas would never have been achieved. This book is about them—the managers of project managers, the mostly unsung heroes of engineering, business, and technology who stand outside the public eye but ultimately are responsible for practically everything that requires collective human effort.

The project manager is but one of many people involved in the creation of society’s products, systems, and artifacts, yet it is he or she who gets the others involved and organizes and directs their efforts so everything comes out right. Occasionally, the manager and the creator happen to be the same: Burt Rutan, Woody Allen, and Gutzon Borglum are examples; their life work—in aerospace, motion pictures, and monumental sculptures, respectively—represent not only creative or technological genius, but leadership and managerial talent as well.

In the last several decades businesses have expanded from domestic, nationalistic enterprises and markets into multinational, global enterprises and markets. As a result, from a business perspective there is more of everything to contend with—more ideas, competitors, resources, constraints, and, certainly, more people doing and wanting things. Technology is advancing and products and processes evolving at a more rapid pace; as a result, the life cycles of most things in society are getting shorter. This “more of everything” has had a direct impact on the conduct of projects—including projects to develop products,

systems, or processes that compete in local, domestic, and international markets; projects to create and implement new ways of meeting demand for energy, recreation, housing, communication, transportation, and food; and projects to answer basic questions in science and resolve grave problems such as disease, pollution, global warming, and the aftermath of natural disasters. All of this project activity has spurred a growing interest in improved ways to plan, organize, and guide projects to better meet the needs of customers, markets, and society within the bounds of limited time and resources.

Associated with this interest is the growing need to educate and train project managers. In the past—and still today—project managers were chosen for some demonstrated exceptional capability, although not necessarily managerial. If you were a good engineer, systems analyst, researcher, architect, or accountant, eventually you would become a project manager. Somewhere along the way, presumably, you would pick up the “other” necessary skills. The flaw in this reasoning is that project management encompasses a broad range of skills— managerial, leadership, interpersonal—that are much different from and independent of skills associated with technical competency. And there is no reason to presume that the project environment alone will provide the opportunity for someone to “pick up” these other necessary skills.

As a text and handbook, this book is about the “right” way to manage projects. It is intended for advanced undergraduate and graduate university students and practicing managers in engineering, business, and technology. As the title says, it is a book about principles and practice, meaning that the topics in it are practical and meant to be applied. It covers the big picture of project management— origins, applications, and philosophy, as well as the nitty-gritty, how-to steps. It describes the usual project management topics of schedules, budgets, and controls, but also the human side of project management, including leadership and conflict.

Why a book on project management in engineering and business and technology? In our experience, technology specialists such as engineers, programmers, architects, chemists, and so on, involved in “engineering/technology projects” often have little or no management or leadership training. This book, which includes many engineering and technology examples, provides somewhat broad exposure to business concepts and

management specifics to help these specialists get started as managers and leaders.

What about those people involved in product development, marketing, process improvement, and related projects commonly thought of as “business projects”? Just as technology specialists seldom receive formal management training, students and practitioners of business rarely get formal exposure to practices common in technology projects. For them, this book describes not only how “business” projects are conducted, but also the necessary steps in the conception and execution of engineering, system development, construction, and other “technology” projects. Of course, every technology project is also a business project: it is conducted in a business context and involves business issues such as customer satisfaction, resource utilization, deadlines, costs, and profits.

Virtually all projects—engineering, technology, and business—originate and are conducted in a similar way, in this book conceptualized using a methodology called the Systems Development Cycle (SDC). The SDC serves as a general framework for discussing the principles and practices of project management, and illustrating commonalities and differences among a wide variety of projects.

This book is an outgrowth of the authors’ combined several decades of experience teaching project management at Loyola University Chicago and University of Pretoria to business and engineering students, preceded by several years’ experience in business and technology projects, including for aircraft design and flight test, large-scale process facility construction, and software applications development and process improvement. This practical experience gave us an appreciation not only for the business-management side of project management, but also for the human-interpersonal side as well. We have seen the benefits of good communication, trust, and teamwork, as well as the costs of poor leadership, emotional stress, and group conflict. In our experience, the most successful projects are those where leadership, trust, communication, and teamwork flourished, regardless of the formal planning and control methods and systems in place. This book largely reflects these personal experiences. Of course, comprehensive coverage of project management required that we look much beyond our own experience and draw upon the published works of many others and the wisdom and suggestions of colleagues and reviewers.

In this fifth edition we have revised and added material to incorporate new

topics of interest, current examples, and the growing body of literature in project management. Among significant new additions are a chapter on agile project management and lean production, extended coverage of program management, as well as 18 new end-of-chapter case studies. The Introduction includes tables that relate sections of the book to the most-common project management knowledge areas and methodologies: PMI PMBOK, IPMA, APM, and PRINCE2. Books tend to grow in size with each new edition; to combat that all chapters have been rewritten to make everything more readable and concise. Despite the inclusion of new material, we’ve held the page count to roughly what it was in the previous edition.

Our goal in writing this book is to provide students and practicing managers the most practical, current, and interesting text possible. We appreciate hearing your comments and suggestions. Please send them to us at [email protected] and [email protected].

Acknowledgments

Like most projects, writing a book reflects the contributions of many people. We want to acknowledge and give special thanks to those who contributed the most. First, thanks to our research assistants. Research assistants in general do a lot of work—academic as well as gofer, and without their toiling efforts most professors would accomplish far less. We were fortunate to have had the assistance of several such bright and capable people, particularly Elisa Denney, Hollyce James, Diane Petrozzo, Miguel Velasco, Gaurav Monga, Cary Morgan, Louis Schwartzman, and Brian Whelan.

Special thanks to current and former colleagues at Loyola University Chicago and the University of Pretoria. In Chicago, thanks to Dr. Gezinus Hidding for his enthusiasm and contributions to the field of project management; and to Drs. Enrique Venta, Harold Dyck, Samuel Ramenofsky, and Donald Meyer, and Elaine Strnad, Paul Flugel, John Edison, Sharon Tylus, and Debbie Gillespie for their suggestions and support for this and earlier editions. In Pretoria, thanks to Dr. Tinus Pretorius for encouraging education and research in project management at the Graduate School of Technology Management and for supporting the work on this book. I (Herman) also want to express appreciation to Dr. Giel Bekker, Philip Viljoen, Dr. Taryn Bond-Barnard, Dr. Pieter Pretorius, Dr. Krige Visser, Corro van Waveren, Dr. Michael Carruthers and Dr. Marie-Louise Barry for their direct and indirect contributions to this book and for all I have learned from them. I (John) want to acknowledge the influence of three of my professors, Dr. Charles Thompson and Dr. Gustave Rath at Northwestern University, and Dr. Dick Evans at the University of Illinois, whose philosophies and teachings helped shaped this book. I also want to thank Chris Phares and Bob Zimmerman, dear friends and project managers extraordinaire, for ongoing sharing of their wisdom on the meaning and significance of project leadership.

Special thanks also to our wives Sharry and Karen. Sharry provided numerous

suggestions to the first edition and helped reduce the amount of “techno-jargon” in the book; she managed the home front and freed up time so that I (John) could pursue and complete this project. Karen provided wifely support and encouragement; as in the case of so many other projects I (Herman) have been involved in, my contribution to this project would never have materialized had not it been for her support.

Thanks also to Amy Laurens and the folks at Routledge and Taylor and Francis, and special thanks to Holly Davis for her ongoing support throughout preparation of this fifth edition.

Other colleagues, students, and friends, some mentioned in the endnotes throughout the book, provided support, encouragement, and reference materials; to them also we say thank you. Despite the assistance of so many people and our own best efforts, there are still likely to be omissions or errors. We had final say and accept responsibility for them.

John M. Nicholas

Herman Steyn

About the Authors

JOHN NICHOLAS is Professor Operations Management and Project Management in the Quinlan School of Business at Loyola University Chicago. He is an active teacher, writer, and researcher in project management and production management, and conducts executive seminars and consults on project management and process improvement. John is the author of numerous academic and technical publications, and five books including Lean Production for Competitive Advantage (2011) and The Portal to Lean Production (2006). He has held the positions of team lead and engineer on aircraft development projects at Lockheed-Martin Corporation, team lead and business systems analyst on operations projects at Bank America, and researcher on energy-environmental research projects at Argonne National Laboratory. He has a BS in aeronautical and astronautical engineering and an MBA in operations research from the University of Illinois, Urbana-Champaign, and a PhD in industrial engineering and applied behavioral science from Northwestern University.

HERMAN STEYN is Professor of Project Management in the Graduate School of Technology Management, University of Pretoria, South Africa. He has been involved in projects in industry since 1975, has managed a variety of large and small engineering projects (system, product, and process development) in the minerals, defense and nuclear industries, and has also managed programs and project portfolios. In 1996 he was appointed to his current position at the University of Pretoria where he initiated a masters’ program in project management. Besides supervising project management research and teaching graduate project management courses, Herman has conducted more than 200 seminars and workshops on project management. He has a bachelor’s degree and graduate diploma in metallurgical engineering, an MBA, and a PhD in engineering management.

Introduction

I.1 In The Beginning…

Sometime during the third millennium BC, workers on the Great Pyramid of Cheops set the last stone in place. They must have felt jubilant, for this event represented a milestone of sorts in one of humanity’s grandest undertakings. Although much of the ancient Egyptians’ technology is still a mystery, the enormity and quality of the finished product remains a marvel. Despite the lack of sophisticated machinery, they were able to raise and fit some 2,300,000 stone blocks, weighing 2 to 70 tons apiece, into a structure the height of a modern 40- story building. Each facing stone was set against the next with an accuracy of 0.04 inch (1 mm), and the base, which covers 13 acres (52,600 m2), deviates less than 1 inch (25 mm) from level (Figure I.1).1

Equally as staggering was the number of workers involved. To quarry the stones and transport them down the Nile, about 100,000 laborers were levied. In addition, 40,000 skilled masons and attendants were employed in preparing and laying the blocks and erecting or dismantling the ramps. Public works were essential to keep the working population employed and fed, and it is estimated that no less than 150,000 women and children also had to be housed and fed.2 But just as mind-boggling was the managerial ability exercised by the Egyptians throughout the 20-year duration of the pyramid construction. Francis Barber, a nineteenth-century pyramid scholar, concluded that:

It must have taken the organizational capacity of a genius to plan all the work, to lay it out, to provide for emergencies and accidents, to see that the men in the quarries, on the boats and sleds, and in the mason’s and smithies shops were all continuously and usefully employed, that the means of

transportation was ample … that the water supply was ample … and that the sick reliefs were on hand.3

Building the Great Pyramid is what we today would call a large-scale project. It stands among numerous projects from early recorded history that required massive human works and managerial competency. Worthy of note are the managerial and leadership accomplishments of Moses. The Biblical account of the exodus of the Hebrews from the bondage of the Egyptians gives some perspective on the preparation, organization, and execution of this tremendous undertaking.

Supposedly Moses did a magnificent job of personnel selection, training, organization, and delegation of authority.4 The famed ruler Solomon also was the “manager” of great projects. He transformed the battered ruins of many ancient cities and crude shantytowns into powerful fortifications. With his wealth and the help of Phoenician artisans, Solomon built the Temple in Jerusalem. Seven years went into the construction of the Temple, after which Solomon took 13 years more to build a palace for himself. He employed a workforce of 30,000 Israelites to fell trees and import timber from the forests of Lebanon.5 That was almost 3,000 years ago.

Figure I.1 The Great Pyramid of Cheops, an early (circa 2500BC) large-scale project.

Photo courtesy of iStock.

With later civilizations, notably the Greeks and Romans, projects requiring

extensive planning and organizing escalated. To facilitate their military campaigns and commercial interests, the Romans constructed networks of highways and roads throughout Europe, Asia Minor, Palestine, and northern Africa so that all roads would “lead to Rome.” The civilizations of Renaissance Europe and the Middle and Far East undertook river engineering, construction of aqueducts, canals, dams, locks, and port and harbor facilities. With the spread of modern religions, construction of temples, monasteries, mosques, and massive urban cathedrals was added to the list of projects.

With the advent of industrialization and electricity, projects for the construction of railroads, electrical and hydro-electrical power facilities and infrastructures, subways, and factories became commonplace. In recent times, development of large systems for communications, defense, transportation, research, and information technology have spurred different, more complex kinds of project activity.

As long as people do things, there will be projects. Many projects of the future will be similar to those in the past. Others will be different either in terms of increased scale of effort or more advanced technology. Representative of the latter are two recent projects, the English Channel tunnel (Chunnel) and the International Space Station. The Chunnel required tremendous resources and took a decade to complete. The International Space Station (Figure I.2) required development of new technologies and the efforts of the US, Russian, European, Canadian, and Japanese space agencies.

Figure I.2 The International Space Station, a modern large-scale project.

Photo courtesy of NASA.

I.2 What Is a Project?

From these examples it is clear that humankind has been involved in project activities for a long time. But why are these considered “projects” while other human activities, such as planting and harvesting a crop, stocking a warehouse, issuing payroll checks, or manufacturing a product, are not?

What is a project? This is a question we will cover in much detail later. As an introduction though, below are listed some characteristics that warrant classifying an activity as a project.6

1. A project has a defined goal—a purpose with well-defined end-items, deliverables, results, or products to achieve specific benefits.

2. It is unique; it requires doing something different than was done previously. It is a one-time activity, never to be exactly repeated again.

3. It is a temporary organization that seeks to accomplish the goal within a scheduled time frame.

4. It utilizes people and other resources from different organizations and functions.

5. Given that each project is unique, it carries unfamiliarity and risk.

The examples described earlier are for familiar kinds of projects such as construction (pyramids) and technology development (space station). In general, the list of activities that qualify as projects is long and includes many that are commonplace. Weddings, remodeling a home, and moving to another house are projects; so are company audits, major litigations, corporate relocations, and projects; and so are efforts to develop new products and implement new systems. Military campaigns also qualify as projects; they are temporary, unique efforts directed toward a specific goal. The Normandy Invasion in World War II on June 6, 1944 is an example:

The technical ingenuity and organizational skill that made the landings possible was staggering. The invasion armada included nearly 5,000 ships of all descriptions protected by another 900 warships. The

plan called for landing 150,000 troops and 1500 tanks on the Normandy coast in the first 48 hours.7

Most artistic endeavors are projects, too. Composing a song or symphony, writing a novel, or making a sculpture are one-person projects. Some artistic projects also require the skills of engineers and builders, for example Mount Rushmore, the Statue of Liberty, and the Eiffel Tower.

Many efforts at saving human life and recovering from man-made or natural disasters become projects. Examples are the massive cleanup following the Soviet nuclear accident at Chernobyl, and rescue and recovery operations following disastrous earthquakes in Chile, Haiti, China, Pakistan, Mexico, Turkey, and elsewhere, the Indian Ocean tsunami of 2004, and the Ebola outbreak in western Africa in 2014.

Figure I.3 shows diverse project endeavors and examples of well-known projects, and where the projects fall with respect to complexity and uncertainty. Complexity is measured by the magnitude of the effort—the number of groups and organizations involved and the diversity of skills or expertise needed to accomplish the work. Time and resource commitments tend to increase with complexity.

Uncertainty is measured roughly by the difficulty in predicting the final outcome in terms of the dimensions of time, cost, and technical performance. In most projects there is some uncertainty in one or two dimensions (e.g. weddings); in complex projects there is uncertainty in all three dimensions (e.g. the space station).

Generally, the more often something is done, the less uncertainty there is in doing it. This is simply because people learn by doing and so improve their efforts—the “learning curve” concept. Projects that are very similar to previous ones and about which there is abundant knowledge have lower uncertainty. These are found in the lower portion of Figure I.3 (e.g. weddings, highways, dams, system implementation). Projects with high uncertainty are in the upper portion of the figure.

When the uncertainty of a project drops to nearly zero, and when the project effort is repeated a large number of times, then the work is usually no longer considered a project. For example, building a skyscraper is definitely a project, but mass construction of prefabricated homes more closely resembles a scheduled, repetitive operation than a project. The first flight to the South Pole by Admiral Byrd was a project, but modern daily supply flights to bases there are

not. When in the future tourists begin taking chartered excursions to Mars, trips there will not be considered projects either. They will just be ordinary scheduled operations.

The cost curve in Figure I.3 indicates that a project’s expense tends to increase roughly in proportion to its complexity and uncertainty. Cost, represented in terms of time or economic value, is at the level of tens or hundreds of labor hours for projects with low complexity and uncertainty, but increases to millions and billions of hours for projects with the greatest complexity and uncertainty.

In all cases, projects are conducted by organizations that after the project is completed go on to do something else (construction companies) or are disbanded (Admiral Byrd’s crew, the Mars exploration team). In contrast, repetitive, high- certainty activities (prefabricated housing, supply flights, and tourist trips to Antarctica or Mars) are performed by permanent organizations that do the same thing repeatedly, with little changes in operations other than scheduling. Because projects are not repetitive is the reason they must be managed differently.

I.3 All Projects are Not the Same8

Besides Figure I.3, another way to illustrate the diversity in projects is with the so-called NTCP model, which classifies projects and their end-results or products into four dimensions, each with three or four possible levels. The dimensions and levels are:

• Novelty: This represents how new the project end-item or product is to customers and potential users and how well defined are its initial product requirements. It includes three levels:

Figure I.3 A typology of projects.

• Derivative—the project end-item or product is an extension or improvement of an existing product or system; e.g. new features to an existing car model;

• Platform—the end-item or product is a new generation of an existing product line in a well-established market; e.g. a new car model;

• Breakthrough—the end-item or product is new to the world; e.g. the first mobile telephone, the first 3M Post-it notes.

• Technology: This represents the project’s technological uncertainty and whether it is new or mature. It addresses the question of how much new technology is required to create, build, manufacture and enable the use of the product and how much technical competency is needed by the project manager and the team. It has four levels:

• Low-tech—involves only well-established technologies; • Medium-tech—uses mainly existing technologies, but also limited

use of some new technology or new features; e.g. automotive and appliances industries;

• High-tech—uses technologies that are mostly new to the firm but already exist and are available at project initiation; typical of many defense and computer projects; is synonymous with “high- risk”;

• Super-high-tech—relies on new technologies that do not exist at project initiation. The project goal is well defined, but the solution is not; e.g. landing a man on the moon; is often synonymous with “very high-risk.”

• Complexity: This measures the complexity of the product and the project organization. There are three levels:

• Assembly—the project involves combining a collection of elements, components, and modules into a single unit or entity that performs a single function; e.g. developing a new coffee machine or creating a department to manage a single function (such as

payroll); • System—involves a complex collection of interactive elements and

subsystems that jointly perform multiple functions to meet specific operational needs; e.g. a new car, new computer, entirely new business;

• Array—the project involves a large variety of dispersed systems (a system of systems, or “super system”) that function together to achieve a common purpose; e.g. national communications network, mass transit infrastructure, regional power generation and distribution network, an entire corporation.

• Pace: This refers to time available for the project—the urgency or criticality of meeting the project’s time goals. There are four levels:

• Regular—no urgency; time is not critical to immediate success; • Fast/competitive—complete project in adequate time to address

market opportunities, create a strategic positioning, or form a new business unit; e.g. launching a new drug, introducing a new product line;

• Time-critical—complete project by a specific deadline; missing the deadline means project failure; e.g. Y2K projects; construction of facilities for the Olympic Games; launch of space probe to a comet;

• Blitz—a crisis project; the criterion for success is solving a problem as fast as possible; e.g. save people from a sinking ship.

All projects can be characterized according to the four dimensions. In Figure I.4, each of the dimensions is represented by a quadrant on the graph. The diamond- shaped profiles show the four dimensions for two examples, the Apollo lunar program and the space shuttle program.

Figure I.4 Shenhar and Dvir’s NTCP Diamond model contrasting the Apollo and space shuttle programs.

Source: Shenhar A. and Dvir D. Reinventing Project Management: The Diamond Approach to Successful

Growth and Innovation. Cambridge, MA: Harvard Business School Press; 2007.

I.4 Project Management: The Need

Although mankind has been involved in projects since the beginning of recorded history, obviously the nature of projects and the environment have changed. Many modern projects involve technical complexity and challenges in terms of assembling and directing large temporary organizations while subject to constrained resources, limited time schedules, and environmental uncertainty. An example is the NASA Pathfinder Mission to land and operate a rover vehicle on the surface of Mars. Such a project is unparalleled not only in terms of technical difficulty and organizational complexity, but also in terms of the requirements imposed on it. In ancient times, the requirements were flexible. If the Pharaohs needed more workers, then more slaves or more of the general population were conscripted. If Renaissance builders ran out of funding during construction of a cathedral, the work was stopped until more funds could be raised (one reason why cathedrals took decades or centuries to complete). If a king ran out of money while building a palace, he simply raised taxes. In cases where additional money or workers could not be found or the project delayed, then the scale of effort or quality of workmanship was reduced to accommodate the constraints.

In the Pathfinder project, many of the requirements were inflexible: the mission team was challenged with developing and landing a vehicle on Mars in less than 3 years’ time and on a $150 million budget, which was less than half the time and 1/20th the cost of the last probe NASA had landed on Mars. The project involved advanced research and development and explored new areas of science and engineering. Technical performance requirements could not be compromised; to do so would increase the risk to undertakings that were already very risky.

Constraints and uncertainty in project work are not restricted to large-scale governmental science programs. They are common in everyday business and technology where organizations continually strive to develop and implement new products, processes, and systems, and to adapt to changing requirements in a changing world. Consider Dalian Company’s development of “Product J,” a product development project that exemplifies what companies everywhere must do to be competitive and survive. Product J is a promising but radically new idea.

To move the idea from a concept to a real product will require the involvement of engineers and technicians from several Dalian divisions and suppliers. Product J will require meeting tough technical challenges, launching the product well ahead of the competition, and doing it for a cost the company can afford.

Another example is Shah Alam Hospital’s installation of a new employee benefits plan. The project would involve developing new policies, training staff workers, familiarizing 10,000 employees with the plan, and installing a new computer network and database, and require active participation from personnel in human resources, financial service, and information systems, as well as experts from two consulting firms. It typifies “change” projects everywhere—projects initiated in response to changing needs and with the goal of transforming the organization’s way of doing things.

Finally, consider that virtually every company has or will have a website. Behind each site are multiple projects to develop or enhance the website and to integrate electronic business technology into the company’s mainstream marketing and supply-chain operations. Such projects are also examples of organizations’ need to change, in this case to keep pace with advances in information technology and business processes.

Activities such as these examples defy traditional management approaches for planning, organization, and control. They are representative of activities that require modern methods of project management to meet difficult technological or market-related performance goals in spite of limited time and resources.

I.5 Project Goal: Time, Cost, and Performance

Figure I.5 Three-dimensional project goal.

Source: Adapted from Rosenau M., Successful Project Management. Belmont, CA: Lifetime Learning

Publications; 1981, p, 16.

The goal of virtually every project can be conceptualized in terms of hitting a target that floats in three-dimensional space—the dimensions being cost, time, and performance (Figure I.5). Cost is thespecified or budgeted cost for the project. Time is the scheduled period over which the work is to be done. Performance is what the project end-item, deliverables, or final result must do; it includes whatever the project customer, end-user, and other stakeholders consider necessary or important. The target represents a goal to deliver a certain something to somebody by a certain date and for a certain cost. The purpose of project management is to hit the target—i.e., to achieve the goal of the project.9

But technological complexity, changing markets, and an uncontrollable

environment make it difficult to hit the target. Time, cost, and technical performance are interrelated, and exclusive emphasis on any one will likely undermine the others. In trying to meet schedules and performance requirements, costs increase; conversely, in trying to contain costs, work performance erodes and schedules slip. In earlier times, one or two aspects of the goal were simply allowed to slide so that the “most fixed” could be met. Most projects, as the Pathfinder, Dalian Company, and Shah Alam Hospital examples show, do not have this luxury. Project management offers a way to maintain focus on all three dimensions and to control the tradeoffs among them.

I.6 Project Management: The Person, The Team, The Methodology

Three key features distinguish project management from traditional forms of management: the person, the team, and the methodology.

The most prominent feature about project management is the role of the project manager—the individual who has overall responsibility to plan, direct, and integrate the efforts of everyone involved in the project (stakeholders) to achieve the project goal. In the role of project manager, one person is held accountable for the project and is totally dedicated to achieving its goals. The project manager coordinates the efforts of every functional area and organization in the project and oversees the planning and control of costs, schedules, and work tasks. As we will discuss later, numerous other parties (stakeholders) are involved in and crucial to project management; nonetheless, the role of project manager is a key feature that distinguishes project- from non-project management.

Doing a project is a team effort, and project management means bringing individuals and groups together to form the team and directing them toward the common goal. The team will often consist of people and groups from different functional areas and organizations. Depending on the project, the size and composition of the team may fluctuate; usually the team disbands after the project is completed.

The project manager and project team typically perform work in phases according to a “project management methodology.” This methodology provides for integrative planning and control of projects, which according to Archibald refers to

the pulling together of all important elements of information related to (1) the products or results of the project, (2) the time, and (3) the cost, in funds, manpower, or other key resources … for all (or as many as practical) phases of the project. [It] requires continual revision of future plans, comparison of actual results with plans, and projection of total time and cost at completion through interrelated evaluation of all elements of information.10

As a project proceeds from one phase to the next, the project manager relies on the methodology to (1) identify the project tasks, (2) identify the required

resources and the costs, (3) establish priorities, (4) plan and update schedules, (5) monitor and control end-item quality and performance, and (6) measure project performance.11

I.7 Project Management Standards of Knowledge and Competencies

Project management has become a recognized vocation supported by several professional organizations around the world. These organizations have advanced project management by establishing standards, guidelines, and certifications. Among the more well-known of these organizations are IPMA (International Project Management Association), APM Group (Association for Project Management), and PMI (Project Management Institute). The PMI is based in the US and is the largest of these organizations; the IPMA, based in the Netherlands, is an international group of national project management associations in Europe, Africa, Asia and North and South America; the APM is based in the UK.

These professional organizations have gathered the accepted best practices of project management and published them as standards or “bodies of knowledge” (BOKs) and competencies for the profession.12 Although none of the standards or BOKs covers everything about project management, they have become recognized norms about what minimally a project management professional should know. The organizations also offer levels of qualification and certification that include, for example, PMI’s PMP (Project Management Professional) certification; APM’s APMP (APM professional), and IPMA’s CPMA (Certified Project Management Associate). PMI’s and APM’s certifications are “body of knowledge-based”; IPMA’s certifications are “competency-based.” Another certification popular in Europe and particularly the UK is based upon PRINCE2 (PRojects IN Controlled Environments, Version 2), a methodology for managing projects originated by the UK Office of Government Commerce.13

For readers interested in professional certification, Tables I.1 through Table I.4 in the Appendix to the chapter show the correspondence between the knowledge areas, competencies expected, and methods from PMI, IPMA, APM, and PRINCE, and chapters in this book most relevant to them.

I.8 About This Book

Philosophy and Objectives

As a philosophy and an approach, project management is broader and more sophisticated than traditional management of repetitive activities. It has roots in many disciplines, including management science, systems theory, accounting, operations management, organizational design, law, and applied behavioral science. What has evolved, and will continue to evolve, are a philosophy, approach, and set of practices, the sum total of which comprise project management. Some managers fail to understand this, believing that application of techniques alone, such as “Gantt charts,” “PERT,” or “matrix management” (all explained later) make for successful project management. Project management is much more than these.

C.P. Snow wrote an essay entitled “Two Cultures” about the cultural gap that separates scientists from the rest of society.14 Managers and management scholars also tend to separate the world into either of two perspectives: (1) the “quantitativists” tend to view projects in terms of costs, dates, and economic variables; (2) the “behaviorists” view projects in terms of peoples’ behavior, skills, and attitudes, and systems of organization.

The intent of this book is to give a balanced view that emphasizes both the behaviorist and quantitativist sides of project management. The philosophy of this book is that for managers to “do” project management, they must gain familiarity with four topical areas: system methodology; systems development process; management methods, procedures, and systems; and organization and human behavior; correspondingly, the objectives of this book are to cover in depth:

1. The principles and philosophy that guide project management practice. 2. The logical sequence of stages in the life of a project. 3. The methods, procedures, and systems for defining, planning, scheduling,

controlling, and organizing project activities. 4. The organizational, managerial, and human behavioral issues in project

management.

In recent years the scope of project management has grown to encompass more than the management of individual projects, recognizing that project success involves more than the skills and talent of a good project manager; hence, a final objective of the book is to cover:

5. Responsibilities of the organization for assuring effective project management and successful projects.

Organization of This Book

Beyond this introductory chapter, the book is divided into five main sections. The first section is devoted to the basic concepts of project management. This section describes project management principles, systems methodologies, and the systems approach—the philosophy that underlies project management. Also covered are the origins and concepts of project management, situations where it is needed, and examples of applications. The second section describes the logical process in the creation and life of a system. Called the Systems Development Cycle, it is the sequence of phases through which all human-made systems move from birth to death. The cycle is described in terms of its relation to projects and project management. The third section is devoted to methods and procedures for planning, scheduling, cost estimating, budgeting, resource allocation, controlling, and terminating a project. The topics of resource planning, computer and web- based project management, and project evaluation are also covered. The fourth section is devoted to project organizations, teams, and the people in projects. It covers forms of project organization, roles and responsibilities of project managers and team members, styles of leadership, and methods for managing teamwork, conflict, and emotional stress. The last section covers topics that lie beyond the project manager but are crucial for project success and, more broadly, the success of the organizations and communities that sponsor and undertake projects. It also covers a topic that spans most other topics in this book but

requires special attention, managing projects in different countries. The five stated objectives of this book are roughly divided among chapters in

the book’s five sections:

1. Basic concepts and systems philosophy: Chapters 1 and 2. 2. Systems development and project life cycle: Chapters 3 and 4. 3. Methods, procedures, and systems for planning and control: Chapters 5

through 13. 4. Organization, management, and human behavior: Chapters 14 through 16. 5. The corporate context and international project management: Chapters 17

through 19.

Three Appendices provide examples of topics mentioned throughout the book: request for proposal (Appendix A), project proposal (Appendix B), and project execution plan (Appendix C).

I.9 Study Project

The best way to learn about project management is to actually participate in it or, failing that, to witness it. At the end of every chapter in this book are two kinds of questions: the first kind are the usual chapter review questions, the second are called “Questions About the Study Project.” The latter are intended to be applied to a particular project of the reader’s choosing. This will be called the “study project.” The purpose of these questions and the study project is to help the reader relate concepts from each chapter to real-life situations.

The study project questions can be used in two ways:

1. For readers who are currently working in projects as managers or project team members, the questions can be related to their current work. The questions serve to increase the reader’s awareness of key issues surrounding the project and to guide managers in the conduct of project management.

2. For readers who are currently full- or part-time students, the questions can be applied to “real-life” projects they are permitted to observe and research. Many business firms and government agencies are happy to allow student groups to interview managers and collect information about their projects. Though secondhand, this is nonetheless an excellent way to learn about project management practice (and mismanagement).

Assignment

Select a project to investigate. It should be a “real” project; that is, a project that has a real purpose and is not contrived just so you can investigate it. It can be a current project or one already completed; whichever, it must be a project for which you can readily get information.

If you are not currently involved in a project as a team member, then you must find one for which you have permission to study (collect data and interview people) as an “outsider.” The project should include a project team (minimum of

five people) with a project leader and be at least 2 or 3 months in duration. It should also have a specific goal in terms of a target completion date, a budget limit, and a specified end-item result or product. In general larger projects afford better opportunity to observe the concepts of project management than smaller ones.

If you are studying a project as an outsider it is also a good idea to do it in a team with three to six people and an appointed team leader (i.e., perform the study using a team). This, in essence, becomes your project team—a team organized for the purpose of studying a project. You can then readily apply many of the planning, organizing, team building, and other procedures discussed throughout the book as practice and to see how they work. This “hands-on” experience with your own team combined with what you learn from the project you are studying, will give you a fairly accurate picture about problems encountered and management techniques used in real-life project management.

Appendix: Relation Between Professional Standards and Chapters of this Book

Table I.1 PMI Project Management Bodies of Knowledge and Process Groups

PMBOK GUIDE AND TEN KNOWLEDGE AREAS

CHAPTERS ADDRESSING THESE AREAS

MOST RELEVANT RELATED

1. Introduction 0, 1 15, 16 2. Organizational influence & project Life

cycle 3, 14, 16 1, 2, 4, 5, 13, 14–

17 3. Project management processes 3, 13

4. Project integration management* 4, 11 2, 5, 9, 12, 14, 19 5. Project scope management* 4, 5, 11 2, 13, 19

6. Project schedule management* 6, 7, 11 5, 13, 19 7. Project cost management* 8, 11 19

8. Project quality management* 9 11, 13 9. Project resource management* 6, 16 7, 11, 14, 15, 19

10. Project communications management* 11, 12 13, 19 11. Project risk management* 10 7, 11, 18, 19

12. Project procurement management* 3, 5 11 13. Project stakeholder engagement* 15 1, 2, 3, 19 14. Appendix X3: Interpersonal &

behavioral skills 16

*Knowledge area Process Groups

Initiating Process Group 3, 4 Planning Process Group 5, 6, 7, 8 9, 10, 13, 19 Executing Process Group 11 13, 19

Monitoring and Controlling Process Group 11 12, 13, 19 Closing Process Group 12

Table I.2 IPMA Project Management Competencies

ICB - IPMA COMPETENCE BASELINE

CHAPTERS ADDRESSING THESE COMPETENCIES

MOST RELEVANT RELATED 1. Technical competencies

 1.01 Project management success 3, 5, 9  1.02 Interested parties 15 1, 3, 19

 1.03 Project requirements & objectives

4, 5 2, 11, 19

 1.04 Risk & opportunity 10 7, 11, 18, 19  1.05 Quality 9 11, 13

 1.06 Project organization 14, 15 13, 16, 19  1.07 Teamwork 16 13

 1.08 Problem resolution 16 2, 9, 10  1.09 Project structures 5, 14 1, 4, 8, 13, 15

 1.10 Scope & deliverables 4, 5 2, 3, 13  1.11 Time & project phases 3, 4, 6, 7 3

 1.12 Resources 5, 6, 7 8, 11, 12, 14, 16, 18, 19  1.13 Cost & finance 8 -

 1.14 Procurement & contract 3, 5 11, 19  1.15 Changes 11 13

 1.16 Control & reports 11 13, 19  1.17 Information & documentation 9, 12

 1.18 Communication 11, 12 19  1.19 Startup 3, 4 16

 1.20Closeout 12 2. Behavioral competencies

 2.01 Leadership 16 15, 19

 2.02 Engagement 15, 16  2.03 Self-control 16  2.04 Assertiveness 16  2.05 Relaxation 16  2.06 Openness 16  2.07 Creativity 9, 10

 2.08 Results orientation 16  2.09 Efficiency 5–9, 11, 16

 2.10 Consultation 5, 16  2.11 Negotiation 3, 16

 2.12 Conflict & crisis 16  2.13 Reliability 5–9, 16

 2.14 Values appreciation 16  2.15 Ethics 16

3. Contextual competencies  3.01 Project orientation I, 1, 17  3.02 Program orientation 17 1  3.03 Portfolio orientation 18 1

 3.04 Project, program & portfolio implementation

18 17

 3.05 Permanent organization 4, 14, 17  3.06 Business 14, 17–19

 3.07 Systems, products & technology 2, 3, 4 9  3.08 Personnel management 6, 16, 19  3.09 Health, security, safety &

environment 3 4, 10

 3.10 Finance 8, 11, 18

 3.11 Legal 3, 19

Table I.3 APM Project Management Knowledge Areas

APMP QUALIFICATION 37 CHAPTERS ADDRESSING THESE

KNOWLEDGE AREAS AREAS

MOST RELEVANT RELATED

Project management in context  1.1 Project management 1 I, 17, 19

 1.2 Programme management 17 1  1.3 Portfolio management 18 1

 1.4 Project context 1 2  1.5 Project sponsorship 15 19

 1.6 Project office 17 14 Planning the strategy

 2.1 Project success & benefits management

3 9

 2.2 Stakeholder management 15 1–3, 19  2.4 Project management plan 4 5–10  2.5 Project risk management 10 7, 11, 18, 19

 2.6 Project quality management 9 11, 13  2.7 Health and safety 3 4, 10 Executing the strategy

 3.1 Scope management 4, 5, 11 2, 13, 19  3.2 Scheduling 6,7 5, 11, 13, 19

 3.3 Resource management 5–7 8, 11, 12, 14, 16, 18, 19

 3.4 Budgeting & cost management 8 11, 19  3.5 Change control 11 13

 3.6 Earned value analysis 11  3.7 Information management & reporting 12 19

 3.8 Issue management 11 Techniques

 4.1 Requirements management 4,5 2, 11, 13, 19  4.3 Estimating 8

 4.7 Configuration management 8 2, 11

 4.7 Configuration management 8 2, 11 Business and commercial

 5.1 Business case 3  5.4 Procurement 3, 5 11

Organisation and governance  6.1 Project life cycles 3 13, 17

 6.5 Handover and closeout 12  6.6 Project reviews 12 9, 13

 6.7 Organizational structure 14  6.8 Organizational roles 15

 6.9 Methods and procedures 17 13  6.10 Governance of project management 17, 18

People and the profession  7.1 Communication 12

 7.2 Teamwork 16 13  7.3 Leadership 16 15, 19

 7.4 Conflict management 16  7.5 Negotiating 3, 16

Table I.4 PRINCE2 Methodology: Principles, Themes, Processes

PRINCE 2 CHAPTERS ADDRESSING PRINCIPLES,

THEMES, PROCESSES

MOST RELEVANT RELATED 1. Seven principles

 Continued business justification

18

 Learn from experience 17 4, 13  Defined roles and

responsibilities 15

 Manage by stages 3 2, 4  Manage by exception 9  Focus on products 4,5,9

 Tailor to suit the project environment

1 I, 17

2. Seven themes  Business case 3  Organization 5, 14 1, 4, 8, 13, 15

 Quality 9 11, 13  Plans 5 6–10  Risk 10 7, 11, 18, 19

 Change 11 9, 13  Progress 11 11, 19

3. Seven processes  Starting up a project 3, 4 16  Directing a project 11 12, 13, 19  Initiating a project 3, 4  Managing a stage

boundary 4

 Controlling a stage 11  Managing product delivery 11

 Closing a project 12

Review Questions

1. Look at websites, newspapers, magazines, or television for examples of projects. Surprisingly, a great number of newsworthy topics relate to current and future projects, or to the outcome of past projects. Prepare a list of these topics.

2. Prepare a list of activities that are not projects. What distinguishes them from project activities? Which activities are difficult to classify as projects or non-projects?

3. Because this is an introductory chapter, not very much has been said about why projects must be managed differently from ordinary “operations,” and what constitutes project management—the subject of this book. Now is a good time to speculate about these: Why do you think projects and non-projects need to be managed differently? What do you think are some additional or special considerations necessary for managing projects?

Case I.1 The Denver Airport15

When the Denver Airport project was initiated in 1989, the planned 4-year timeframe seemed adequate. However, despite abundant political backing and adequate funding, the project suffered a 16-month delay and a $1.5 billion cost overrun. The NTCP model can be used in retrospect to explain the root cause of much of the project’s unsatisfactory performance. With 20- 20 hindsight one may argue that a relatively simple NTCP analysis of the project and its sub-projects at an early stage (and adjusting the management style accordingly) might have significantly improved performance.

To enable aircraft turnaround around in less than 30 minutes as requested by United Airlines, one of the airport’s largest tenants, an automated baggage sorting and handling system was necessary to improve efficiency

over the traditional manual handling system. In December 1991 BAE Automatic Systems was contracted to design and implement the automated system in an estimated 2.5-year timeframe.

By August 1994 the system was 11 months late and was severely hampering airport operations. Management decided to build an alternative, more traditional baggage system as a backup at an additional $50 million cost, and only United would use the BAE system for its own terminal concourse. In January 1995 a full-scale practice run of the BAE system was successfully executed, and in February 1995 the airport was opened—16 months late.

Building the airport was mostly a typical large construction project; in terms of NTCP it would be classified as follows: Novelty—Platform; Technology—Low-tech; Complexity—Array; Pace—Fast/Competitive. The snag in the project was that one element—the automatic baggage-handling system: it was new technology and, thus, riskier than the rest of the project, a risk that was not considered. The system was the first of its kind (it had been used before only on a much smaller scale) and required several design cycles and intensive testing. It therefore should have been considered “High- tech” and managed accordingly. As discussed later in the book, high-risk projects need to be managed differently from low-risk projects. The NTCP profiles of the total project and the baggage-handling system are illustrated in Figure I.6.

Figure I.6 “Diamond” profiles for the Denver Airport and for the Baggage-Handling System.

Source: Shenhar A. and Dvir D. Reinventing Project Management: The Diamond Approach to

Successful Growth and Innovation. Cambridge, MA: Harvard Business School Press; 2007.

Questions About the Case

1. In what ways should High-tech projects be managed differently from Low-tech ones?

2. BAE Automatic Systems is a reputable high-technology corporation and was familiar with building automated baggage-handling systems. What might have convinced them to accept a schedule of 2.5 years for designing and construction of the baggage-handling system?

3. If an NTCP analysis had been done and the profile of the baggage- handling system identified, what should the project manager have done to help ensure project success?

4. Explain how the NTCP model makes provision for 144 different types of projects.

Endnotes

1. Tompkins P. Secrets of the Great Pyramids. New York, NY: Harper & Row; 1976, pp. 233–234; Poirier R.

The Fifteen Wonders of the World. New York, NY: Random House; 1961, pp. 54–67.

2. Ibid., pp. 227–228.

3. Barber F. The Mechanical Triumphs of the Ancient Egyptians. London, UK: Tribner; 1900.

4. George C.S. The History of Management Thought. Upper Saddle River, NJ: Prentice Hall; 1968, p. 11.

5. Potok C. Wanderings. New York, NY: Fawcett Crest; 1978, pp. 154–162.

6. See Archibald R.D. Managing High-Technology Projects. New York, NY: Wiley; 1976, p. 19; Meredith J.

and Mantel S. Project Management: A Managerial Approach, 3rd edn. New York, NY: Wiley; 1995, pp. 8–

9; Roman D. Managing Projects: A Systems Approach. New York, NY: Elsevier; 1986.

7. See Terraine J. The Mighty Continent. London, UK: BBC; 1974, pp. 241–242.

8. This section is adapted from: Shenhar A. and Dvir D. Reinventing Project Management: The Diamond

Approach to Successful Growth and Innovation. Cambridge, MA: Harvard Business School Press, 2007.

Since publication of the book, the NTCP model has been revised: “Breakthrough” has been split into

New-to-Market, and New-to-World; to “Complexity” the level of Component has been added below

Assembly.

9. See Rosenau M.D. Successful Project Management. Belmont, CA: Lifetime Learning; 1981, pp. 15–19.

10. Archibald, Managing High-Technology Projects, pp. 6–7.

11. Kerzner H. Project Management: A Systems Approach to Planning, Organizing, and Controlling, 10th

edn. Hoboken, NJ: John Wiley & Sons; 2009, p. 16.

12. APM Body of Knowledge, 6th edn. Association for Project Management, 2013; IPMA Competence

Baseline: ICB, International Project Management Association. Available for download at

http://ipma.ch/certification/competence/ipma-competence-baseline/ (accessed December 30, 2014); A

Guide To The Project Management Body of Knowledge (PMBOK Guide), 5th edn. Project Management

Institute, 2013.

13. Managing Successful Projects with PRINCE2, 2009 edn. Office of Government Commerce. Available for

download at https://www.prince2.com/downloads (accessed December 30, 2014).

14. Snow C.P. The Two Cultures and a Second Look. Cambridge, UK: Cambridge University Press; 1969.

15. Shenhar A. and Dvir D. Reinventing Project Management: The Diamond Approach to Successful Growth

and Innovation. Boston, MA: Harvard Business School Press; 2007.

Part I Philosophy and Concepts

1 What Is Project Management?

2 Systems Approach

The two chapters in this section describe the philosophy and concepts that differentiate project management from traditional, non-project management. The first chapter introduces features associated with project management and project management variations. Project management is an application of what has been called the systems approach to management; the second chapter describes the principles, terminology, and methodology of that approach. The two chapters set the stage for more detailed coverage in later sections.

Chapter 1 What Is Project Management?

The projects mentioned in the Introduction—the Great Pyramid of Egypt, the International Space Station, the Chunnel, and the development of “Product J” have something in common with each other and with every other undertaking of human organizations: they all require, in a word, management. Although the resources, work tasks, and goals of these projects vary greatly, none of them could have happened without management. This chapter contrasts project management and non-project management and looks at the variety of ways and places where project management is used.

1.1 Functions of Management1

The role of management is to plan, organize, and integrate resources and tasks to achieve the organization’s goals. Although the specific responsibilities of managers vary greatly, all managers—whether corporate presidents, agency directors, line managers, school administrators, movie producers, or project managers—have this same role.

The activities of managers, including project managers, can be classified into the five functions identified in Figure 1.1. First is deciding what has to be done and how it will be done. This is the planning function, which involves setting a purpose or goal and establishing the means for achieving it consistent with higher-level organizational goals, resources, and constraints in the environment.

Second and related to planning is arranging for the work to be done; this is the organizing function. This involves (1) hiring, training, and gathering people into a team with specified authority, responsibility, and accountability relationships; (2) acquiring and allocating materials, capital, and other resources; and (3) creating an organization structure with policies, procedures, reporting patterns, and communication channels.

Third is directing and motivating people to attain the goal. This is the leadership function.

Fourth is monitoring work performance with respect to the goal and taking necessary action whenever work deviates from the goal; this is the control function.

The four functions are aimed at the goal, which implies a fifth function: assessing the four functions to determine how well each of the functions is doing and whether the functions or the goals need to be changed.

On a day-by-day basis, rarely do managers perform the functions in Figure 1.1 in sequence. Although planning logically precedes the others, there is always a need to organize activities, direct people, and evaluate work, regardless of sequence. Managers constantly face change, which means that plans, activities, performance standards, and leadership styles must also change.

Figure 1.1 The functions of management.

Different managers’ jobs carry different responsibilities depending on the functional area and managerial level of the job. Some managers devote most of their time to planning and organizing, others to controlling, and others to directing and motivating. At some time or another, project managers perform all these functions.

1.2 Features of Project Management

Project management is a systems approach to management. A system is a collection of interrelated components or elements that in combination do something. A project can be thought of as a system: it is a collection of elements —work tasks, resources, and stakeholders (individuals, teams, organizations)— aimed at achieving some goal. The focus of the systems approach is to optimize the overall system (not its individual elements) so as to achieve the goal. The approach starts by defining the goal, identifying components or elements of the system that contribute to or detract from meeting the goal, and then managing the elements to best achieve the goal. It involves all the functions of management —planning, organizing, leadership, and so on.

As described in the Introduction, projects differ from non-projects. Non-project activities such as mass production in factories or delivery of routine services are routine and seldom change; there is little uncertainty or risk involved. They tend to involve the same people doing the same procedures, day-in, day-out. In contrast, every project is unique and unfamiliar in some sense, and requires people or teams from different functions or organizations. This creates uncertainty and risk and makes it harder to achieve the desired goal. So the question is: How do you manage such a thing as a project? The answer: Use project management.

The key features of project management are:2

1. A single person, the project manager, heads the project organization and works independently of the normal chain-of-command. The project organization reflects the cross-functional, goal-oriented, temporary nature of the project.

2. Because each project requires a unique variety of skills and resources, project work might be performed by people from different functional areas or outside contractors.

3. The project manager is responsible for integrating people from the different functional areas or outside contractors.

4. The project manager works directly with functional managers or contractors who might be responsible for the individual work tasks and personnel within the project.

5. Whereas project managers focus on delivering particular products or services on time and on budget, functional managers might be responsible for providing project workers and resources from their departments. As a result, conflict may arise between project and functional managers over the people and resources allotted to projects.

6. A project might have two chains-of-command, one functional and one project, so people working in a project report to both a project manager and a functional manager.

7. Decision making, accountability, outcomes, and rewards are shared between the project team and supporting functional units and outside contractors.

8. Although the project organization is temporary, usually the functional or subcontracting units from which it is formed are permanent. When a project ends, the project organization is disbanded and people return to their functional or subcontracting units.

Because projects require the coordinated efforts of different individuals and units from within and outside the organization, managers and workers in different units and at different levels work directly with each other. Formal lines of communication and authority are frequently bypassed and a horizontal hierarchy is created. This horizontal hierarchy enables people in the project organization from different functional areas and outside organizations to work directly with each other as needed.

In non-project organizations, managers tend to be specialized and responsible for a single functional unit or department. A project, however, since it might involve many departments, needs someone from beyond these departments to take responsibility for meeting the project’s goals. That person is the project manager. The emphasis on project goals versus the goals of each functional unit is a key feature that distinguishes project managers from functional managers.

Project managers often direct people who are not “under” them but who are “assigned” to them from different areas of the organization as needed. This

potentially makes being a project manager more complicated (and difficult) than being a departmental manager. Project managers must know how to use diplomacy, resolve conflicts, and be able to function without the convenience of always having the same team reporting to them.

1.3 Evolution of Project Management

No single individual or industry can be credited with the idea of project management. It is often associated with the early missile and space programs of the 1960s, but clearly its origins go back much earlier. Techniques of project management probably first appeared in the major construction works of antiquity, such as the Pyramids and the Roman aqueducts, and were later modified for use on other projects such as shipbuilding. Starting in the early twentieth century, managers developed techniques for use in other kinds of projects, such as for designing and testing new products, and building and installing specialized machinery. During World War I a new tool called the Gantt chart for scheduling and tracking project-type work was developed (examples in Chapter 5), followed about 40 years later by the project network diagram (discussed in Chapter 6).

By the 1950s, the size and complexity of many projects had increased so much that existing management techniques proved inadequate. Repeatedly, large-scale projects for developing aircraft, missiles, communication systems, and naval vessels suffered enormous cost and schedule overruns. To grapple with the problem, two new “network-based” methods for planning and control were developed, one called PERT, the other called CPM (described in Chapters 6 and 7). A decade later, network-based methods were refined to integrate project cost accounting with project scheduling. These methods came into widespread usage in the 1960s when the US government mandated their usage in projects for the Department of Defense, NASA, and large-scale efforts such as nuclear power plants. In the 1970s, the earned value method of project tracking was developed (see Chapter 12); this led to performance measurement systems that simultaneously track work expenditures and work progress.

See Chapters 5 and 6

See Chapters 6 and 7

See Chapter 12

The last 50 years have witnessed the increased computerization of project management. Whereas initial project planning and tracking systems cost $10,000 to $100,000, today relatively low-cost software and freeware make it possible to use a variety of tools for planning, scheduling, costing, and controlling virtually any size project.

Associated with the evolution of project management was the emergence of project forms of organization and the role of project manager. Not until World War II was “the project” recognized as a distinct organizational form. In the urgency to develop sophisticated weaponry and organize massive task forces of troops and material, the “pure-project” form of organization evolved (described in Chapter 14), and it was not until the 1960s that companies began to use the term “project manager” as a formal title and role (see Chapter 15).

In recent years, project management has proliferated throughout all industries around the world. The most widespread applications and examples of each are discussed in the following sections.

See Chapters 14 and 15

1.4 Where is Project Management Appropriate?3

Fact is, project management is applied everywhere, and there are few industries or situations where it is not applied at least some of the time. This section identifies conditions and situations where a project-type organization applies or is essential.

Project management can be applied to any “ad hoc” undertaking. As shown in Figure I.3 in the Introduction, “ad hoc” includes activities that range from writing a term paper or remodeling a kitchen, to fundraising and constructing theme parks. Generally, the more unfamiliar or unique the undertaking, the greater the need for project management; the more numerous, interdisciplinary, and interdependent the activities in the undertaking, the greater the need for project management to ensure everything is coordinated, integrated, and completed, and nothing is overlooked.

Customers such as major corporations and governments frequently request or mandate formal project management because they believe it offers better cost, schedule, and quality control, and they prefer having a single point of contact— the project manager—with whom to deal.

See Introduction

Criteria

Cleland and King list five criteria for determining when to use project management methods and organization:4

1. Unfamiliarity

By definition, a project involves doing different things, doing the same things but differently, or both. For example, whereas continuous minor changes in products

such as small improvements in automobile parts can usually be accomplished without project management, modernizing an automotive plant, which calls for non-routine efforts such as upgrading facilities, replacing equipment, retraining employees, and altering procedures, would certainly require project management.

2. Magnitude of the Effort

When a job requires substantially more resources (people, capital, equipment, etc.) than are normally employed by a department or organization, project management may be necessary. Examples include relocating a facility, merging two corporations, or developing a new product and placing it on the market. Even when the job lies primarily within the realm of one functional area, the task of coordinating the work with other functional areas might be large. For example, although a corporate software installation project might seem to fall entirely within the functional area of information technology, in fact it might require a meshing of the procedures and resources of all departments affected by the installation and involve hundreds of people.

3. Dynamic Environment

Industries such as aerospace, biotechnology, computers, electronics, pharmaceuticals, and communications face continual change driven by an environment characterized by high innovation, intense competition, and shifting markets and consumer demands. Project management provides the necessary flexibility to deal with emerging threats and opportunities in such environments.

4. Interrelatedness

Functional areas tend to be self-serving and work independently. When the effort requires that they work together, project management is necessary to build relationships between the areas, expedite work, and reconcile conflicts. The project manager coordinates the efforts of internal functional areas and with

outside subcontractors and vendors.

5. Reputation of the Organization

If failure to satisfactorily complete a project would result in financial ruin, loss of market share, damaged reputation, or loss of future contracts, the case for using project management is strong. Project management cannot guarantee success, but it does improve the odds by reducing the inherent risks in large, complex undertakings.

Example 1.1 Renovating the Statue of Liberty5

Ninety-five years after the Statue of Liberty was presented to the American people, its surface and interior structure had become so badly corroded that it was judged structurally unsound. To oversee restoration of the statue and other buildings on nearby Ellis Island, the US Department of Interior established a foundation.

Very little of the restoration work qualified as “standard.” It involved highly specialized skills such as erecting the scaffolding, constructing a new torch, building windows for the crown, and replacing the interior framework—expertise that tends to be found in smaller firms. As a result, the work was accomplished by a legion of over 50 small businesses, many of whose workers were immigrants or descendants of immigrants whom the statue had welcomed to America.

There were myriad notable features about the job. The scaffolding surrounding the statue never touched it at any point. Constructed of hundreds of thousands of pieces of aluminum, it qualified for the Guinness Book of World Records as the largest free-standing scaffolding ever built. To renovate the statue’s interior, 1,699 5-foot (1.5 m) bars were painstakingly fashioned from 35,000 pounds (15,900 kg) of stainless steel, and then individually installed. Around the crown 25 windows were replaced. Each was handcrafted and had to be treated as a project unto itself. To fashion an entirely new torch, French artisans practiced an ancient copper shaping

technique. The project was truly a marriage of art and engineering. The 30-month, $31 million renovation effort involved thousands of tasks

performed by hundreds of people. Most of the tasks were non-routine and interrelated, and all had to be completed within a tight budget and schedule; such a situation calls for project management. (Chapter 16 discusses the company responsible for managing the renovation.)

See Chapter 16

Where Project Management is not Appropriate

The obverse of all of this is that the more familiar and routine the undertaking, the more stable the environment, the less unique and more standardized the end- item, and the lower the stake in the result, the less the need for project management. Production of standardized industrial and agricultural outputs, for example, is generally more efficiently managed by tried and true operations planning and control procedures than by project management. This is because for standardized, repetitive operations, there is much certainty in the process and outcome; for such operations, standardized, routine procedures for production planning, scheduling, and budgeting are well-suited, and project management is not.

1.5 Management by Project: A Common Approach

Though not appropriate for every situation, project management applies to a great many, and not only large-scale, infrequent undertakings, but also all kinds of smaller, more frequent activities as well. Whenever an undertaking involves activities that are somewhat unique or unfamiliar and requires cooperation from several parties, project management applies.

For example, consultants in most every industry perform work on a project-by- project basis. Whenever their work calls for coordinated participation of several individuals or groups, project management applies. The more people or groups involved, the more the applicability of project management.

Similarly, groups that develop or implement new products, systems, or services also work on a project-by-project basis. The larger, riskier, more complex, costly, innovative, or different the thing being developed or implemented, the greater the applicability of project management.

Further, any group that performs unique work on a client-by-client basis (so- called made-to-order, or made-to-engineer) is performing project work. If the work requires coordinated efforts from different parties, project management applies.

Think about these situations for a moment and you start to realize the many cases where projects happen and project management applies.

Managing any kind of work as a discrete project is referred to as “managing by project,” or MBP.6 With MBP, an undertaking or set of activities is planned and managed as if it were a project. In particular, MBP implies that the undertaking will have well-defined objectives and scope, firm requirements for the end- results, a plan of work, a completion date, and a budget for the required resources. A team is formed for the sole purpose of performing the work, and a project manager or team leader is assigned to guide and coordinate the work.

At some time, all organizations do projects. Even in stable repetitive industries, small projects involving a few individuals are always in progress: new machines are installed, old ones are repaired; the office is remodeled; the cafeteria is renovated. When these or larger project efforts arise, a formalized project group

is formed and a project manager appointed.

Example 1.2 Relocation of Goman Publishing Company

Many companies, regardless of size (headquarters for a multi-billion dollar corporation or a storefront family restaurant), at some point face the decision to relocate. Relocation requires planning and coordination of numerous tasks involving many individuals, departments, and outside contractors. It is an important event that if done properly can be an exciting and profitable experience, but if done poorly can lead to financial loss or ruin. It is also representative of a situation wherein a company must do something it does not ordinarily do.

Goman Publishing was experiencing rapid growth and expected to outgrow its current facility. The initial task in relocating the company was to decide between two options: buying land and constructing a new building, or leasing or buying an existing structure. After deciding to build, the next task was to select a site. The main selection criteria were purchase expense, distance from current location, prestige and size of the new location, and access to major highways. The next task was the relocation planning, which had two major phases: design and construction of the new facility, and the physical move, each involving numerous considerations. For example, Goman wanted to retain its current employees, and so as to maximize the new facility’s appeal it chose to build an indoor employee parking area and a large, well-appointed cafeteria. Among the many move- related considerations were furniture procurement, special handling of computers, hiring movers, informing employees and clients about the move, and maintaining corporate security. Further, the relocation would have to be scheduled to minimize downtime and interruption of operations.

To oversee the project and ensure that construction and the physical move would go as planned, Goman appointed a project manager. The project manager worked with architects and building contractors during the design and construction phases, and with representatives from functional

departments and moving contractors during the relocation move. Despite the scope and unfamiliarity of the project, Goman was able to complete the construction and physical move on time and on budget.

1.6 Different Forms of Project-Related Management

Project management takes different forms with different names, including systems management, task force management, team management, ad hoc management, matrix management, and program management. All these forms share two features: (1) a project team or project organization created uniquely for the purpose of achieving a specific goal, and (2) a single person—a project manager—assigned responsibility for seeing that the goal is accomplished. Beyond these, features of the forms are somewhat different.

The first section below covers “basic” project management, the most commonly understood concept of project management. The other sections cover management forms similar to project management or related to project selection.

Basic Project Management

Commonly the project manager and functional managers are on the same organizational level, and both report to the same senior-level persons. The project manager has formal authority to plan, direct, organize, and control the project from start to finish. The project manager may work directly with any level and functional area of the organization to accomplish project goals. She reports to the general manager or owner and keeps him apprised of project status. The project manager sometimes has authority to hire personnel and procure facilities, although more often she has to negotiate with functional managers to “borrow” them.

Basic project management is implemented in two widely used forms—pure project and matrix. In pure project management a complete, self-contained organization is created; the needed resources belong to the project and do not have to be borrowed. In matrix management, the project organization is created from resources borrowed from the functional units. The project must share its resources with other projects and with the functional areas from which they are borrowed. These two project management forms will be described further in

Chapter 14.

See Chapter 14

Often found in construction and technology industries, basic project management is also readily applied to small, nontechnical activities, including in the arts and social sciences. Adams, Barndt, and Martin cite examples:7

• Health, Education, and Welfare (HEW) performs social work largely on the basis of grants allocated through state and local agencies. Associated with each grant are time, cost, and performance requirements for the funding agencies. In essence, each grant results in a project to which the concepts of project management can be applied.

• An advertising firm conducting promotional campaigns utilizes the services of the marketing research, accounting, graphics, sales, and other departments. The campaigns are similar to the projects in other industries: they require planning and coordination of the departments as provided by project management.

Program Management

The term “program management” is sometimes used interchangeably with project management due to the similarities of programs and projects: both are defined in terms of goals or objectives about what must be accomplished and both require plans, budgets, and schedules for accomplishing the goals.

Nonetheless, programs and projects are different; the main distinctions are that a program extends over a longer time horizon (sometimes indefinitely) than a project, and it consists of several parallel or sequential work efforts or projects working to meet a program goal. The projects within a program share common goals and resources and, often, are interdependent. As examples, an urban development program may include several projects such as housing rehab, job and skill training, and small business consulting assistance; a Mars exploration program may include several projects for unmanned probes to the red planet and

its moons, Phobos and Diemos, followed by a manned mission to Mars. Another distinction is that projects are oriented to producing and delivering a

product or service, but after that the project organization is dissolved and responsibility is handed off to someone else for operating the end-item. In a program, however, it is the responsibility of program management to ensure the end-item is not only delivered but is integrated with other systems and operational for as long as needed. For example, program management would oversee not only development of a satellite and its booster rocket and launch, but also ongoing operation and monitoring of the satellite—whatever is needed to achieve the overall satellite program goal.

Many concepts for managing projects also apply to managing programs, though with modification to handle the larger scope and magnitude of programs and enable the program manager to oversee and coordinate the projects within the program. The Project Management Institute has published a Standard for Program Management that aligns with its PMBOK; the UK Office of Government has produced one that aligns with Prince2.8 Program management is discussed more in Chapter 17.

See Chapter 17

New Venture Management

Project management resembles new venture management, a type of management used in consumer-oriented firms for generating new products or markets. In new venture management a team is created to find new products or markets that fit an organization’s specialized skills, capabilities, and resources. Once it has defined the product, the team may go on to design and develop it, then determine the means to produce, market, and distribute it.

Product Management

The term product management refers to a special type of program management

where a single person is responsible for overseeing all aspects of a product’s production scheduling, inventory, distribution, and sales. The product manager coordinates and expedites the product’s launch, manufacture, distribution, and support. Like the project manager, the product manager communicates directly with functions inside and outside the organization, and coordinates efforts directed at product goals. The product manager is active in managing conflicts and resolving problems that would degrade manufacturing capability, forestall distribution, alter price, harm sales, or in any way affect financing, production, and marketing of the product. For products with long life cycles, the product manager role is filled on a rotating basis.

Project Portfolio Management

Many organizations select and group projects and programs into “portfolios,” each similar to an investment portfolio, with the goal of maximizing the value of the portfolio in terms of, for example, profit, rate of return, or meeting company strategic goals. The portfolio manager helps the organization make decisions about adding, cancelling, or changing projects or programs based on financial performance, resource utilization, risks, and other factors affecting business value.

Whereas the purpose of project and program management is to manage particular projects and programs, the purpose of portfolio management is to make sure the right projects and programs are selected, i.e., to assure that they align with the organization’s strategic and financial goals and fit within the available limited resources.

Portfolio management is not really about managing projects per se, but selecting and retaining the right projects. Thus, to portfolio managers, project management experience is less important; of greater importance is the financial and analytical skills needed to select and group projects and programs based on their contributions to strategic and financial goals. The portfolio manager must know how to diversify a project portfolio to take advantage of available resources and the risk–reward tradeoff. The PMI created the Standard for Portfolio Management and offers a Certification in Portfolio Management; the UK OCG

has also created a standard.9 Portfolio management is covered in Chapter 18.

See Chapter 18

1.7 Project Environments10

Project management practice also varies depending on the project environment, which author Daniel Roman classifies as commercial/for profit, government/nonprofit, and military. All the project forms described above are found in the commercial environment. The two forms most commonly found in government and the military are basic project management and program management.

Commercial/For-Profit Project Management

In a commercial project the end-item is a clearly defined product or service, typically customized to satisfy a customer, and motivated by profit criteria. The project manager usually guides the project start to finish, coordinating efforts of the project team with functional areas, subcontractors, and vendors, and keeping the customer and top management informed of progress toward project and profit objectives.

Government and Nonprofit Project Management

Government and nonprofit projects differ from commercial activities in several ways. First, there is no profit incentive in government and nonprofit work, and economic factors may be of lesser importance. Project managers are frequently reassigned midstream in their projects, which is problematic in terms of administrative continuity. For government work, project continuance often depends upon political considerations and funding that is legislatively appropriated.

Second, most of these projects focus on evaluation or testing of products or services procured from commercial contractors or vendors. Because design and development work in government projects is usually done by contractors, the project manager’s role is largely administrative. Though she is responsible for

checking on the contractors’ progress, the project manager may have little control over technical matters. Project managers frequently oversee and coordinate multiple, related projects; in other words, they are program managers.

Military Project Management

Most military projects involve testing and evaluating hardware developed by contractors. Evaluation is often based on the “weapons systems” approach whereby each project is part of a larger systems program and hardware is evaluated for its contribution to the mission of the overall system. The major criteria for evaluating projects are technical and political; costs are of lesser importance; profit is not a consideration. Each civilian contractor has a project manager who works with a military project manager. The latter are military officers and, because of their limited tours of duty, typically do not oversee a project for its full.

The following sections describe situations where project management is most common: development of new products and systems, construction, services, and public sector works.

1.8 New Product and Systems Development Projects

The development of every new product and system is a project. Examples include projects for developing products (such as household appliances, industrial machinery, and computers) and systems for defense, aerospace, energy, and telecommunication. Projects in medicine and pharmaceuticals include the development of new medicines, medical procedures, and medical equipment. Projects in IT/ICT include the development of information systems and software products.

When the development of new products and systems comprises new technologies, the early phases of the projects typically involve testing and experimentation. Although the main purpose of each project is to create a newly designed product or system, the actual project deliverable could be either the physical product or system, or merely documents showing the product design or how to produce it. These projects all have a significant engineering component; the examples described in Chapter 2 would fall into this category.

Following are two examples of product and systems development projects.

See Chapter 2

SpaceShipOne and the X-Prize Competition11

In April of 2003 SpaceShipOne (SS1) and its mother ship White Knight were rolled out to the public. Simultaneously it was announced that SS1 was entering the $10 million X-Prize competition against 23 other teams from seven countries to be the first manned vehicle to successfully make two trips into space in less than 2 weeks (Figure 1.2). Space is internationally recognized as beginning at 100 km, or about 62 miles (commercial jets fly at a height of about 8 km). The brainchild of celebrated aerospace engineer and visionary Burt Rutan and the culmination of almost 8 years of design and development work, it was but the first step in Rutan’s broader dream to build vehicles to carry paying passengers

into space. Rutan’s major challenge was not just winning the prize, but designing and building a complete space launch system—spacecraft, aerial launch vehicle, rocket motor, and all support subsystems—without having many hundreds of engineers and many millions of dollars in government support to do it. Rutan would try to do it with his own company of 130 people, a handful of subcontractors, and the $25 million backing of billionaire Paul Allen, cofounder of Microsoft.

Figure 1.2 SpaceShipOne beneath its mother ship, White Knight.

Photo: Flight 16P taxi pre launch, photo by D Ramey Logan; http://creativecommons.org/licenses/by-sa/4.0/.

Besides Rutan and Allen, the principal stakeholders in the program included the Ansari Foundation, Sir Richard Branson, and the FAA (Federal Aviation Administration). The Ansari Foundation is the sponsor of the X-Prize competition. Its long-term goal is to spur innovations that will make space travel safe, affordable, and accessible to everyone, and its X-Prize requirements were for “a non-government-funded program to put three people safely into space twice within 2 weeks with a reusable spacecraft.” Sir Richard Branson, founder of the Virgin Group, is the program’s customer; his plan is to buy spaceships and the associated technology for his fledgling space airline, Virgin Galactic. Branson has estimated Virgin will be able to turn a profit if it can carry 3,000 customers into

sub-orbit over a 5-year period at about $190,000 a ticket—to include medical checks, 3 days of preflight training, custom-molded seats, and 5 minutes of floating weightless while in space. (By comparison, a civilian trip aboard the International Space Station costs about $50 million.) Paying passengers are another stakeholder group. Although none would be aboard SS1, the vehicle was designed with them in mind. For instance, SS1’s cabin is designed to provide a “shirtsleeve” environment so passengers would not have to wear spacesuits. The FAA is also a stake-holder; it imposes a long list of requirements necessary for the spaceship to be “certified” and commercially viable.

As in most technical projects, a project manager shared oversight of the project with a project engineer. The project engineer was responsible for identifying technical requirements and overseeing design work, system integration, and testing. All this, and what else is left for the project manager to do, will become clear in later chapters.

The Development of “Product J” at Dalian Company12

The future of Dalian Company depends on its ability to continuously develop and market new products. Dalian specializes in food and drink additives, but it is representative of firms in industries such as pharmaceuticals, food products, biotechnology, home and commercial appliances, computer and entertainment electronics, and communications that must continuously generate new products to survive in a competitive environment.

Dalian Company was concerned about maintaining market share for its “Product H,” but it knew that competitors were developing substitutes for Product H that might be less expensive. To beat the competition, Dalian had to develop its own improved substitute, “Product J.”

The product development process at Dalian is facilitated by the New Product Development Department. The department is responsible for managing and coordinating all internal and externally contracted development projects; its purpose is to ensure that good ideas can be developed and quickly brought to market. The department has three directors who are the project managers. The directors facilitate, coordinate, and monitor the project efforts of the various

departments—research and development, engineering, marketing, manufacturing, and legal.

For each new product concept a team is created with representatives from functional departments. A director works with the team to assess the project’s progress and requirements. Functional managers decide about what is to be done and how, but the directors have final say over project direction. The directors always know the status of their projects and report any problems or delays to upper-level managers who manage the projects as a “portfolio” (i.e. they are portfolio managers). Projects facing big problems or signs of failure are cancelled so resources can be allocated to more promising projects.

Similar to all new product developments, development of “Product J” involved the participation of several departments: R&D developed a product prototype and prepared specifications; engineering defined where and in what ways the product would be used; marketing defined the commercial market and determined how to position the product; manufacturing developed a new process for making the product that would be difficult for competitors to copy; finance determined the initial product costing and performed profit/loss forecasts; and legal obtained regulatory approval and performed patent research.

The director for “Product J” was involved from project conception. She worked with R&D scientists and marketing experts to determine project feasibility and was active in gaining upper management’s approval. She worked with scientists and managers to prepare project plans and schedules. When additional labor, equipment, instruments, or raw materials were needed, she wrote requests for funds. When additional people were needed, she wrote personnel requests to upper management. During the project she scheduled and chaired project review meetings and issued monthly and quarterly progress reports.

1.9 Construction Projects

Similar to developing new products and systems, construction projects often have a front-end piece devoted to architectural/engineering design followed by a back- end piece for fabrication and construction. This is typical for most all construction projects, whether for new buildings, transport infrastructure (roads, bridges, rail systems, harbors, airports), factories, oil and gas installations, dams, mines, and plants for renewable energy and utilities. When undertaken for profit, such projects are classified as capital expenditure projects. Throughout this book are examples of project management in construction, for example: Case 8.2, the Chunnel Project; Case 9.1, Big Dig; Case 10.1, Sydney Opera House; Case 10.3, Nelson Mandela Bridge; and Case 19.1, the Mozal Aluminum Smelter. These cases describe large projects. The following case study illustrates project management in a smaller project.

Small Projects at Delamir Roofing Company

Delamir Roofing Company installs and repairs roofs for factories and businesses. Like other companies associated with the construction industry, Delamir considers each job a project and assigns a project manager to oversee it.

Involvement of the project manager begins when a request for work is received from a potential customer. The project manager examines the blueprints to determine how much material and labor time will be needed (called “prepping the job”) and then prepares a budget and a short proposal. After the contract is signed, the project manager visits the site ahead of the crew to make arrangements and accommodations for work to begin. The project manager has discretion in work crew selection to ensure that the size and skills of the crew fit the requirements of the job. After work begins, he is responsible not only for supervision of work and delivery of supplies, but for maintaining budget records and reporting progress to the home office. The project manager performs the final inspection with the customer and signs off when the job is completed. Overall,

his responsibility is to see that the job is done well.

1.10 Service-Sector Projects

Project management is employed in a broad range of services, including banking, consulting, insurance, national revenue services, stock exchanges, and accounting, and includes projects for developing new service systems and processes. The next two examples show how it is used in a corporate audit and in a nonprofit fundraising campaign.

Auditing at CPAone13

Large audits conducted by the auditing division at CPAone require the involvement of many people. In the audit of a national corporation, for example, numerous auditors with diverse specialties are needed to investigate all aspects of operations in various geographic areas. Given the number of people and the variety of skills, expertise, and personalities involved, a project manager is needed to oversee the audit. Every audit begins by assigning the client to a partner who is familiar with the client’s business. The partner becomes the audit’s “project director” and is responsible for the project’s initiation, staffing, scheduling, and budgeting.

The project director begins by studying the client’s income statement, balance sheet, and other financial statements. If the client has a bad financial reputation, the project director can make the decision for CPAone to refuse the audit. If the client is accepted, the director prepares a proposal that explains the general approach for conducting the audit and designates the completion date and the cost estimate.

In determining the general approach for conducting the audit, the project director considers the company’s size and number of departments. Auditors are then assigned on a department-by-department basis. The audit team is a pure project team, created anew for every audit, composed of people who have the skills best suited to the needs of the audit. Generally, each audit team has one or two staff accountants and one or two senior accountants. During the audit the

director monitors all work to ensure it adheres to the Book of Auditing Standards and is completed on schedule. Each week the client and project director meet to review progress. When problems cannot be solved immediately, the director may call in people from CPAone’s tax or consulting divisions. If the IRS (Internal Revenue Service) requests an examination after the audit is completed, the project director sees to it that the client is represented.

Nonprofit Fundraising Campaign Project: Archdiocese of Boston14

The Archdiocese of Boston contracted the American Services Company, a fundraising consulting firm for nonprofit organizations, to manage a 3-year campaign to raise $30 million for education, social and health care services, building renovations, and a clergy retirement fund. American Services appointed a project manager to prepare the campaign strategy and organize and direct the campaign staff. The project manager had to work with three stakeholder groups: donors, the Archdiocese Board of Directors, and campaign volunteers. Potential target donors had to be identified and provided with evidence to show how their financial commitments would benefit the community and the Archdiocese; the board and church leadership had to be involved in and kept apprised of campaign planning and progress; and volunteers had to be identified, organized, and motivated.

One of the project manager’s first tasks was to conduct a feasibility study to determine whether there was sufficient leadership capability, volunteer willingness, and “donor depth” within the Archdiocese community to achieve the $30 million goal. The study indicated that the goal was achievable, and pastors were invited to a kickoff luncheon at which time the Cardinal of the Archdiocese introduced the campaign. During the meeting, influential church personnel were signed up and the process of identifying potential donors and volunteers was started.

The project manager provided guidance for establishing a campaign leadership team and project office, enlisting volunteers, forming campaign committees, and recruiting and training volunteers. In addition to organizational matters, he convened several “reality sessions” with chairpersons to remind them of the

importance of the campaign and renew their commitment to the campaign goal, and organized frequent meetings with the volunteers to instill a sense of pride and involvement in the campaign.

1.11 Public-Sector and Governmental Projects and Programs

The following two examples illustrate how project and program management is performed in large public sector and joint government/commercial undertakings.

Disaster Recovery

The aid assistance, cleanup, rebuilding, and return-to-normalcy efforts following a disaster involve the labors of numerous organizations. A large disaster such as the December 2004 tsunami in the Indian Ocean impacts many countries and requires the support and coordinated efforts of host governments, non- governmental agencies (NGOs), local business, religious, and community organizations, and international aid, charitable, and funding organizations.

Almost by definition, post-disaster recovery is a program—or several programs —a host of efforts devoted to the goals of rescuing and providing immediate relief to victims and, ultimately, of returning the lives of people in the areas affected back to normal. Each program involves many projects to address the multiple aspects of a recovery effort, including projects to provide:15

• Immediate rescue of victims • Food and medical care • Temporary shelter and housing • Clothing, blankets, and other immediate physical needs • Social, moral, and spiritual assistance.

Ideally, disaster recovery is treated as an organized, coordinated effort—a managed program with numerous projects—that enables quick assessment of the scope of the situation, identification and organization of needed and available resources, and effective deployment of those resources. For all of that to happen requires leadership, usually in the person of someone with exceptionally strong

organization and leadership abilities—in effect, a program leader. In the chaos and frenzy immediately following a disaster, however, it is often not clear who is in charge. Indeed, the poor immediate response and confused rescue and recovery efforts in New Orleans and the surrounding US Gulf coastal region following Hurricane Katrina has been blamed on a lack of leadership and coordinated management at all levels of government—federal, state, and local.

In the months and years following a disaster, the focus turns to obtaining and allocating aid funding; reconstruction, redevelopment, and rebuilding (infrastructure, organizations, facilities); permanently situating (returning home or relocating) victims; dealing with waste and debris; and providing opportunities, jobs and ongoing support. To accomplish this requires numerous projects, for instance, to obtain and allocate financial assistance to individuals, businesses, and local government, and provide subsidized housing and building materials. Often the goal is to employ the victims in many small-scale, labor- intensive projects to provide jobs and income.

For example, the December 2004 tsunami caused severe damage to coastal areas in Sri Lanka, Thailand, Indonesia, the Maldives, and other countries around the Indian Ocean, and in India alone affected an estimated 2.7 million already- poor people, 80 percent of whose livelihoods depended on fishing and 15 percent on agriculture. The government of India launched the Emergency Tsunami Reconstruction Project, estimated to cost US $682.8 million, to help repair or reconstruct about 140,000 damaged houses in two coastal regions and assist with the reconstruction of public buildings and the revival of livelihoods in fisheries and agriculture.16 It is a project–a program really–that consists of many hundreds of projects, takes many years, and continues for as long as the funding holds out.

NASA Project and Program Management17

NASA has had a successful history of working in partnership with researchers in universities, industry, and the military. NASA and industry work closely together on technical problems, but technical initiatives and technical decisions are made by NASA field installations.

NASA organization includes (1) top management, (2) functional support for top

management, (3) program offices for developing and controlling major programs, and (4) field installations, which conduct the programs and their projects either on-site or at universities for contractors. NASA is divided into four mission directorates or offices: Exploration Systems, Space Operations, Science, and Aeronautics Research, shown in Figure 1.3.

Each directorate is responsible for development, justification, and management of programs that support broad NASA goals. Directorates are assigned field installations to carry out permanent activities for the directorate, but, still, also carry out projects or tasks under the direction of other directorates. For example, though Ames reports to Science, it also contributes to projects in Space Operations.

In a typical non-NASA government agency project, the agency prepares specifications for a program, lets a contract, and then relies on the contractor for results. NASA uses a different approach since no one company likely has all of the capability to execute a large project. Although NASA relies upon industry to build, integrate, and test-fly hardware, it relies upon its own in-house management and technical competence to monitor and work with contractors. Because NASA projects call for a diversity of technical and managerial competency, project managers practice the philosophy of “participative responsibility”—an integration of technical and managerial competency across industry, academia, and NASA laboratories. Regardless of location, NASA brings in experts from its own field installations, universities, and other government laboratories to assist contractors in tackling difficult problems. This participative team approach avoids the usual delays caused by working across boundaries that separate government and commercial organizations. The concept utilizes teamwork, central control, and decentralized execution, but respects the semi- autonomous status of NASA’s field installations.

NASA defines a program as a series of undertakings that over several years are designed to accomplish broad scientific or technical goals. It defines a project as an undertaking within a program with a scheduled beginning and end, and normally involves design, construction, and/or operation and support of specific hardware items.

NASA uses a dual system of responsibility. The single greatest contributor to a project’s success is the person upon whom final responsibility rests, the project

manager. She is the official responsible for executing the project within the guidelines and controls of NASA, and for day-to-day supervision, execution, and completion of projects. Although most of the workers on a project are outside of the administrative authority of the project manager, nonetheless they take directions from her on any project matter.

Figure 1.3 NASA program and organization chart.

Each project manager has a counterpart in Washington, the program manager, who is the senior NASA official responsible for developing and administering headquarter’s guidelines and controls with respect to a given project. She must fight the battles for resource allocation within headquarters, work with all organizations participating in the project, relate the project to NASA’s broader goals, and testify to or justify authorizations from Congress or the President. The success of a project depends on the project and program managers working together and the quality of their relationship. An example is Case 17.4, the Mercury Exploration Program.

See Chapter 17

1.12 Miscellaneous Projects

If you still wonder about the myriad situations where project management applies, read on.

Maintenance

All major facilities and machines require maintenance work that takes on project proportions—everything from small repairs and preventative maintenance jobs to scheduled shutdowns of big facilities like chemical plants and power generating plants. Airplanes are removed from service after a certain number of flight hours, stripped down to the component level, inspected, and portions replaced, repaired, or rebuilt. Projects like this put facilities and equipment out of operation and require project management to do quality work, fast.

Events

Mentioned in the Introduction are fundraising and political campaigns, and even weddings. Such projects if small can be handled without project management, but as they grow in size and complexity so do the merits of using project management. Many major sports events like the Olympic Games certainly need project managers, but so do smaller ones like league championships. Case 9.2, the FIFA 2010 World Cup, is an example.

Implementation of Change

Any form of large-scale change effort is a project. Examples include implementing a new corporate strategy, upgrading the safety and health provisions in the workplace, and establishing a new business unit. Applications of project management to such projects are illustrated throughout this book; see for

example: Case 1.2: Flexible Benefits System, and Case 3.1: West Coast University Medical Center.

1.13 Summary

The most important aspect of project management is the project manager, the person who functions to unify project-related planning, communications, control, and direction to achieve project goals. The project manager is the integrator who ties together the efforts of functional areas, suppliers, and contractors, and keeps top management and the customer apprised of project progress. Project management includes many things, but in particular the organization, systems, and procedures to enable the project manager to plan, organize, direct, and integrate everything necessary to achieve project goals.

Project management can be applied to any temporary, goal-oriented activity, but it becomes more essential as the magnitude, unfamiliarity, and stake of the undertaking increase. Organizations in rapidly changing business and technology environments especially need project management.

Project management takes on a variety of forms such as pure project, matrix, and program management forms. Consumer-oriented firms use new-venture and product-management forms that are similar to basic project management. Project management is applied in much the same way in commercial, nonprofit, government, and military projects, with variations to account for differences in the environments.

Project management is a “systems approach” to management. The next chapter expands on that concept and discusses the systems philosophy and methodologies that underlie much of project management theory and practice.

Review Questions

1. Making a film and carrying out a space mission are both expensive projects conducted by teams and subject to budgetary and schedule constraints. The technical expertise for landing a spacecraft on a planet is similar to that required to create the illusion of a spacecraft landing in a motion picture. Use the NTCP model described in the Introduction to indicate ways in which the two project types differ.

2. Describe five functions of management. Are any of these not performed by managers? How do you think each of these functions comes into play in the course of a project?

3. List the main characteristics of “projects.” How do these features distinguish projects from other, non-project activities?

4. What are the characteristics of “project management”? Contrast these to functional and other types of non-project management.

5. What makes project management more suitable to project environments than traditional management and organization?

6. Where did project management methods and organization originate? What happened during the twentieth century that made project management necessary?

7. What five criteria do Cleland and King suggest for determining when to use project management? From these, describe briefly how a manager should know when project management is appropriate for the task.

8. When is project management clearly not appropriate? List some “project-type” activities where you think project management should not be used. Describe organizations or kinds of work where both project and non-project types of management are appropriate.

9. Briefly compare and contrast the following forms of project management: pure project, matrix, program, new venture, product, and portfolio. Give at least one illustration of an organization where each one is used.

10. What are some of the problems of being a project leader in commercial,

government, and military projects? Where do organizations in these environments get project leaders?

11. In the industry, service sector, and government examples in this chapter, what common characteristics of the environment, the project goals, and the project tasks make project management appropriate (or necessary)? Also, what seem to be the common characteristics of the roles and responsibilities of the project managers in these examples? What are the differences?

12. Now that you know a little about projects and project management, list some government and private organizations where you think project management might be useful. You might want to check to see if, in fact, they are using project management.

Questions About the Study Project

1. In the project you are studying, what characteristics of the company, project goals, tasks, or necessary expertise make the use of project management appropriate or inappropriate? Consider the project size, complexity, risk, and other criteria in answering this question.

2. How does the project you are studying fit the definition of a project? 3. What kind of project management is used—program, product, new

venture, or other? Explain. Is it called “project management” or something else?

4. What functions does the project manager serve? What is his or her title? 5. In which way(s) does the industry of the study project differ from other

industries described in the chapter? Do the differences have an effect on how projects are managed?

Case 1.1 Disaster Recovery at Marshall Field’s18

Early one morning basements in Chicago’s downtown central business district began to flood. A hole the size of an automobile had developed between the river and an adjacent abandoned tunnel. The tunnel, built in the early 1900s for transporting coal, runs throughout the downtown area. When the tunnel flooded, so did the basements of buildings connected to it, some 272 in all, including that of major retailer Marshall Field’s.

The problem was first noted at 5:30 am when a member of Marshall Field’s trouble desk saw water pouring into the basement. He notified the manager of maintenance, who immediately contacted the Chicago Fire and Water Departments, and Marshall Field’s parent company, Dayton Hudson in Minneapolis. Electricity—and with it all elevator, computer, communication, and security services for the 15-story building—would soon be lost. The building was evacuated and elevators were moved above

basement levels. A command post was set up and a team formed from various departments such as facilities, security, human resources, public relations, and financial, legal, insurance, and support services. Later that day, members of Dayton Hudson’s risk management group arrived from Minneapolis to take over coordinating the team’s efforts. The team’s goal was to ensure the safety of employees and customers, minimize flood damage, and resume normal operations as soon as possible. They hoped to reopen the store to customers in a week.

An attempt was made to pump the water out; however, as long as the tunnel hole remained unrepaired, the Chicago River continued to pour back into the basements. Thus, basements remained flooded until the tunnel was sealed and the Army Corps of Engineers gave approval to start pumping. Everything in the second-level basement was a loss, including equipment for security, heating, ventilation, air-conditioning, fire sprinkling, and mechanical services. Most merchandise in the first-level basement stockrooms was also lost.

Electricians worked around the clock to install emergency generators and restore lighting and elevator service. Additional security officers were hired. An emergency pumping system and new piping to the water-sprinkling tank were installed so the sprinkler system could be reactivated. Measures were taken to monitor ventilation and air quality, and dehumidifiers and fans were installed to improve air quality. Within the week, inspectors from the City of Chicago and OSHA (Occupational Safety and Health Administration) gave approval to reopen the store.

After water was drained from Marshall Field’s basements, damaged merchandise was removed and sold to a salvager. The second basement had to be gutted to assure removal of contaminants. Salvageable machinery had to be disassembled and sanitized.

The extent of the damage was assessed and insurance claims filed. A construction company was hired to manage restoration of the damaged areas. Throughout the ordeal, the public relations department dealt with the media, being candid yet showing confidence in the recovery effort. Customers had to be assured that the store was safe. The team overseeing the recovery met twice a week to evaluate progress and make decisions, then

slowly disbanded as the store recovered. This case illustrates crisis management, an important element of which is

having a team that can move fast to minimize losses and quickly recover damages. At the beginning of a disaster there is little time to plan, though companies and public agencies often have crisis guidelines for responding to emergency situations. When an emergency occurs they then develop more specific, detailed plans to guide short- and long-term recovery efforts.

Questions

1. In what ways is the Marshall Field’s flood disaster recovery effort a project? Why are large-scale disaster response and recovery efforts projects?

2. In what ways do the characteristics of crisis management as described in this case correspond to those of project management?

3. Who was (were) the project manager(s) and what was his or her (their) responsibility? Who was assigned to the project team and why were they on the team?

4. Comment on the appropriateness of using project management for managing disaster recovery efforts such as this.

5. What form of project management (basic, program, and so on) does this case most closely resemble?

Case 1.2 Flexible Benefits System Implementation at Shah Alam Medical Center19

Senior management of Shah Alam Medical Center decided to procure and implement a new system that would reduce the cost and improve the service of its employee benefits coverage. The new system would have to meet four goals: improved responsiveness to employee needs, added benefits flexibility, better cost management, and greater coordination of human resource objectives with business strategies. A multifunctional team of 13 members was formed with representatives from four departments—Human Resources (HR), Financial Systems (FS), and Information Services (IS)—and six

technical experts from the consulting firm of Hun and Bar Software (HBS). Early in the project a workshop was held with participants from Shah

Alam and HBS to clarify and finalize project objectives and develop a project plan, milestones, and schedule. Project completion was set at 10 months. In that time HBS had to develop and supply all hardware and software for the new system; the system had to be brought on-line, tested, and approved; HR workers had to be trained how to operate the system and load existing employee data; all Shah Alam employees had to be educated about and enrolled in the new benefits process; and the enrollment data had to be entered in the system.

The director of FS was chosen to oversee the project. She had the technical background and had previously worked in the IS group in implementing Shah Alam’s patient care information system; everyone on the team approved of her appointment as project leader. She selected two team leaders to assist her, one each from HR and IS. The HR leader’s task was to ensure that the new system met HR requirements and the needs of Shah Alam employees. The IS leader’s task was to ensure that the new software interfaced with other Shah Alam systems.

Members of the Shah Alam team worked on the project on a part-time basis, spending roughly half their time on the project and the other half on their normal daily duties. The project manager and team leaders also worked part-time on the project, although each gave the project priority. Shah Alam’s senior management had made it clear that meeting project requirements and time deadlines was imperative. The project manager was given authority over functional managers and project team members for all project-related decisions.

Questions

1. What form of project management (basic, program, etc.) does this case most closely resemble?

2. The project manager is also the director of FS, one of several departments that will be affected by the new benefits system. Does this seem like a good idea? What are the pros and cons of her being selected?

3. Comment on the team members’ part-time assignment to the project and the expectation that they give the project top priority.

4. Much of the success of this project depends on the performance of team members who are not employed by Shah Alam, namely the HBS consultants. They must develop the entire hardware/software benefits system. Why was an outside firm likely chosen for such an important part of the project? What difficulties might this pose to the project manager in meeting project goals?

Endnotes

1. Adapted from Szilagyi A. Management and Performance, 2nd edn. Glenview, IL: Scott, Foresman; 1984;

pp. 7–10, 16–20, 29–32.

2. Portions of this section are adapted from Cleland D. and King W. Systems Analysis and Project

Management, 3rd edn. New York, NY: McGraw-Hill; 1983, pp. 191–192.

3. Portions of this section are adapted from Johnson R., Kast F., and Rosenzweig J. The Theory and

Management of Systems, 3rd edn. New York, NY: McGraw-Hill; 1973, pp. 395–397.

4. Cleland and King, Systems Analysis and Project Management, p. 259.

5. Based upon Hofer W. Lady Liberty’s business army. Nation’s Business July; 1983: 18–28.

6. Sharad D. Management by projects, an ideological breakthrough. Project Management Journal March;

1986: 61–63.

7. Adams J., Barndt S. and Martin M. Managing by Project Management. Dayton, OH: Universal

Technology; 1979, pp. 12–13.

8. Project Management Institute. The Standard for Program Management, 3rd edn. Newton Square, PA:

PMI; 2013; Office of Government Commerce. Managing Successful Programmes (MSP). UK: The

Stationery Office; 2007.

9. Project Management Institute. The Standard for Portfolio Management, 3rd edn. Newton Square, PA:

PMI; 2013; Office of Government Commerce. Management of Portfolios. UK: The Stationery Office; 2011.

10. This section is adapted from Roman D. Managing Projects: A Systems Approach. New York, NY: Elsevier,

1986; pp. 426–429, with the permission of the publisher.

11. This and examples in later chapters of SpaceShipOne illustrate concepts. Much factual information about

the project and the systems is available from published sources, but design and development information

of the systems is confidential. SpaceShipOne, the X-Prize, and the stakeholders described are all true-life,

but for lack of information portions of this and subsequent examples are hypothetical.

12. Based upon information compiled by Jenny Harrison from interviews with managers in Dalian

Company (factual company, fictitious name).

13. Based upon information compiled by Darlene Capodice from interviews with managers in the

accounting firm (factual company, fictitious name).

14. Information about this project contributed by Daniel Molson, Mike Billish, May Cumba, Jesper Larson,

Anne Lanagan, Madeleine Pember, and Diane Petrozzo.

15. Disaster Response. Lesson 7: Emergency Operations Support. University of Wisconsin, Disaster

Management Center, http://dmc.engr.wisc.edu/courses/response/BB08-07.html.

16. India: Emergency Tsunami Reconstruction Project. The World Bank Group, May 3, 2005, Press Release

No: 453/SAR/2005, ReliefWeb, http://www.reliefweb.int/rw/RWB.NSF/db900SID/VBOL-6C3CF8?

OpenDocument&rc=3&cc=ind

17. Portions of this section are adapted from Chapman R. Project Management in NASA: The System and

The Men. Washington, D.C.: NASA SP-324, NTIS No. N75-15692; 1973.

18. Information about this case contributed by Jennifer Koziol, Sussan Arias, Linda Clausen, Gilbert Rogers,

and Nidia Sakac.

19. Information about this case contributed by Debbie Tomczak, Bill Baginski, Terry Bradley, Brad Carlson,

and Tom Delaney. Organizational names are fictitious but the case is factual.

Chapter 2 Systems Approach

A project can be conceptualized as a system of people, equipment, materials, and facilities organized and managed to achieve a goal. Much of the established theory and practice about what it takes to organize and coordinate a project comes from a perspective called the “systems approach.” At the same time, work done in projects is often done for the purpose of creating systems, and such projects commonly employ methodologies such as “systems analysis” and “systems engineering.” This chapter introduces concepts that form the basis for project management and the systems methodologies used in technical projects.

2.1 Systems and Systems Thinking

By definition, the term system refers to “an organized or complex whole; an assemblage of things or parts interacting in a coordinated way.” The parts could be players on a football team, keys on a keyboard, or components in a machine. The parts can be physical entities or they can be abstract or conceptual, such as words in a language or steps in a procedure. Beyond being an “assemblage of parts,” however, a system has three other features:1

1. Parts of the system affect the system and are affected by it. 2. The assemblage of parts does something; it serves a purpose or goal. 3. The assemblage is of particular interest.

The first feature means that, in a system, the whole is more than the sum of the parts. The human body, for example, is comprised of separate components—the liver, brain, heart, nerve fibers, and so on; yet if any of these are removed from the body, both they and the body will change. Parts of the body cannot live outside the body, and without the parts, the body cannot live either. The idea of the parts affecting the whole and vice versa is central to systems thinking.

The second feature of systems is that the parts work in combination to do something. What they do can usually be observed in the outputs of the system or the way the system converts inputs to outputs (although sometimes that conversion process may be quite obscure). In a human-made system the parts are designed to interact to achieve some purpose or goal.

Third, systems are conceived by the people looking at them, which means they exist in the eye (or mind) of the beholder.2 What this says is that the conception of a system can be altered to suit one’s purpose. For example, in diagnosing the illness in a patient, a doctor may see the entire human body as “the system.” The doctor may send the patient to a specialist, who sees only the digestive tract as “the system.” If the diagnosis is food poisoning and the patient files suit, her attorney might expand the view of “the system” to include the restaurant where the patient last ate.

Systems thinking is a particular way of viewing the world, its key feature being a focus on “the big picture—the whole system or organism,” rather than just the parts of the system. Systems thinkers also look at the parts and try to understand the relationships among them, but they always step back to see how the parts fit into the whole.3 Systems thinking means being able to perceive the “system” in a situation; to take a seemingly confused, chaotic situation and perceive some degree of order or harmony in it. As such it is a useful way of dealing with complex human-created systems and endeavors such as large projects.

Although project managers must be familiar with and able to coordinate the individual parts of the project, most responsibility for each of those parts is delegated to the managers and technicians who specialize in them. Project managers are concerned with the “big picture”—the whole project with its goals, work tasks, and the people involved; as such, they must be systems thinkers.

2.2 Systems Concepts and Principles

The following concepts and principles apply to all systems.

Goals and Objectives

Human-made systems are designed to do something; they have goals and objectives that are conceived by people. For the intentions of this book, a goal is defined as a broad, all-encompassing statement of the purpose of a system, and an objective as a more-detailed, usually quantifiable statement of purpose pertaining to some aspect of the system. The system goal is met by achieving a group of system objectives.

A project can be conceptualized as a system that exists for the purpose of creating a human-made system. The goal of the project may be defined as, for example, “build a space station for $15 billion in 10 years.” Starting with the goal, the project can then be defined in terms of many objectives such as “select overall design for the station,” “select prime contractors,” “train crew,” “launch components into orbit,” “assemble components,” “do project for cost $15 billion,” and so on. The objectives can be broken down into more detailed, specific objectives called requirements. Requirements are the specific criteria to which the system and its parts must conform for the system to meet its overall goals and objectives.

Elements and Subsystems

Any system can be broken down into smaller parts. These parts in combination form “the assemblage of parts” that constitutes the system. The smallest part of a system is an element. A system can also be broken down into parts that are themselves systems, called subsystems. A subsystem is a system that functions as a component of a larger system. When it is not necessary to understand its inner workings, a subsystem can simply be thought of as an element. Figure 2.1, a

common organization chart, illustrates this: the production subsystem may be viewed as an “element” in the company; if we choose to delve into it, however, production becomes a subsystem with elements of scheduling, manufacturing, and inventory. Each of these elements could in turn be viewed as a subsystem containing elements. In a project, an element could be a unit of work, a person or group doing the work, or a component of the end-item being produced by the project.

Figure 2.1 A company portrayed in terms of systems, subsystems, and elements.

Attributes

Systems, subsystems, and elements all have distinguishing characteristics called attributes; these describe the condition of systems, subsystems, and elements in qualitative or quantitative terms. In human-made systems, the attributes are designed into the system so the system will perform as required. Often, the attributes of a system and its components are monitored to keep track of the system’s behavior and performance. In a project, time and cost are universal attributes of most of its elements, and they are tracked to assess the project’s performance.

Environment and Boundary

The term environment refers to anything outside the system that influences the behavior or outcome of the system. In human-made systems it usually refers to things over which system designers and managers have no control. The environment can include, for example, the community or society we live in, the air we breathe, or the people with whom we associate—although it is not necessarily any of these. A system is separated from its environment by a boundary. In many systems the boundary is somewhat obscure and it is difficult to separate the system from its environment. To determine what the environment is, ask the questions “Can I do anything about it?” and “Is it relevant to the system and its objectives?” If the answer is “no” to the first question but “yes” to the second, then “it” is part of the environment. The following table shows how to distinguish a system from its environment:

Is it relevant to the system? Yes No

Can system designers or managers control it? Yes System Irrelevant No Environment Environment

“Irrelevant environment” includes all things that do not influence the system and that do not matter. To a project manager the planet Jupiter is in the irrelevant environment—unless her project is to send a space probe there, in which case Jupiter is relevant and, hence, part of the project environment. From here on, mention of the environment will always refer to the relevant environment—

factors that matter to and affect the system in some way, but have to be lived with.

System Structure

Elements and subsystems are linked together by relationships. The form taken by the relationships is referred to as the structure of the system. The functioning and effectiveness of a system is largely determined by the “appropriateness” of the structure to the system’s objective or purpose. Most complex systems have hierarchical structures consisting of organized levels of sub-elements within elements, elements within subsystems, and so on.

Figure 2.2 is an example of a hierarchical structure. It shows a project as a hierarchy of tasks and responsibilities. Element X represents the entire project; elements A, B, and C are areas of work or management divisions in the project; elements a through g are specific work tasks. The structure implies that tasks a, b, and c are all subsumed under management division A, tasks d and e are under division B, and so on. This structure is called a work breakdown structure and is explained more in Chapter 5.

See Chapter 5

Inputs, Process, Outputs, Interfaces

Figure 2.2 One way to conceptualize project structure.

Systems achieve goals and objectives by converting inputs into outputs through a defined process. This is illustrated in Figure 2.3. Outputs represent the end-result of a system and, generally, the purpose for which the system exists. All systems have multiple outputs, including desirable ones that contribute to system objectives, neutral ones, and undesirable or wasteful ones that detract from system objectives and/or negatively impact the environment. Subsystems and most elements have inputs and outputs too.

Figure 2.3 Input–process–output relationship.

Inputs are the raw materials, resources, or steps necessary for the system to function and produce outputs. They include controllable factors such as labor, materials, information, capital, energy, and facilities, as well as uncontrollable factors such as weather and natural phenomena (i.e., the environment). Inputs that originate from the system itself are called feedback. For example, all systems produce information; usage of that information for guiding system behavior is called feedback input. Process (also termed function) is the means by which the system physically

converts or transforms inputs into outputs. An important aspect of system design is to create a process that effectively produces the desired outputs and meets system objectives, yet minimizes consumption of inputs and production of wasteful outputs.

In a hierarchical structure where systems are divided into subsystems, the subsystems each have their own inputs, process, and outputs that are interconnected in some way. In Figure 2.2, each of the project elements produces outputs, some of which become inputs for other elements. Two elements where the output of one becomes the inputs of the other are said to interface.

Constraints and Conflicts

All systems have constraints or limitations that inhibit their ability to reach goals and objectives. Often the constraints are imposed by the environment. Time and money are two universal constraints in projects.

In human-made systems, and especially in projects, the objectives of the subsystems are sometimes in conflict, which reduces the chances that they or the goal of the overall system will ever be realized. Removing conflict from objectives to enable meeting the goal of the overall system is called integration.

Integration

For a system to achieve its goal, all of its elements, the “assemblage of parts,” must work in unison. Designing, implementing, and operating a system that achieves its prespecified objectives and requirements through the coordinated (so-called “seamless”) functioning of its elements and subsystems is called system integration. Project management seeks to integrate tasks and resources to achieve project goals. In technological projects, project management also addresses the integration of the phys cal components and modules that compose the project end-item. The subject of systems integration is covered in Chapter 14.

See Chapter 14

open Systems and Closed Systems

Systems can be classified as closed or open. A closed system is one that is viewed as self-contained, and “closed-systems thinking” means to focus on the internal operation, structure, and processes of a system without regard to the environment. For some kinds of systems closed-system thinking applies: to understand how a machine functions, you need only study the machine, its components, and not anything else. This does not mean that the environment does not affect the system, but only that the person looking at the system has

chosen to ignore the environment. For analyzing or improving the design of many kinds of mechanical systems, closed-system thinking works fairly well.

But what about systems that interact with and must be adaptive to the environment? These are open systems. To understand their behavior and functioning, you cannot ignore the environment. Since mechanical systems rely upon resources from and inject byproducts (e.g. pollutants) into the environment, in many cases they too should be treated as open systems. In fact, any systems that must be adaptable to the environment, including projects, must be treated as open systems.

Organizations and Environment4

As open systems, human organizations interact with stakeholders in the environment (customers, suppliers, unions, stockholders, governments, etc.) and rely upon the environment for inputs of energy, information, and material. In turn, they export to the environment outputs of goods, services, and waste (represented in Figure 2.4).

As an open system, any organization must choose goals and conduct its operations so as to respect opportunities presented and limitations imposed by the environment. Cleland and King call this the “environmental problem,” meaning that a manager must:5

1. appreciate the need to assess forces in the environment 2. understand the forces that significantly affect the organization, and 3. integrate these forces into the organization’s goals, objectives, and

operations.

To the extent that every project is influenced by outside forces, the project manager must try to understand these forces and, having done that, be able to guide the project to its goal. A project that is predominantly influenced by divergent forces in the environment will be difficult to control and likely to fail.

Natural Systems and Human-Made Systems

Figure 2.4 Organization as an input–output system.

Systems can also be classified as either natural or human-made. Natural systems originated by natural processes (e.g. organisms and planetary systems). Human- made systems are designed and operated bypeople (e.g. communication systems and human organizations). Projects are human-made systems (organizations) created for the purpose of creating other human-made systems.

Natural systems can be altered by or become intertwined with human-made systems. An example is the alteration of a river system and formation of a lake by building a dam; another is the alteration of the composition of atmosphere and ecosystem through CO2 introduced by human-made machines.

Human-made systems are embedded in and utilize inputs from natural systems, and both systems interact in important and significant ways. In recent years the appearance of large-scale human-made systems has had a significant, mostly undesirable, impact on the natural world. Examples include global warming, acid rain, and toxic contamination of water systems. Such consequences, referred to as “side effects,” arise largely because system designers and users fail to consider (or chose to ignore) the impacts of human-made systems on the natural environment.

2.3 Systems Approach

The systems approach is a way to visualize and analyze physical things and conceptual systems, but more than that it is an approach for doing things—a framework for abstracting problems, solving problems, and making decisions.

Systems Approach Framework

The systems approach framework utilizes systems concepts such as goals and objectives, subsystems, elements, relationships, integration, and environment. It formally acknowledges that the behavior of any one element may affect other elements and no single element can perform effectively without help from the others. This recognition of interfaces, interdependency, and cause-effect among elements is what most distinguishes the systems approach.6

Managers who adopt the systems approach recognize the multitude of “elements” in the systems they manage and the problems they need to solve, the relationships among the elements, and reciprocal influences between human- made systems and the environment. As a result, they are better able to grasp the full magnitude of a problem and anticipate consequences of their actions. This reduces the chances that important elements in a situation or consequences of actions will be overlooked.

The systems approach keeps attention on the big picture and the ultimate goal; it allows focus on the parts of the system, but only in regard to the parts’ contributions to the whole. For instance, a university system can be viewed as separate elements of students, faculty, administrators, and alumni, and it is possible to take action regarding any one of them while ignoring impacts on the others and the environment. But actions that focus exclusively on parts of the system are likely not optimal for the total system because they disregard negative repercussions on other parts of the system. For example, although curtailing the hiring of faculty reduces costs, it can also lead to larger class sizes and classroom overcrowding, less faculty time for research, fewer research grants, lower prestige

to the university, and ultimately, lower enrollments and less revenue. Similarly, enacting laws is one way to reduce air pollution, but laws that restrict industry can damage local economies. Every problem is inextricably united to the environment, and attempts to solve it may cause other problems. Churchman calls this the “environmental fallacy.”7

Examples abound of situations where solutions for part of the system have led to worse problems for the whole. These include trying to reduce traffic congestion by building more highways, trying to eliminate drug abuse by outlawing drug sale and consumption, and trying to increase the appeal of wilderness areas by building resorts in national parks. The negative consequences of these problem-solving attempts are well known. The systems approach tries to avoid the environmental fallacy.

Orderly Way of Appraisal8

The systems approach is a methodology for solving problems and managing systems. By its holistic nature, it avoids tackling problems narrowly, head-on. It says, “Let’s stand back and look at this situation from all angles.” The problem solver does this by keeping in mind the system concepts discussed, namely:

1. The goals and objectives of the system. 2. The environment of the system. 3. The resources and constraints of the system. 4. The elements of the system, their functions, attributes, and performance

measures. 5. The interface and interaction among the elements. 6. The management of the system.

The systems approach mandates hardheaded thinking about the goals and objectives of the system and real ways to measure them. Project management uses this kind of thinking: it begins with the mission or objectives of the system and, thereafter, organizes and directs all subsequent work to achieve those objectives. The stated objective must be precise and measurable in terms of specific performance criteria (the system requirements). Criteria are the basis for

ranking alternative solutions or courses of action to a problem. In a project, criteria for the end-item are referred to as user requirements and specifications, explained in later chapters.

The environment of the system (other systems, groups, or persons and natural systems that affect or are affected by the system) must also be identified—no easy matter because external forces are sometimes hidden and work in insidious ways. Looking to the future, questions must be raised about likely changes or innovations in the environment and how they will affect the system. The project manager needs to ask, what can happen on the “outside” that will affect the project and its outcomes?

The resources to be used to accomplish system goals must also be identified. These are assets or the means that the system utilizes and influences to its advantage; they include capital, labor, materials, facilities, and equipment. Most system resources are exhaustible. The system is free to utilize them only for as long as they are available. When resources are depleted they become constraints. In the systems approach, the project manager considers the resources needed and available to the project.

The systems approach identifies the key elements of the system. In a project there are actually two systems, the one being produced by the project (this is the project end result or end-item) and the one producing the end-item (this is the project itself). Defining these involves defining, on the one hand, the subsystems, components, and parts of the hardware or software end-item system being produced, and, on the other hand, the work tasks, resources, organization, and procedures of the project. This topic is elaborated in Chapter 4.

See Chapter 4

The output of a system results not just from the individual elements, but from the way the elements interact. Thus, designing a new system or resolving problems in a human-made or natural system requires understanding the way the elements interface and interact. Designers use “models” of the system to help understand how the elements interact and how altering the elements and their relationships impact system behavior and outputs.

Finally, the systems approach pays explicit attention to the management of the

system, that is, to its planning and control, taking into consideration its objectives, environment and constraints, resources, and so on. This is precisely the role of project management.

The preceding concepts are not necessarily addressed in the sequence they are listed. In actuality each concept might need to be dealt with several times before it is completely described and clearly defined. More importantly, each concept serves to suggest numerous open-ended questions that aid in investigating the system:9 What are the goals, objectives, and criteria? What are the elements? What are the relationships among them? What functions should each perform? What are the resources? What are the tradeoffs among resources?

Systems Models

Systems thinkers use “models” to help understand systems and assess alternative plans and solutions against goals. A model is a simplified representation of a system; it abstracts the essential features of the system under study. It may be a physical model, mathematical formulation, computer simulation, or simple checklist. An example of a physical model is a model airplane. It is a scaled-down abstraction of the real system. It includes some aspects of the system (configuration and shape of exterior components) and excludes others (interior components and crew). Another kind of model is a conceptual model; it depicts the elements, structure, and flows in a system. The conceptual model in Figure 2.5, for example, helps demographers to understand relationships among the elements contributing to population size and make predictions.10

Models are used to conduct experimentation and tests. Many human-made systems are too expensive or risky to do “real-life” experiments on. The model permits assessment of various alternatives and their consequences before committing to a decision. Engineers use model airplanes in wind tunnel tests, for instance, to try out design alternatives and measure the effect of different design parameters on airplane performance. A good model allows designers and analysts to ask “what if” questions and explore the effects of altering the various inputs. It takes into account the requirements, relevant elements, resources, and constraints, and allows the consequences of different alternatives to be compared

in terms of costs and benefits. Models employed for quality assurance are discussed in Chapter 9.

See Chapter 9

Systems Life Cycles

Figure 2.5 A generalized population sector model.

Natural and human-made systems change over time in a way that tends to be systematic and evolutionary, and similar kinds of systems follow similar cycles of evolution. One basic cycle, that of all organisms, is the pattern of conception, birth, growth, maturity, senescence, and death. Each of these can be thought of as a life “stage” or event. Historically, even civilizations and societies have followed this pattern. Nonliving, electro-mechanical systems also follow a cycle with the stages of design, fabrication, installation, burn-in, normal operation, and deterioration or obsolescence. Similarly, all products follow a cycle—the “product life cycle,” which consists of the stages of conception, design, development, production, launch into the market, capture of market share, then decline and

discontinuation. Products such as cell phones may have life cycles only months- long; others (Kool-Aid and Levi’s jeans) have decades-long cycles.11 As mentioned in Chapter 1, virtually all human-made systemsstart out as projects, and most projects also follow a cycle called the project life cycle.12 This is discussed in Chapter 3.

See Chapter 3

2.4 Systems Engineering

Systems engineering, an application of the systems approach, is defined as “the science of designing complex systems in their totality to insure that the component subsystems making up the system are designed, fitted together, checked and operated in the most efficient way.”13 It refers to the conception, design, and development of a complex system wherein the components themselves must be designed, developed, and integrated together to fulfill the system objectives. Systems engineering is a way to bring an entire system into being and to account for its entire life cycle—including operation and phase-out— during its early conception and design.

All Systems Go

An example of systems engineering is the design and operation of a space vehicle. The expression “all systems go,” popularized during the early US space flights, means that the overall system of millions of components that make up the space vehicle and its support systems, and the hundreds of people in its technical and management teams, is ready to “go” to achieve the objectives of the mission.

To get to the point of “all systems go” planners must first have defined the overall system and its objectives. Designers must have analyzed the requirements of the system and broken them down into detailed, focused requirements, and have designed the components and subsystems that meet the requirements. They must then have built and combined the components into subsystems, and the subsystem into the total system of space vehicle, rocket boosters, launch facilities, ground support, crew selection and training, and technical and management capability. In the end, every component and person must be assigned a role and be integrated into a subsystem that has been integrated into the overall system.

Systems engineering applies to any system (hardware or software) that must be developed (perhaps from scratch), implemented, and operated to fulfill some immediate or ongoing future purpose. Examples can readily be found in the

design and implementation of local, national, and global systems for communication, transportation, water purification and supply, power generation and transmission, research, and defense.

Overview14

Systems engineering can be described in terms of the three dimensions illustrated in Figure 2.6.

First, it is a multidisciplinary effort. Systems engineers (parties responsible for oversight of designing and building the system) work with the system’s stakeholders to determine their needs and what the system must do to fulfill them. A stakeholder is any individual or group that affects or is affected by the system; the primary stakeholders are customers, builders, and end users. Customers finance and own the system; builders design and create it; users operate and maintain it. Stakeholders’ objectives and needs are the basis for determining the system requirements that specify what the system will do. The practice of involving key stakeholders in the early phases of the system conception and development is called “concurrent engineering,” discussed in Chapters 4 and 14.

See Chapter 4 and Chapter 14

Second, systems engineering addresses all aspects of the system, starting with the whole system and ending with its individual elements. System elements, modules, and subsystems are designed to perform the functions necessary to satisfy the objectives and requirements of the whole system. This aspect of systems engineering focuses on how the system must function to meet the requirements. Of course, none of the elements and subsystems function independently. All rely on the outputs of other functions and, in turn, provide inputs to still others; in a word, they interface. Systems engineering addresses how they should interface and the necessary interactions between them.

Figure 2.6 Dimensions of systems engineering.

Finally, in the creation and development of the system, systems engineering also takes into account how the system will be produced, operated, maintained, and finally disposed of—the system’s full life cycle, cradle to grave. This helps assure that the system will be economical to develop, build, operate, and maintain, and friendly to users and the environment. A multidisciplinary team approach that involves all the system’s stakeholders promotes this life cycle kind of thinking.

Once systems engineers have learned what stakeholders want and defined the objectives and requirements of the system, they then look for ways to meet the requirements. This involves research, analysis, and studies of alternative approaches to the system design, and the estimated costs, schedules, risks, and benefits associated with each. Says Brooks, “The hardest part of building a

[system] is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements [and] no other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”15

Example: Advanced Automation System16

The centerpiece of the Federal Aviation Administration’s (FAA) program to modernize the air traffic control system was the Advanced Automation System (AAS), which would provide controllers with new displays and computer equipment for processing radar and flight data. The FAA awarded the contract for AAS to IBM following a 4-year design competition. Requirements from the FAA initially filled a thick book, but as the program progressed they kept increasing and eventually grew to a stack 20 feet high. As the number of requirements grew, so did program delays, costs, and tensions between the FAA and IBM. Congress balked, and after 10 years and an estimated $1.5 billion it cancelled the program.

Eliciting the expectations and needs of operators and users and then translating them into measurable requirements can be difficult for engineers, which is why the multidisciplinary teams sometimes include behaviorists and psychologists. Developing the flight deck for a commercial aircraft, for example, would include the suggestions of pilots, the airlines, pilot associations, and human factors experts. A common way to elicit responses to or suggestions about a proposed design is for users to try out a mockup or simulator of the system.

Modularization: Iterative Analysis-Synthesis-Evaluation Cycle17

The process of creating a system concept is a series of steps to define the subsystems and elements that will comprise the system. The process is illustrated by Forsberg and Mooz’s “V-model” in Figure 2.7.18 It involves iterative cycles of (1) top-down analysis of details (i.e. decomposing the system into smaller parts),

(2) bottom-up synthesis (building up and integrating the parts into successively larger parts), and (3) evaluation (checking to see that results meet requirements).

Systems are designed and assembled from subsystems that themselves are designed and assembled from subsystems, and so on. The practice, called modularization, is what makes the design, assembly, and operation of complex systems feasible and practical. Herbert Simon gives the example of a watch- maker who assembles a watch of 100 parts. The process requires concentration and is time consuming and expensive. If the watch should need repair, finding and fixing the problem might be difficult. If instead the watch were made of ten modules, each with ten parts, assembly will be simple. If the watch develops a problem, the repair will be simple: just identify the module with the malfunction and replace it.19

Figure 2.7 Forsberg and Mooz’s V-model.

Soource: Adopted from Forsberg K. and Mooz H. in Software Requirements Engineering, 2nd edn, Taylor R.,

Dorfman M., and Davis A. (eds). Los Alamitos, CA: IEEE Computer Society Press; 1997, pp. 44–77.

The top-down stroke of the V represents subdividing the functions of the system into subfunctions and requirements. At each lower level the process of working with customers to define requirements repeats, except the “customer” becomes the function at the next higher level and the question becomes: “What

must the lower-level functions do to meet the requirements of the higher-level function?” In this way, requirements are defined for functions at all levels.

Systems are designed by designing subsystems or modules that each performs a necessary function of the system. Functions are the means by which a system meets its objectives and requirements. In everyday systems it is easy to identify the modules and the functions they perform. A desktop computer is almost completely modularized: it has a processor and controllers, drives, and peripheral devices that each performs a specialized function such as data processing, data storage, and input/output processing.

The way in which system functions are grouped into modules is called the system architecture. The architecture of an airplane is an example: an airplane must perform several major functions including propulsion, lift, and payload stowage; the visibly familiar modules of engines, wings, and fuselage, respectively, serve these functions. But each function is itself a composite of several subfunctions, hence each module is comprised of several submodules. A wing, for example, is subdivided into ailerons, flaps, spoilers, etc., each of which performs a specific aerodynamic function.

The bottom-up stroke of the V represents assessing “design alternatives” to satisfy requirements, implementing design decisions, converting designs into physical parts, integrating the parts, and verifying that the integrated parts meet the requirements. Design alternatives are the potential solutions to problems; they are the courses of action for meeting requirements; ultimately they show up in the final system as pieces of hardware and software. The chosen alternatives result in procuring or designing and building component parts. Components are checked individually and then assembled into modules; modules are tested, then combined with others and tested again.

If tests reveal that parts or modules are not meeting requirements, then the process returns to the downstroke of the V to determine why, and the analysis- synthesis-evaluation cycle repeats. As illustrated by the many dashed arrows in Figure 2.7, the process moves back and forth within each top-down/bottom-up stroke; at times during the upstroke it loops back and over to the downstroke.

One rule of the systems approach is “Don’t rush to solutions! Look for alternatives.” Multidisciplinary teams are good at considering alternative solutions; they combine knowledge from experts in disparate areas and can

generate alternatives that transcend any one person’s or field’s area of expertise. The design and development of complex technical systems can be vexing, but

systems engineering offers a way to do it. In practice, systems engineering follows a process very similar to the project life cycle, described in Chapter 3, and it employs practices for defining systems, described in Chapter 4. But whereas the project life cycle applies to generic projects, systems engineering applies more specifically to complex, usually technical, projects. Steps and tools that characterize systems engineering are covered in Appendix A to Chapter 4.

See Chapter 4

2.5 Project Management: A Systems Approach20

Project management is a systems approach to management: it is total-system oriented and emphasizes achievement of the overall mission and objectives of the project; it emphasizes decisions that optimize the overall project rather than the elements or subsystems of the project; and it recognizes interaction and synergy among elements of the project—that outputs from one element provide inputs to other elements. The project manager recognizes interactions and interdependencies between project elements and with the environment, and he works to ensure that organizations, responsibilities, knowledge, and data are integrated toward achieving overall project objectives. This contrasts with the more typical management view, which is to focus narrowly on individual functions and tasks and on the performance of individual departments, even if at the expense of the total organization.

In Winning at Project Management, author Robert Gilbreath21 describes the “right” way to visualize a project. From an outsider’s perspective, he says, a project may look like something with no separate discernable parts, like a barrel containing thousands of earthworms. Obviously, if you have to manage the project such a perspective is not very useful and you need another perspective, one that involves subdividing the continuum into a collection of elements and defining the characteristics of each.22 Good project managers, says Gilbreath, conceptually subdivide the project into pieces and make sure each piece is well managed. The project manager knows all the pieces of the project and how each impacts the others and the overall project.

Gilbreath discusses another feature of project managers: the ability to “change focus,” to zoom-in on the performance of discrete elements, then zoom-out and check the direction and performance of the overall project. The zoom-out view is essential for it enables the project manager to direct the project toward its goals and not get hung-up with the pieces.23 In other words, the project manager needs to be a big-picture person who knows how to balance focus between technical elements of the project and the administrative aspects of schedules, budgets, and human relations. The ability to zoom-in and zoom-out, to see and know what is

important to the big picture—that is the essence of the systems approach. Whether or not you call it the “systems approach” the point is, in managing a project it helps to think of a project as a system.

2.6 Summary

A system is an assembly of parts where (1) the parts are affected by being in the system, (2) the assembly does something, and (3) the assembly is of particular interest. What is called “the system” depends upon one’s point of view and purpose. Projects are systems created for the purpose of making systems.

Systems thinking is a way to deal with complex phenomena. It imparts the ability to discern a degree of order and structure in a seemingly confused or chaotic situation. Systems thinking includes the “systems approach,” which is a way of conceptualizing physical entities and addressing problems. The principle components of the systems approach are (1) the objectives and the performance criteria of the system, (2) the system environment and constraints, (3) the resources of the system, (4) the elements of the system, their functions, attributes, and performance measures, (5) the interaction among the elements, and (6) the management of the system. For development and operation of large technical systems, the systems approach is implemented through the systems engineering methodology.

Part I of this book has given you an overview of project management. Projects are of finite duration—they have a beginning and an ending. What happens in between—the stages of tasks and activities—tends to be remarkably similar, regardless of the kind of project. These stages are analogous to stages in the system life cycle and were alluded to in the examples in Chapter 1. Part II discusses these stages and describes a framework for conducting projects: the systems development cycle.

Review Questions

1. What distinguishes systems thinking from analytical thinking? Is systems thinking something new or is it just another perspective? Explain.

2. Define “system.” What notable features enable you to see something as a system? Describe briefly the American legal or education system in terms of these features.

3. How can several people looking at the same thing see the “system” in it differently?

4. Define the following concepts and explain how they fit into systems thinking: objectives, elements, subsystems, attributes, environment, boundary, structure, inputs, outputs, process, and constraints.

5. Describe the difference between open and closed systems, and between human-made and natural systems. Are all natural systems open systems?

6. Is a space vehicle an open system? Is an organization an open system? Explain.

7. Describe the systems approach. Where does the systems approach apply? Explain in a sentence what a manager does in the systems approach that she might not do otherwise.

8. What is the “environmental fallacy”? 9. What things does the problem solver keep in mind when applying the

systems approach? 10. Describe how the following elements of the systems approach apply to

projects and project management: objectives, environment, resources, subsystems, and management.

11. Give some examples of physical models; of graphical models; of mathematical models.

12. What is the systems life cycle? What is the systems development cycle? 13. Discuss the dimension of systems engineering in Figure 2.6. 14. What is modularization? What are its benefits in system design and

operation? 15. In systems engineering the first stage is identification. Identification of

what? 16. Who are the stakeholders in systems engineering? 17. What are requirements? What aspects of the system or stakeholder

needs should the requirements incorporate? 18. Distinguish stakeholder requirements and system requirements. 19. Why is project management a systems approach? 20. What is the relevancy of the systems approach to project management?

Questions About the Study Project

1. Conceptualize the project organization (the project team and the parent organization of the team) you are studying as a system. What are the elements, attributes, environment, and so on? What are its internal subsystems—functional breakdown and management-hierarchy subsystems? What is the relevant environment? Who are the decision makers?

2. Describe the role of the project manager with respect to these subsystems, both internal and external. What is the nature of his or her responsibilities in these subsystems? How aware is the project manager of the project “environment” and what does he or she do that reflects this awareness?

3. Now, conceptualize the output or end-item of the project as a system. Again, focus on the elements, relationships, attributes, subsystems, environment, and so on. All projects, whether directed at making a physical product (e.g. computer, space station, skyscraper, research report) or a service (e.g. giving consultation and advice), are devoted to producing systems. This exercise will help you better understand what the project is doing. It is also good preparation for topics in the next chapter.

4. If the study project involves engineering or integration of many components, was the systems engineering process used? Is there a section, department, or task in the project called systems engineering? If so, elaborate. Are there functions or phases of the project that seem to resemble the systems engineering process?

5. As described in this chapter, besides the main end-item or operating system (i.e., the output objective of the project), systems engineering also addresses the support system—that system which supports installation, operation, maintenance, evaluation, and enhancement of the operating system. Describe the support system in the study project and its development.

6. Were the stakeholder requirements clearly defined at the start of the project? Were system requirements clearly defined? What are the requirements? In your opinion, were stakeholders identified and involved early in the project. Were their needs identified and addressed? Did the project deliver a system that met their needs?

Case 2.1 Glades County Sanitary District

Glades County is a region on the Gulf Coast with a population of 600,000. About 90 percent of the population is located in and near the city of Sitkus. The main attractions of the area are its clean, sandy beaches and nearby fishing. Resorts, restaurants, hotels, retailers, and the Sitkus/Glades County economy in general rely on these attractions for tourist dollars.

In the last decade, Glades County has experienced a near doubling of population and industry. One result has been the noticeable increase in the level of water pollution along the coast due primarily to the increased raw sewage dumped by Glades County into the Gulf. Ordinarily, the Glades County sewer system directs effluent waste through filtration plants before pumping it into the Gulf. Although the Glades County Sanitary District (GCSD) usually is able to handle the county’s sewage, during heavy rains the runoff from paved surfaces exceeds sewer capacity and must be diverted past filtration plants and directly into the Gulf. Following heavy rains, the beaches are cluttered with dead fish and debris. The Gulf fishing trade also is affected since pollution drives away desirable fish. Recently, the water pollution level has become high enough to damage both the tourist and fishing trade. Besides coastal pollution, there is also concern that as the population continues to increase, the county’s primary fresh water source, Glades River, will also become polluted.

The GCSD has been mandated to prepare a comprehensive water waste management program that will reverse the trend in pollution along the Gulf Coast as well as handle the expected increase in effluent wastes over the next 20 years. Although not yet specified, it is known that the program will

include new sewers, filtration plants, and stricter anti-pollution laws. As a first step, GCSD must establish the overall direction and mission of the program.

Questions

Answer the following questions (given the limited information, it is okay to advance some logical guesses; if you are not able to answer a question for lack of information, indicate how and where, as a systems engineer, you would get it):

1. What is the system? What are its key elements and subsystems? What are the boundaries and how are they determined? What is the environment?

2. Who are the decision makers? 3. What is the problem? Carefully formulate it. 4. Define the overall objective of the water waste management

program. Because the program is wide-ranging in scope, you should break this down into several sub-objectives.

5. Define the criteria or measures of performance to be used to determine whether the objectives of the program are being met. Specify several criteria for each sub-objective. As much as possible, the criteria should be quantitative, although some qualitative measures should also be included. How will you know if the criteria that you define are the appropriate ones to use?

6. What are the resources and constraints? 7. Elaborate on the kinds of alternatives and range of solutions to

solving the problem. 8. Discuss some techniques that could be used to help evaluate which

alternatives are best.

Case 2.2 Life and Death of an Aircraft

Development Project

Law and Callon24 describe the history of a large British aerospace project in terms of two entities: the global system and the project itself. The global system comprised parties and organizations outside the project that had a stake in the project; the project comprised everything within the project, including all work and the organizations contracted to do it.

The Global System

The principle stakeholders in the global system were:

1. The Royal Air Force (RAF), which initiated the project with a request for a new supersonic aircraft with short take-off capability. The aircraft would be a “tactical strike and reconnaissance fighter” called TSR.

2. Ministry of Defence (MOD), which wanted an aircraft that would best fit the nation’s current overall defense needs.

3. The Treasury, which wanted an inexpensive aircraft that would have market appeal for sale outside the UK, such as to the Royal Australian Air Force (RAAF).

4. The Royal Navy, which wanted to buy a different aircraft but was under pressure by MOD to buy the TSR.

5. The Ministry of Supply (MOS), which wanted an aircraft that would be produced by a consortium of several UK airframe and engine manufacturers.

As typical of most projects, each stakeholder in the global system conceptualized the project differently: to the RAF and MOD it would yield an aircraft for a specific mission; to the Treasury it would fit the defense budget and generate revenue; to the Navy it was a competitive threat to the aircraft they really wanted; and to the MOS it was an instrument of industrial policy. The parties had different reasons for contributing resources and support: some were economic (in return for funds, an aircraft would be built); some political (in return for a demonstrated need, objections of the Navy would be overruled); some technical (in return for engineering and technical effort, the aircraft would meet RAF performance requirements); and some industrial (in exchange for contracts, the aircraft industry would be consolidated).

The Project

The Treasury would not approve project funding until the aircraft’s basic design, manufacturer, cost, and delivery date were defined. The RAF and MOD sent requests to the aircraft industry for design ideas and selected two manufacturers; Vickers Corp. and English Electric (EE). They favored Vickers for its integration capability (combining aircraft, engine, armaments, and support equipment into a single weapons package), but they also liked EE for its design experience with supersonic aircraft. So they decided to contract with both companies and adopt a design that would utilize features from both. The idea was approved by all other parties in the global system and funding for the project was released.

The project grew as Vickers and EE hired subcontractors and expanded their teams for design, production, and management. The two companies and several other contractors merged to form a single new organization called the British Aircraft Corporation (BAC).

Relationships Between the Global System and the Project

As the project grew so did the problems between it and the global system. MOS wanted centralized control over all aspects of the project and all transactions between the project and stakeholders in the global system. Although BAC was the prime contractor and ostensibly responsible for managing the project, MOS would not confer upon it the necessary management authority. Rather, MOS formed a series of committees with members from the global system and gave them primary responsibility to manage the project. This led to serious problems:

1. The committees were allowed to make or veto important project- related decisions. They, not BAC, awarded important contracts; when the RAF wanted to change its requirements, it consulted with the committees, not with BAC.

2. The committees often lacked sufficient information or knowledge. Technical committees made decisions without regard to costs; cost committees made decisions without regard to technical realities. Decisions focused on particular aspects of the project; seldom did they account for impacts on other parts of the project or the project as a whole.

Distrust grew between BAC and MOS; neither was able to effectively integrate the resources, information, and decisions flowing between parties in the project and the global system. Subcontractors became difficult to control. Many ignored BAC and worked only with MOS and RAF to get favorable treatment.

Global System Reshaped

Everyone knew the project was in trouble. Project costs doubled. One of the test engines exploded and the RAF recognized it would take years to understand the cause. In addition, the RAAF announced that it would not order the TSR but instead was buying the US-built F-111. Opposition to the project grew and in the upcoming general election the Labour Party promised that if elected it would review the project. When the Labour Party won, it immediately began an assessment of the project, which included comparing the TSR to the F-111—considered by now an alternative to the TSR. As cost overruns and schedule delays continued, MOS slowly withdrew support. Then the RAF withdrew its support when it discovered that the F-111, which was already in production, would meet all of its requirements. The project was canceled.

Questions

1. In this case history, what is the “system”? What are its elements? What is the “environment”? What are the elements of the environment?

2. Describe the interaction between the system and its environment. 3. Do you feel that important decisions made in this project represent

“system thinking”? Explain. 4. Comment on the concept of “integration” in the project. How were

aspects of the project integrated or not integrated? 5. What are the main factors that contributed to cancellation of the

project? Which of these factors would you characterize as project management?

Case 2.3 Jubilee Line Extension Project25

The Jubilee Line Extension Project (JLEP) was an expansion of the London Underground (LU) system. It expanded LU through six London boroughs, linking Westminster to Docklands and Stratford. The project actually comprised 30 projects (i.e., it was a “program”) that included 22 km of tunnels, five underwater crossings, 11 new stations, and complex installations of machinery and equipment. Everywhere care had to be taken to ensure the safety of over 30 buildings in Central London. JLEP in many ways mirrors another large underground project—Boston’s Big Dig (see Cases 9.1 and 15.3).

Started in 1993 for an estimated £2.1 billion cost, JLEP was completed in

December 1999, 20 months behind schedule and over £1.4 billion over budget (at the time, the most expensive project in the world). Four major events contributed to the overruns:26

• Work stoppage to secure private sector funding. • Collapse of express tunnels at Heathrow Airport, which utilized the

same tunneling method in JLEP and necessitated a complete safety review of the method.

• Failure of the new signaling system. • Decision to site the Millennium Dome at Greenwich, for which JLE

was to be a major source for access.

Other contributors were the differences in contracts and resulting ambiguities over roles and responsibilities of the involved parties. Two kinds of contracts were used; one was based upon payment schedules and milestones, the other upon design and performance specifications. These differences later proved incompatible.

JLEP required significant design changes throughout the project; many of them were poorly controlled and managed or were approved post facto. Differences between early proposed designs and working design drawings were poorly communicated, and many designs were “frozen” by engineering and architectural groups even though elements of the design were still in the conceptual stage. Construction contractors were minimally involved in the design. The project team faced political pressure to complete JLE in time to serve as a main transport link to the Millennium Dome, which was then in- construction. Consequently it set an overly ambitious project deadline of 53 months.

The project was managed through the project director, project manager, and a large project team. Contractors were chosen independently and interfaces between them were not defined. This led to confusion and left the project team with the substantial task of managing all contractor interfaces and coordinating their work. Substantial changes in design and lack of clear targets and milestones led to difficulties in monitoring progress and applying the milestone payment system.

London Underground management treated JLE as a “bolt on” to the

existing railway line, i.e. it treated JLE as almost independent of existing transportation lines and communication systems to which it would be linked. The project team actually took the view that existing LU lines had nothing to do with them. Despite the fact that JLE would substantially increase the size of the LU system—and impact the system and be impacted by it—LU management viewed JLEP as simply a construction project whose ultimate operation would be independent of the overall LU system. Only a relatively small amount was budgeted to other parts of the LU to handle increased passenger traffic resulting from JLE. Early planning of JLE did not fully address operational issues, and it was more than a year after the project started that a plan for the operation of JLE was first addressed. The project was originally scheduled to go “online” all at once; only much later after setbacks was it decided that JLE would open in a phased manner.

JLEP was completed with no fatalities and has been successful in relieving congestion; several of its stations have received awards for architectural design; and JLE is cited as a contributor to the success of the 2012 London Olympic Games. But it was completed for £3.5 billion instead of the budgeted £2.1 billion and in 73 months instead of the planned 53 months, this despite a substantial reduction in its scope (replacing an intended new- technology signaling system with a traditional system).

Questions

1. The case illustrates a situation where the systems approach to design and management is necessary. Why is it necessary?

2. Is there evidence in the case to demonstrate that JLE planners and management used the systems approach or systems engineering? In your discussion, consider the following: JLE as a “system,” stakeholders’ identification and needs identification, requirements definition, interface management, and system operation.

Case 2.4 Santa Clara County Traffic Operations System and Signal Coordination Project27

The road infrastructure of Santa Clara County consists of (1) freeways managed by the state of California, (2) city streets and highways managed by individual municipalities, and (3) limited-access highways and signalized intersections managed by the county. The county conducted a study of the feasibility of integrating all of these traffic operations and signaling systems into one Intelligent Transportation System (ITS). The ITS would upgrade the county’s Traffic Operations Center, traffic signal system, communications, and intersection surveillance, and provide communication links with municipal control centers. The study identified interfaces among the disparate systems and described the ITS architecture. The project began in 1998 and within the legislated budget and 7-year timeframe the ITS was fully operational.

Among challenges experienced during the project were:

• Rapid changes in video-camera and video-transmission technology for traffic surveillance.

• Availability of new technologies to allow traffic signaling and ITS communication systems to transition from analog to digital Internet protocol.

• The “dot.com” boom, which affected the supply of fiber optic cabling and led to an 18-month delivery schedule and a potential doubling of costs.

A post-hoc analysis of the project conducted by the INCOSE Transportation Working Group concluded that the project’s management had taken the following major steps:

• Created a clear statement of the operational concept. • Developed system requirements. • Controlled the revision of the requirements during the design and

construction phases to accommodate changes in technology. • Clearly defined during the design stage the verification tests

necessary for acceptance of sub-systems. • Defined early in the project the performance measures to be used in

system validation.

The INCOSE group also concluded that the project’s management had effectively used risk management planning, especially regarding potential delivery delays due to shortages of fiber optic cable. Soon after the communications requirements were declared fixed, the client initiated procurement of the fiber cable and processes to incorporate the cable into construction contracts.

During system design and implementation, senior staff (both client and consultant) reviewed the user requirements and revised the design concept, which removed technological biases in requirements and made it possible to accommodate later revisions in technology.

Twelve years after the start of the project, communications protocols had changed. The modularity of the system design, however, enabled the system to be upgraded in stages without changing the equipment or underground

communication infrastructure.

Question

Although the project team did not intentionally set out to follow the systems approach, much of what it did, in fact, conformed to systems engineering practices. Compare the limited information provided about the project with the systems engineering concepts and V-model described in the chapter.

Endnotes

1. Naughton J. and Peters G. Systems Performance: Human Factors and Systems Failures. Milton Keynes,

UK: The Open University; 1976, pp. 8–12.

2. Ibid., 11. Innumerable systems can be perceived from any one entity. K. Boulding, in The World as a

Total System (Beverly Hills, CA: Sage, 1985) describes the world as physical, biological, social, economic,

political, communication, and evaluative systems.

3. Schoderbek P., Kefalas A. and Schoderbek C. Management Systems: Conceptual Considerations. Dallas:

Business Publications; 1975, pp. 7–8.

4. Kast F. and Rosenzweig J. The Modern View: A Systems Approach. In Beishon J. and Peters G. (eds),

Systems Behavior, 2nd edn. London, UK: Harper & Row; 1976, pp. 19–25.

5. Cleland D. and King W. Management: A Systems Approach. New York, NY: McGraw-Hill; 1972, p. 89.

6. Churchman C.W. The Systems Approach and Its Enemies. New York, NY: Basic Books, 1979.

7. Ibid., pp. 4–5.

8. Much of the discussion in this section is based on Churchman C.W. The Systems Approach. New York:

Dell; 1968, pp. 30–39.

9. Thome P. and Willard R. The Systems Approach: A Unified Concept of Planning. In Optner S. (ed.),

Systems Analysis. Harmondsworth, UK: Penguin Books; 1973, p. 212.

10. Hamilton H. Systems Simulation for Regional Analysis. Cambridge, MA: The M.I.T. Press; 1972.

11. The life cycle of technological products is eloquently described by Foster R. in Innovation: The Attacker’s

Advantage. New York, NY: Summit Books; 1986.

12. As common parlance, the term project life cycle is recognition that all projects tend to follow a similar

sequence of activities, start to finish. Since every project, however, has a start and finish, when referring

to a particular project the more precise term is project life span.

13. Jenkins G. The Systems Approach. In Beishan J. and Peters G. (eds), Systems Behavior, 2nd edn. London,

UK: Harper and Row; 1976, p. 82.

14. Auyang S. Engineering—An Endless Frontier. Cambridge, MA: Harvard University Press; 2004, pp. 175–

189.

15. Brooks F. The Mythical Man Month. Reading, MA: Addison Wesley; 1995, p. 199.

16. Auyang, Engineering—An Endless Frontier, p. 183.

17. Ibid., pp. 192–197.

18. Forsberg K. and Mooz H. In Taylor R., Dorfman M. and Davis A. (eds), Software Requirements

Engineering, 2nd edn. Los Alamitos, CA: IEEE Computer Society Press; 1997, pp. 44–77; V-model adapted

from reprint in Auyang, Engineering—An Endless Frontier, p. 197.

19. Herbert Simon, quoted in Auyang, Engineering—An Endless Frontier, p. 194.

20. Cleland and King, Management: A Systems Approach, pp. 171–173; and Johnson R., Kast K. and

Rosenzweig J. The Theory and Management of Systems, 3rd edn. New York, NY: McGraw-Hill; 1973, pp.

135–136.

21. Gilbreath R. Winning at Project Management. New York, NY: John Wiley and Sons; 1986.

22. Ibid., pp. 95–96.

23. Ibid., pp. 98–102.

24. From Law J. and Callon M. The Life and Death of an Aircraft: A Network Analysis of Technical Change.

In Bijker W. and Law J. (eds), Shaping Society/Building Technology. Cambridge, MA: MIT Press; 1992.

25. Information for this case is derived from three sources, all downloaded Oct. 30, 2014: (1) Project Profile,

Jubilee Line Extension. Omega Centre, University College London (no date),

http://www.omegacentre.bartlett.ucl.ac.uk/studies/cases/pdf/UK_JLE_PROFILE_120909.pdf; (2) Jubilee

Line Extension, London, UK (no date),

http://www.omegacentre.bartlett.ucl.ac.uk/studies/cases/pdf/UK_JLE_2P_080911.pdf; and (3) Systems

Engineering Case Study # 8 Jubilee Line Extension, Systems Engineering in Transportation Projects: A

Library of Case Studies, INCOSE Transportation Working Group, 2013,

http://www.incose.org/practice/techactivities/wg/transport/docs/CaseStudyLibrary_6_0.pdf.

26. Mitchell, B. Jubilee Line Extension: From Conception to Completion. London, UK: Thomas Telford

Publishing; 2003.

27. Adapted from Systems Engineering Case Study # 7 Santa Clara County Traffic Operations System and

Signal Coordination Project, Systems Engineering in Transportation Projects: A Library of Case Studies,

INCOSE Transportation Working Group, 2013,

http://www.omegacentre.bartlett.ucl.ac.uk/studies/cases/pdf/UK_JLE_2P_080911.pdf; downloaded Oct.

30, 2014.

Part II Project Life Cycle

3 Project Life Cycle and Project Conception

4 Project Definition and System Definition

Most systems move through a series of developmental stages. In human-made systems, the developmental stages follow an intentional, logical sequence of prescribed activities called the systems development cycle. Project management occurs within this cycle and is the function responsible for planning the work activities and organizing and guiding their execution. The two chapters in this section introduce the systems development cycle and describe its first two phases, conception and definition.

Chapter 3 Project Life Cycle and Project Conception

There is … a time to be born, and a time to die; a time to plant, and a time to reap; a time to kill, and a time to heal; a time to break down, and a time to build up …

—Ecclesiastes 3:1

One feature of the systems approach is the concept of “life cycle”—the basic pattern of change that occurs throughout the life of a system. Two ways the systems approach accounts for this are to (1) recognize the natural process that occurs in all dynamic systems—that of birth, growth, maturity, and death, and (2) incorporate that process into the planning and management of systems. The practice of project management does both.

The process of developing, implementing, and operating any human-made system follows a logical sequence of phases called the systems development cycle. Projects also follow a sequence of phases from beginning to end called the project life cycle. This chapter describes the system development and project life cycles and the first phase of both. The next chapter covers the second phase; subsequent chapters cover the others.

3.1 Project Life Cycle

Systems are dynamic—they change over time. The change tends to follow a distinct pattern that is repeated again and again. Mentioned in Chapter 2 was the life cycle of organisms—birth, growth, maturity, senescence, and death, and its similarity to cycles in human-made products and systems.

See Chapter 2

Projects follow a cycle called the project life cycle. Each project has a starting point and progresses toward a predetermined conclusion; during this time, activity in the project continues to grow, reaches a peak, and then declines—the pattern shown in the lower curve in Figure 3.1 (the upper curves” shows cumulative activity). Activity or effort can be measured in various ways such as the amount of money being spent on the project, number of people working on it, amount of materials being used, and so on.

Besides changes in the level of activity, the nature and emphasis of the activity change too, and so do the people involved. For example, customers and planners are very active early in the project; then designers, builders, and implementers take charge, then at the end, users and operators take over.

Managing the project life cycle requires special treatment. Unlike non-project, repetitive operations where everything tends to be somewhat familiar and stable, many things in projects—resources, schedules, work tasks, etc.—are unfamiliar or in a constant state of change. Much of what is done in a project can be considered non-repetitive or non-routine. Work schedules, budgets, and tasks must be tailored to fit each phase and stage of the project life cycle. Unforeseen obstacles can cause missed deadlines, cost overruns, and poor project performance. Managers must try to anticipate the problems, plan for them, and adjust activities and shift resources to mitigate or overcome them.

Figure 3.1 Level of effort during the project life cycle.

3.2 Systems Development Cycle

The project life cycle is part of a larger life cycle called the systems development cycle (SDC). Virtually all human-made systems follow the four phases of this cycle (Figure 3.2):

1. Conception phase (Phase A) 2. Definition phase (Phase B) 3. Execution phase (Phase C) 4. Operation phase (Phase D)

The project life cycle typically spans Phases A, B, and C—conception, definition, and execution. When Phase C ends, so does the project. At that point the system enters Phase D, operation; the system transits from being the end-item of a project to an operational entity.

Phase A: Conception

Every project is an attempt to solve a problem, and a first step in solving the problem is recognizing that the problem exists. After that, the individual facing the problem—the customer and users—seeks out someone who can help. The steps they take—soliciting contractors who can do the work, evaluating their proposals, and reaching an agreement—are all part of the procurement management process.

If the customer organization has an internal group capable of doing the work, it turns to them. If not, it looks to outside contractors, possibly by sending them a formal request for help called a request for proposal, or RFP. Each contractor examines the customer’s problem, objectives and requirements as stated in the RFP and determines the technical and economic feasibility of undertaking the project. If the contractor decides to respond to the request, it presents to the customer a proposed solution (system concept) in a proposal or letter of interest. The customer then examines the proposals and makes a choice. The result is a

formal agreement between the customer and the chosen contractor. Most ideas or proposals never get beyond Phase A; the problems addressed are judged as insignificant, or the proposal as impractical, infeasible, or lacking benefits to justify funding and resources. The few that are approved and reach a contract agreement move on to Phase B.

Figure 3.2 Four-phase model and stages of the systems development cycle. The project life cycle is Phases A,

B, and C.

Phase B: Definition

Having reached agreement with the customer, the contractor begins a detailed analysis of the system concept, during which it defines requirements the system must fulfill to meet the customer’s needs, and the functions and elements the system must possess to meet those requirements. This definition results in a preliminary design for the system. As the process continues, the major subsystems, components, and support systems of the proposed system are determined, as are the resources, costs, and schedules necessary to build the system. Meantime, project management assembles a comprehensive project plan that defines the activities, schedules, budgets, and resources to design, build, and

implement the system. Contractor top management reviews the plan for acceptability and then forwards it to the customer who also reviews it for acceptability.

In some industries the tasks in Phases A and B are referred to as “front-end loading” (FEL) or “front-end planning”, which refers to everything that happens in the project prior to the work execution in Phase C. FEL is discussed in Chapter 4.

See Chapter 4

Phase C: Execution

The execution phase is when the work specified in the project plan is put to action; it is sometimes referred to as the “acquisition” phase because the user acquires the system at the end of the phase and most system resources are acquired then. The execution phase often includes the stages of “design,” “production,” and “implementation,” referring to the progression through which a system moves from being an idea to a finished, physical end-item. All systems are comprised of elements arranged in some configuration, pattern, or structure, and it is in the design stage that the elements and configuration necessary for the system to fulfill requirements are defined. Following design the system enters production where it is built as either a single-item or mass-produced item. During the execution phase the system is implemented; it is installed in and becomes a part of the user’s environment.

Phase D: Operation

In the operation phase the system is deployed; the customer takes over to operate the system and maintain it. For systems such as products and equipment that people use and rely upon daily, Phase D may last for years or decades, in which case the phase includes not only operation and maintenance of the system, but improvement and enhancement to keep the system viable and useful. Every

system eventually outlives its purposes or simply wears out. When that happens there are two choices: scrap the system or modify it so it remains useful; in the latter case the “modification” becomes a new system concept, the beginning of a new SDC and a new project.

For some systems Phase D is short or nonexistent: examples are a political campaign, rock concert, and gala ceremony (the project ends on Election Day or upon completion of the concert performance or ceremony).1

Virtually all projects progress through Phases A, B, and C, though not necessarily through the stages shown in Figure 3.2. In some projects, certain stages receive little emphasis or are entirely skipped; many projects, however, move through all the stages, even if informally. For instance, although not every project requires proposal preparation, every project does start with a proposal from someone. Similarly, while many projects do not involve “production,” every project involves the production of something—even if only information. A great many projects follow a pattern similar to the cycle in Figure 3.2. The next two examples illustrate.

Example 3.1: New Product Development Cycle at Jamal2

Jamal Industries is a medium-sized manufacturing firm that produces products for major retailers under the retailer’s own labels such as Sears and True Value. It develops and produces its products in the phases of initiation, feasibility, analysis, design, and manufacturing. Jamal initiates and implements most projects internally, though sometimes it contracts out development and manufacturing work. This example is such a case.

A competitor had introduced a computerized timer that would have a major impact on Jamal’s market share. To examine the feasibility of launching a new product, Jamal engineers analyzed samples of the competitor’s device to see whether they could quickly develop their own version. The analysis focused on whether a device as good or better could be made and sold under the retailers’ private labels for 20 percent less than the competitor’s price. As an alternative, Jamal could seek other distribution

channels to sell the product under its own label. The feasibility study indicated that the first alternative was not feasible, although the second one —selling the product under its own label—was.

An in-depth analysis was done to determine how Jamal could contract out work to avoid a capital investment that it could not afford. The research director, who served as the project manager, and his engineering staff analyzed contracting alternatives and decided to hire a general contractor to design and manufacture the product. They identified a foreign contractor that could make a superior timer that Jamal could market at a price $12 lower than the competition. The bulk of the planning, scheduling, and budgeting associated with the project was delegated to the contractor. Within a year the product was designed, manufactured, distributed, and in stores.

The contractor will continue to produce the device as long as Jamal markets it. Jamal’s design team was transferred to other projects, although the research director continues to monitor the contractor to ensure quality standards are maintained.

Example 3.2: Software System Development Cycle at Microsoft3

New software development at Microsoft commonly follows the phases of planning, development, and stabilization, although some of the phases pass through a series of iterations.

The planning phase produces a vision statement, specification document, and plans for marketing, integrating components from other products, testing, and documentation. The phase runs from 3 to 12 months depending on whether the product is new or an upgrade. The vision statement guides the project; it is a short statement about the product goals, focus, and priorities. The specification document is a preliminary statement of the product’s features and packaging. The document starts out small (sometimes it can be described in a single sentence) but expands as the project

progresses. The document and plans are combined with time estimates to create a project schedule. The phase concludes when management approves the plans and schedule.

The development phase is nominally subdivided into four sub-phases with three internal product-release milestones. Each sub-phase is scheduled to run for 2 to 3 months, which includes time buffers to accommodate unanticipated problems and to enable the sub-phase to be completed by the milestone date. The first three sub-phases are devoted to development and coding, testing for bugs and functionality, and documentation of the product features. The goal of each sub-phase is to meet the requirements for a set of product features that would be fully ready to “ship,” even though shipping isn’t yet possible because the features have yet to be integrated into the product. In the event that a competitor threatens to release a similar product, the third, or even second, sub-phase can be bypassed to cut 4 to 6 weeks from the development process. The product would have fewer features, but would beat the competition to launch. During the fourth sub-phase, product features are further tested and debugged and a freeze imposed, which means no major changes can be introduced thereafter. This enables the education group to write documentation that will accurately correspond to the product when released. The sub-phases of the developmental phase are a variation of the “agile” approach to system development, described in Chapter 13.

See Chapter 13

In the last phase, stabilization, all the features developed in the previous phase are combined and tested. “Zero bug release” occurs when all bugs are fixed or features with remaining bugs are removed from the product (to be fixed later and included in subsequent product releases). This phase concludes with the release of a “golden master” disk from which manufacturing will make copies. The project concludes with a project team meeting to review the project and what was learned from it.

Most project-oriented companies undertake projects in ways best suited for them, and they prescribe or mandate ways to manage and perform tasks in those

projects; i.e., they create their own project methodology. The two above examples illustrate such “homegrown” project methodologies. Throughout this book we will repeatedly refer to the methodology that encompasses phases A thorough C in Figure 3.2. We use this methodology not because it is always the best but because it conveys a common pattern that is very similar to methodologies we have seen in many companies. Another methodology similar to Figure 3.2 is the systems engineering process; this process, which relates to tools and topics discussed in Chapter 4, is described in the Chapter 4 Appendix. Other methodologies are discussed in Chapter 17.

See Chapters 4 and 17

Phased Project Planning and Fast-Tracking

The phases and stages in a project life cycle are sometimes undertaken in a stepwise fashion called phased project planning or project gating. At the end of each phase the project objectives, costs, and outcomes are evaluated, and a decision is made to continue, suspend, or cancel the project. Resources are committed only after a management review. This is elaborated in Chapter 4.

See Chapter 4

The project phases as described are not always performed in discrete sequence but can be overlapped in a practice called fast-tracking. Before Phase B is completed, elements of Phase C are started; before Phase C is completed, portions of Phase D are started. Fast-tracking compresses the time for systems development and implementation, though it poses the risk of overlooking or misdefining tasks and having to repeat or undo them.

In projects using the so-called agile methodology some phases are repeated. The execution phase and, sometimes, also the definition phase are repeated in cycles, each cycle intended to refine, enhance, or build upon the results of the previous cycle. Agile is covered in Chapter 13.

See Chapter 13

Stakeholders

The SDC has many stakeholders (actors and interested parties). The main stakeholders groups are:

1. System customers (buyers, clients, or owners), including:

a. Customer management b.Users and operators

2. System contractors (the systems development organization (SDO), developer, promoter, or consultant), including:

a.Contractor top management (corporate and functional managers) b.Project management (project manager and staff) c.The “doers”—professional, trade, assembly, and other workers

Customers are the persons or groups for whom the project is being done and who will acquire and/or operate the system when it is completed. Customer management pays for and makes decisions about the project; users and operators will utilize, maintain, or in other ways be the recipients of the project end-item. It is important to identify the actual users since, ultimately, it is for them the end- item is being created. The terms customer and user are used somewhat interchangeably, but it’s important to keep in mind the distinction between them:

• The customer (owner, buyer, sponsor) pays for the system. • The users use and operate it.

The contractor or developer or consultant is the party that studies, designs, develops, builds, and installs the system. The contractor is usually external to the customer organization, although, of course, it might well reside within the same organization, as is the case of internal consulting/support groups. Since the

contractor is usually an organization, it sometimes is referred to as the system development organization (SDO).

Because in most cases the customer pays the contractor to perform the project, think of the customer as the buyer and the contractor as the seller. These terms make sense when you think of a project in the context of being a contract between two parties, wherein one (the contractor-seller) agrees to provide services in return for payment from another (the user-buyer). The project manager usually works for the contractor, although the customer might also have a project manager.

Besides these, the life cycle involves other key parties—individuals, groups, and organizations with vested interests and/or influence on the conduct of the project. Anyone who is affected by the project, perceives he is affected by it, or potentially can alter its outcome is a stakeholder. Project stakeholders are discussed throughout the book and somewhat in depth in Chapters 15 and 17.

The remainder of this chapter will focus on the first phase of the project life cycle and how projects are conceived and started. For externally contracted projects, most of what happens in this phase is part of what is called the procurement management process.

See Chapter 15 and Chapter 17

3.3 Phase A: Conception

The conception phase nominally comprises two stages. The first, project initiation, establishes that a “need” or problem exists and that it is worthwhile to investigate. The second, project feasibility, is a detailed investigation of the need or problem, a formulation of possible alternative solutions, and the selection of one. The phase ends with an agreement that a chosen contractor will provide a specified solution to the customer.

Project Initiation

The process begins when the customer or user perceives a need;4 i.e., it recognizes a problem or opportunity and, possibly, ways to deal with it. Sometimes the need is expressed as a vision.

Example 3.3: Vision Statement at Microsoft5

As mentioned in Example 3.2, each new product development project at Microsoft starts with a short statement about a product and its goals called a vision statement. For a recent version of Excel it was just five pages long.

The purpose of the vision statement is to communicate the concept and requirements of the product to the development team, other product groups, and management. At Microsoft the vision includes an executive summary with a one-sentence objective, a list specifying what the product will do and not do, and definitions of the typical customer and competition. It might describe product features and priorities in enough detail to begin preparing schedules for development, testing, user education, and preparation of English and non-English product versions. It might also list requirements for the operating system, memory, disk space, processor speed, graphics, and dependencies on printer drivers and components. The statement informs

everyone about what they will do and not do, and gives them a common overview.

Beyond perceiving the need, project initiation requires proving that the need is significant and can be fulfilled at practical cost. It is easy to identify problems and muse about solutions, but most ideas are ephemeral and not worth much. If a customer decides to take an idea beyond speculation, he might take the “quick and dirty” route and simply accept the first solution that comes along; or, he might undertake a more protracted, albeit systematic and thorough approach and consider only ideas with a reasonably high degree of success or return on investment. To cull for the few good ideas, the customer organization undertakes a brief, initial investigation.

Initial Investigation

Many users know a problem exists but do not know what it is or how to explain it. Before committing resources to a full-fledged study, the user undertakes a short internal investigation to clarify the problem and evaluate possible solutions. The investigation starts with fact-finding—interviewing managers and users, gathering data, and reviewing existing documentation. A clear statement of the problem is formulated, objectives are defined, and a list of alternative, potential solutions is compiled. The investigation focuses on the elements of the problem, including:

• The environment • The needs, symptoms, problem definition, and objectives • Preliminary solutions and estimated costs, benefits, strengths, and

weaknesses of each • Affected individuals and organizations.

Based on the investigation, the customer decides whether or not to proceed with the idea. Most ideas never get farther than this, and it is obvious why: there are endless ideas about needs and potential solutions, but resources are scarce and

organizations can commit only to those comparative few that provide the most benefits and have the best chances of success. To approve the concept for further study, the customer must be convinced that the idea:

• Fits a need that is real and funding is available to support it. • Has sufficient priority in relation to other ideas. • Has particular value in terms of, for example, applying new technology,

enhancing reputation, increasing market share, or raising profits. • Is consistent with the organization’s goals and resources.

Pertaining to the last bullet, some organizations prescreen proposed projects and consider for further analysis only those that align with organizational goals and available resources. Prescreening is an aspect of project portfolio management, discussed in Chapter 18.

See Chapter 18

The initial investigation is usually conducted by the customer and is brief, requiring a few days or weeks at most. Sometimes called the Idea Stage or Pre- Feasibility Stage, its purpose is to determine if the idea deserves further study; if it does, it then becomes a “potential project” and is approved for the next stage, feasibility.

3.4 Project Feasibility

Feasibility assessment is the process of studying a need, problem, and solution in sufficient detail to determine if an idea is economically viable and worth developing. The initial investigation is a form of feasibility study, a pre-feasibility study, which is usually rather cursory and, hence, insufficient to commit to a project. A feasibility study is a more protracted, rigorous study that considers alternative solutions (system concepts) and the benefits and costs of each. The customer typically performs the feasibility study but will hire an outsider (contractor) to do it if the study requires special expertise. Deciding to build a new airport, power plant, highway, or tunnel are examples where the feasibility studies are undertaken by contractors and are themselves big, expensive projects.

When a number of alternatives exist for the project, feasibility may depend on the life cycle cost (LCC) of the end-item system, which is the system’s total cost over its entire useful life, including installation, operation, and disposal. For systems that must be newly developed, the cost includes all costs associated with all phases of the SDC—conception, definition, execution, and operation. The topic of LCC is covered in Chapter 8.

See Chapter 8

Some projects involve multiple feasibility studies. Product development and research projects often have a technical feasibility (to assess the risk that the technology might not work) and another, commercial feasibility (assess the risk that the product might fail in the market). Another matter regarding feasibility is the question of how the project will be financed and its expenses covered throughout the project life cycle. Project financing is a subject unto itself and beyond the scope of this book, however it is of major importance and, quite often, the deciding factor in project approval. In other words, a project’s feasibility might have less to do with the technical or commercial merit of the project than with funds available for the project as compared to other projects under consideration. For large projects the execution plan (see Chapter 5) should

include a section on project financing that addresses funding arrangements and means for controlling cash flow and managing money.

See Chapter 5

If the feasibility study indicates that the concept is viable, one of two things happen (Figure 3.3). Theme A: if the concept is something the customer can handle itself, it is passed along to an internal group for development and execution; Theme B: if the concept cannot be executed internally, it is given to outside contractors (SDOs). Companies like Boeing, Microsoft, and Toyota routinely do feasibility studies for new products and then hand the approved concepts to their own teams for the design, development, and production of the products. But companies like Ritz-Carlton and Swisshotel, after deciding to build a hotel at a specific location, hire outside contractors to execute the project. In the latter case, they solicit proposals and bids from multiple contractors with an RFP document (described in the next section) and select the best.

Each contractor competing for the project must perform its own feasibility study to assess the merits of the project and whether or not it wants to participate. If a contractor decides to go forward, it will investigate alternative possible solutions (system concepts) to the customer’s problem, choose one, and describe it in a proposal. This is called the “proposal preparation process.” Upon receiving the proposals, the customer reviews them and selects the one that best fits the selection criteria, i.e., is the “most feasible.”

Figure 3.3 Feasibility study as part of the conception phase.

In summary, project feasibility involves multiple studies and decisions—the customer assessing the “feasibility” of funding the project; the contractor determining the “feasibility” of winning the contract;the contractor conceiving alternative solutions and picking the “most feasible” one to propose; and the customer assessing proposed solutions and choosing the “most feasible” to buy. When the customer reaches an agreement with a contractor, the project moves forward to Phase B.

Sometimes contractors decide not to prepare proposals because they don’t have solutions that will make a profit or fit the customer’s request. Sometimes customers conclude that none of the proposals meet the requirements. Either way, the concept is judged as “not feasible” and the process ends there.

Request for Proposal

The RFP—request for proposal (or request for bid, request for quotation, invitation for bid (IFB), or similar term)6 is a document the customer sends to potential contractors explaining the customer’s problems, objectives, requirements and desire to hire someone; it might also state what the customer wants to see in the proposal (proposal requirements) and how the winning proposal will be selected (proposal evaluation criteria) (see Figure 3.4). The process to select the best proposal is described later and in Chapter 18.

See Chapter 18

One purpose of the RFP is to outline the user’s need, problem, or idea, another is to solicit suggestions (proposals) for solutions—usually with the intent of awarding a contract. The customer can send RFPs to contractors on its own bidders list—a list of prequalified contractors, or it can also distribute RFPs to the broader market via the Internet using commercial “online sourcing tools.” Thus, contractors learn about upcoming jobs either by directly receiving RFPs from customers or by scanning online newsletters and bulletins, and requesting RFPs. For example, Commerce Business Daily is a web publication that gives a synopsis of all US federal jobs over $10,000. Businesses scan the jobs and request RFPs for those they might be interested in bidding on.

Often the customer will precede the RFP with a Request for Qualifications or RFQ, which is a request for contractors to describe their qualifications. The customer sends RFPs only to contractors deemed qualified for the work.

Figure 3.4 Contents of a Request for Proposal.

Usually the customer gets just what he asks for, and project foul-ups later can be traced to a poor RFP. The RFP must be clear, concise, and complete: when it is, the customer can expect contractors to respond with proposals that are clear, concise, and complete; when it is not, the customer can expect proposals in kind. Ultimately, the ability of contractors to develop solutions that uniquely fit the customer’s needs will depend in part on their understanding of the requirements as specified in the RFP. Similarly, the ability of the customer to select a contractor that is qualified and has the best proposal will depend on information provided in the RFP. Appendix A at the end of the book is an example RFP.

See Appendix A

Each competing contractor must consider its capability of preparing a winning proposal and, should it win the contract, of performing the proposed work. Among the considerations are:

• Have competitors already got a head start?

• Does the contractor have sufficient money, facilities, and resources to invest in the project?

• Could performance on the project enhance (or damage) the contractor’s reputation?

• Other considerations similar to the criteria employed by the customer in the initial investigation.

Sometimes a contractor will submit a proposal knowing full well it cannot possibly win the project, doing so to maintain its relationship with the customer, remain on the customer’s bidders list, or keep the field competitive. Sometimes a customer sends out an RFP with no intention of ever signing with a contractor, doing so simply to gather ideas—obviously a situation of which respondent contractors must be wary.

Contractors can also submit proposals to potential customers without an RFP. Whenever a developer believes it has a system or solution that satisfies a need or solves a problem, the project manager works with his marketing department to identify prospective customers to which they might send unsolicited proposals describing the merits of the new system. Unsolicited proposals are also sent to current customers for potential follow-up work on current projects.

The Feasibility Study

As mentioned, a feasibility study can be performed at multiple times and with different parties in a project: minimally the customer performs a study to determine if the project is worth supporting; if the project work is to be done externally, the contractor also performs one to determine if the job is worth pursuing. In this section we consider the latter, although the same steps would apply equally to the customer or anybody doing a feasibility study.

The statement of the problem as defined in the RFP is frequently incomplete, vague, or even incorrect. If an RFP has been received it will likely contain such a statement. Thus, one of the contractor’s first steps in responding to an RFP is to develop a definition of the problem that is more concise, accurate and complete than the one in the RFP.

The prime source of information about the problem is interviews and

documented information provided by the customer and user. It is thus important that the contractor identifies who the user really is. Surprisingly, this is not always obvious. The real user, the party that will operate, maintain, or be the main beneficiary of the system, is often confused with persons who only represent the user. If the customer is an organization, the contractor must determine the individuals whose needs are to be met. The contractor should be working closely with the user throughout the feasibility study, so it is important to find users who are familiar with both the problem and the workings of the organization. Sometimes, however, the RFP specifies that in order to make the competition “fair” the customer will maintain an “arms-length” relationship with competing contractors. Even then, however, contractors are usually permitted to make inquiries to or seek additional information from a customer contact person. The feasibility study sometimes results in a document called a “business case.”

The Business Case

The business case document assesses the value and risks (feasibility) of a project at an early stage and attempts to convince the customer/sponsor to authorize and undertake the project. It is sometimes used to obtain financing for the project from commercial banks (a bankable business case). In the process of choosing between projects, some companies use the business case to compare the value of and risks associated with a project to those of other projects. This is discussed in Chapter 18.

See Chapter 18

The content of the business case is based on the findings of a feasibility study; if the feasibility study indicates the project is viable, then the business case is written to justify the project. Whereas the final report of a feasibility study compares alternative solutions, the business case tries to justify the chosen alternative.

A business case typically includes:

• Cost-benefit analysis: estimated project costs compared to the benefits

• Estimated project duration (when financial return depends on the timescale)

• Financial aspects such as the funding approach • Risks, issues, and a preliminary risk management plan • Assumptions.

The business case contains estimates for costs and benefits, although in some cases these estimates are updated as the project moves through its early phases. For example, the PRINCE2 methodology specifies developing an outline business case at the project start and thereafter reviewing and updating these estimates after each project phase. In some industrial mega-projects the first two phases of a project are referred to as FEL-1 (Front-End Loading-One) and FEL-2; FEL-1 concludes with a preliminary business case, FEL-2 with a verified, detailed business case.

Sometimes the business case is included as part of a more comprehensive feasibility report that, in addition to arguing the business case, addresses technical, environmental, financial, and other aspects of the project in greater detail than would a typical business case.

Needs Definition

Problems originate from needs (Definition: a problem is an unsatisfied need), and so do solutions (Definition: a solution is a way to satisfy a need), so it is important that the solution adopted for the project addresses the right needs. Hence, conducting a feasibility study and preparing a proposal should begin with defining user needs. J. Davidson Frame7 suggests the following steps:

1. Ask the user to state the needs as clearly as possible. Ask the user a complete set of questions to further elicit the needs. For

example:

Are these real needs, or are there other, more fundamental ones? Are they important enough to pursue? Are we are capable of fulfilling these needs, or is someone else better

suited? If the needs are fulfilled, will they give rise to other needs? Will satisfying these needs also satisfy other needs too? What effect do the unmet needs have on the organization and the

user? What other parties are affected by these needs and how will they

react to our efforts?

2. Conduct research to better understand the needs. “Research” means probing to gather whatever information is necessary to better understand needs, define the problem, and propose solutions. Information sources include interviews, reports, memos, observation, models, and analysis of technical data and empirical test results.

3. Based on information from Steps 2 and 3, restate and document the needs. 4. Give the restated needs to the user.

The steps are repeated as often as necessary, concluding with a statement of needs that the user accepts as best representing his interests (rather than the interests of the contractor or other parties).

Since every project is an effort to fulfill needs, a clear, well-stated, and correct needs statement is necessary to avoid a project that is meandering or irrelevant. But attaining such a needs statement is not easy. Frame describes the following troublesome aspects.8

• Some needs are ever-changing. They are a moving target; thus, for each need the question must be asked “Is this likely to change?” When the answer is yes, the solutions and project plans that address the need must be flexible and easy to change.

• Solutions are confused with needs. Rather than stating a need, the user or contractor states a solution. For example, the statement “We need a new building” is a solution, not the need. True, maybe a new building will be required, but a building is only one of perhaps many ways of satisfying the need to, for example, overcome a space shortage.

• The needs identified are for the wrong user. Who is the user? Is it the party that actually feels the need and is most affected by it, or is it the party

who pays to resolve it? Usually they are different. The needs statement should reflect the opinion of the party to which the solution will be directed—the user. Do not be content for one party to tell you the need of another. Talk to the other party, too.

• There is more than one user, and their needs differ. The user embodies several parties, all with valid needs. The question is “Can all of their needs be addressed?” Given multiple users, an attempt must be made to organize, classify, and prioritize their needs.

• User’s needs are distorted by the “experts.” Inadvertently or intentionally, the contractor leads the user to a distorted definition of needs. The customer should be wary that the contractor might:

1. Extend the list of needs to be much broader than the user thought. This increases the size of both the problem, and, no surprise, the contractor’s billable work.

2. Reframe the needs in terms of what he, the contractor, is best suited to do. The contractor readily fulfills the stated needs, but the user’s needs remain unaddressed.

3. Not ask for but rather state the user’s needs (because, after all, the contractor is the expert).

Sometimes users are resistant to clarifying needs and expect the contractor to do it for them. The contractor should involve the user and ensure the two parties work together until they reach an agreed-upon statement of user needs. The process helps both to better understand the needs and problems, and to ensure that the adopted solution is the right one.

User Requirements Definition

Conversation between a user and contractor:

USER: “You installed my computer. Why didn’t you install the network router, too?”

CONTRACTOR: “You said you wanted the computer installed.”

USER: “But the computer won’t be of much use without a router.” CONTRACTOR: “You said you wanted the computer installed. I did just what you

requested.”

Another exchange:

CONTRACTOR: “The lighting for the office addition is finished. As we agreed, I wired 20 ceiling lights.”

USER: “But the room seems kind of dark.” CONTRACTOR: “You said you wanted 20 lights.” USER: “Yes, but you said the room would be bright. It isn’t.”

Both cases illustrate user-contractor disagreements about end-results. Misunderstandings like these delay project completion, drive up costs, and sometimes become legal disputes that put the outcome in the hands of the courts. The problem is lack of clear user requirements. User requirements should describe in unambiguous terms what the user wants in the finished solution. Derived from user needs, the requirements are the measure by which the user determines whether or not the end result or solution is acceptable. Formally documented, they are the quality measures for the project. In the above examples, they would include the functions that the installed computer system and overhead lighting must serve.

Ideally, user requirements address the needs not only of users but also builders, suppliers, and other stakeholders that will benefit from, manage, maintain, or otherwise be impacted by the system. Perhaps obvious, user requirements are stated in the language of the users and other stakeholders. The project should not begin until the requirements have been combined into a user requirements list and the customer and contractor agree that the list is complete.

Often users do not understand the necessity for and importance of good requirements; thus, it is the project manager’s responsibility to make sure the requirements are complete, clear, and accurate. When the project is completed and the contractor says “Here’s what you ordered,” the user should be able to say “Yes, it satisfies all my requirements.”

There are many kinds of user requirements. Some account for the system’s objectives, life cycle, and operational modes, others for constraints and interfaces

with other systems.

Requirements for Objectives and Life Cycle

Every project and the end-item system to which it is directed start with a statement of objectives that elaborate on the needs and provide the basis for defining requirements. Consider the SpaceShipOne example from Chapter 1. The need—“a reusable three-person vehicle that can be launched into space twice within a 2-week period” can be defined in terms of the following set of objectives:

See Chapter 1

Develop a spaceship that can:

1 attain a minimal altitude of 100 km (where “space” begins) 2 be reused (launched) every 2 weeks 3 carry three people.

Each objective is then elaborated in terms of a set of requirements. The requirements must account for whatever the users and other stakeholders think will be significant throughout the expected life cycle of the system, cradle to grave, which means they should incorporate issues regarding how the system will be developed, built, used, marketed, financed, maintained, and disposed.

Requirements for Operational Modes

Included in this life-cycle thinking are the different ways and kinds of environments in which the system will be used or operated, referred to as operational modes. For example, the modes for the previously mentioned reusable spacecraft include:

• Flight mode

- Launch and boost into space

- In-space - Return from space - Landing

• Turn-around-between-flights mode • Crew training mode • Ground transport mode • Maintenance and testing mode

The system will be expected to perform different functions and satisfy different conditions in each of the modes, and these functions and conditions must be specified in the requirements.

Requirements for Constraints and Interfaces

Every system is subject to limitations imposed by the environment and other systems with which it must interface. These include mandated policies, procedures, and standards, and limits on resources, time, funding, technology, and knowledge. In addition it faces environmental constraints including technological requirements, laws, and even social norms and customs. For instance, among numerous constraints and interfacing systems, the spaceship must conform to FAA regulations, technical standards of the aerospace industry, and local noise and pollution laws, and it must be able to interface with existing systems for air traffic control and communication.

The Current System

Figure 3.5 System schematic: Flow of supplies to the operating room.

Conceptually, a need arises because of inadequacies of the current system; there is a gap between the current system’s capability and a desired capability. A purpose of the feasibility study is to understand and document the current system, including its inputs, outputs, functions, flows, subsystems, components, relationships, attributes, resources, and constraints. The system schematic in Figure 3.5, for example, shows the elements and flows of a hospital system; it was developed in a project to reduce the cost of supplies inthe operating room. Of course, sometimes needs arise simply because there is no current system. That would be the case for SpaceShipOne.

Analysis of Alternative Solutions

Through the process of defining and documenting needs, requirements, and the

current system, the contractor develops a good understanding of the problem and is able to delimit the scope of alternative ways to solve it. The contractor begins to develop alternative high-level (system-level) solutions to the problem from studies and models that take into account what the system must do (user requirements), how it can be done (technical considerations), and what it will cost (economic considerations). The solutions may include new systems developed from scratch, or modifications of off-the-shelf systems and existing technology. A good project manager encourages creativity and free flow of ideas in the search for solutions.

Alternative solutions are analyzed for ability to satisfy objectives and user requirements within available resources and imposed constraints. The best solution is chosen and proposed to the customer. The following example illustrates.

Example 3.4: User Requirements and Feasible Solution for the X-Prize Project

The X-Prize competition described in Chapter 1 required developing a complete system that would meet numerous requirements relating to everything necessary to design, build, and operate a spaceship. Among numerous user requirements for the spaceship are:

See Chapter 1

• Climb to an altitude of at least 100 km • Carry three people • Provide safe and comfortable flight • Be relatively inexpensive to design, build, and launch • Have a maximum “turn-around” time for reuse within at most 2

weeks.

Associated with each of these requirements are many issues, problems, and alternative solutions. One issue that impacts all of the requirements is the

basic question of how, exactly, do you get people into space and then back home safely?

The alternatives are:

1. Getting into space

a. Launch spaceship from atop a booster rocket b. Launch spaceship from a high-flying airplane

2. Being in space

a. Enter Earth orbit b. Do not enter Earth orbit

3. Getting back to Earth

a. Follow a wide parabolic arc b. Follow a narrow arc going almost straight up and almost

straight down

4. Landing

a. Land in a “zone” using a parachute b. Land at an airport like an airplane

After considering the requirements and constraints, designer Burt Rutan chose the combination of alternatives 1-b, 2-b, 3-b, 4-b: launch the spaceship from a high-flying airplane, do not enter orbit, follow a narrow parabolic trajectory up and down, and land airplane-like. Choosing these alternatives involved analysis of cost, risk, technology, time, and ability to meet the requirements.

Environmental Impact

Part of a project’s feasibility is determining the project’s or end-item system’s

impact on the natural environment. In 1969 the US enacted legislation mandating that all projects receiving federal funding or licensing must assess and report on the project’s environmental impacts in an Environmental Impact Statement (EIS). Since then Canada, Australia, New Zealand, Japan, countries of the European Union, and others have ratified laws requiring Environmental Impact Assessments (EIAs).

The contents of the EIS vary by state, country, and region but typically include:

1. A summary of proposed development and/or management plans 2. Alternative sites and technologies for the proposed project 3. A description of the project’s existing site and surrounding area 4. Potential project impacts, such as on:

• Quality of air, soil, watersheds, wetlands, flood plains • Fisheries; sensitive plants; sensitive, endangered, or threatened

species • Scenic resources; societal and aesthetic experiences • Heritage resources (sites, structures, buildings, districts, objects) • Historical resources (logging, ranching, grazing, mining, recreation)

5. Adverse impacts that cannot be avoided 6. Long-term impacts on resources 7. Ways to prevent, minimize or offset impacts; ways to monitor actual

impacts.

The EIS is followed by a series of public reviews and hearings to discuss the findings and determine follow-up actions, especially concerning the last bullet above. Since the results of the EIS often affect the project plan and the system’s design, the project’s managers and supporters should try to develop a positive working relationship with the environmental assessment team.

Sustainability

In recent decades, increased energy consumption and usage of non-renewable

resources has led to harmful environmental effects such as habitat destruction, biodiversity loss, desertification, and greenhouse gas emission. Projects themselves and the end-items they produce contribute significantly to such effects. Consequently, one way to mitigate the damage is to design and build products—and manage the projects that do so—with an eye on sustainability.

Many industries have taken strides to incorporate environmental and social responsibility into the role of project management. For example, the construction industry has created guidelines (sometimes by government mandate) for designing and constructing buildings (so-called “design for environment” and “green construction”, respectively) to reduce air and water pollution, landfill waste, and carbon emissions. As examples, building design guidelines in the UK mandate the use of:

• Passive ventilation systems • Whole building heat recovery systems • Renewable/recycled materials • Materials with no damaging effects on the environment and energy-

efficiency in terms of manufacture, use, and disposal.

Construction guidelines in the US include:

• Reduce landfill waste: crush/reuse aggregates (stone, etc.); use suppliers who accept returns/exchanges, reuse packaging, and use reclaimed/recycled building products.

• Minimize dust from concrete/mortar; avoid air/water pollution. • Use timber and wood products with the Forest Stewardship Council’s

trademark. • Use low energy forms of construction to minimize CO2 from site activities. • Reduce trips to/from the site and use local suppliers to reduce transport

CO2.

In the US, the LEED certification program (Leadership in Environmental and Energy Design) has created standards of sustainable building design and development. The standards include many of the guidelines listed above, as well as:9

• Installation of windows that provide ample fresh air and natural light. • Site selection: do not build on prime farmland or too close to a threatened

animal habitat. • Build near transportation alternatives and within walking distance to ten

basic services.

Matters of sustainability arise throughout the project life cycle—in project initiation, feasibility, and definition; in the RFP, proposal, contract, requirements, and project plan; in risk analysis; and in project execution. Although in some cases project managers have little ability to influence such matters, in others they do; they can influence the designers of the end-item and select the right contractors and suppliers with the goal of sustainability and minimizing the environmental impact of the project.10 The project plan should minimally ensure that the project and its outcomes comply with local, state, and federal environmental laws; where the laws are inadequate, project managers can take the lead.

The result of the feasibility study is a statement of the problem, a list of needs and user requirements, a description of the current situation, and a preferred solution and reasons for its selection. The feasibility study, when combined with the project plan, bid price, and contractor qualifications, form the project proposal.

3.5 The Project Proposal

Proposal Preparation11

The proposal tells the customer what a contractor intends to do; it is the basis for selecting the project contractor. The effort to prepare the proposal is itself a project and, thus, it should be managed like one. Since preparing a proposal sometimes involves significant time and money, it usually requires top management authorization. Upon authorization, management identifies a technically competent person to oversee preparation of the proposal; often, this person becomes the project manager if the contract is won. She might be entirely responsible for managing the proposal preparation effort or, alternatively, work with another manager who specializes in conducting proposal-related activities. The project manager selects the project team, or part of it, to help prepare the proposal; usually the bulk of the project team is not specified until after the contract is won.

The project manager reviews the requirements of the RFP and prepares a detailed summary of the tobe-proposed project. This summary guides the effort and prevents the focus from shifting to irrelevant technical or managerial considerations.

The project team outlines the work to be done for the solution identified in the feasibility study and prepares a statement of work or SOW. The SOW will include the system and project objectives, technical solution, high-level requirements, and major areas of work required to deliver the solution. If a SOW appeared in the RFP (e.g. Figure 3.4) then the SOW in the proposal might repeat it but should also include new information culled during the feasibility study and particulars about the chosen solution. In cases where the contractor believes the SOW in the RFP is inaccurate or incorrect, the contractor should state that in the proposal.

During proposal preparation the project team must think through the entire project and prepare a rudimentary project plan that will address project time, cost, and performance issues. It uses a work breakdown structure (WBS) to

determine the tasks necessary to achieve the requirements and to prepare a schedule and cost estimate (topics discussed in later chapters). The proposal sometimes includes the WBS, schedule, and a cost breakdown showing how the project price was derived. When multiple solutions are proposed, a rough plan of each one is included.

The proposal is a sales device and, if accepted, also a contract: a good proposal gives not only the price, schedule, and other details, but convinces the customer that the contractor is competent and capable of doing the work.

All functional departments in the contractor organization able to provide relevant information are called upon to assist with the proposal. This increases the accuracy of proposal estimates and builds commitment from groups that will later work on the project.

As the proposal is being prepared, the contractor should establish a dialogue with the customer to determine which solutions it prefers and which requirements are dominant among time, cost, and performance. Even when the RFP is clear, this will help ensure that the proposal will conform to the RFP specifications and satisfy the user’s requirements. Proposal preparation can be iterative: acceptance of one proposal leads to preparation of another, more detailed proposal, as illustrated next.

Example 3.5: Writing Proposals for Real Estate Projects at Cwutzrite Company

The real estate department at Wutzrite Company helps clients choose among real estate investment alternatives. A meeting is set up with the client to define the client’s investment “problem” and goals; the client and several Wutzrite employees brainstorm to get a clear, accurate definition of the problem. Afterward, a project director prepares a proposal for the client that includes the problem statement, a proposed solution, and the price. Proposals that involve site development or designing and constructing a building include a feasibility study; for proposals that involve only evaluating, improving, or determining the value of a site, no feasibility study is needed. If the client likes the proposal, the director prepares a second,

more detailed proposal that includes a WBS and updated schedule. If the client approves it, the second proposal becomes the high-level project plan. It specifies tasks to be done and target dates, and is the basis for assigning personnel to the project.

Approval of the second proposal usually calls for a feasibility study, demographic study, and analysis of financing, tax, and accounting ramifications of the recommended solution; the results are combined and submitted to the client in a third proposal that suggests particular courses of action regarding the solution.

The feasibility study and proposal preparation may take weeks or months to complete. Although enough time must be spent to produce a good proposal, not so much time should be spent that it becomes overly time consuming or expensive. A good rule of thumb is: Do not try to do the entire project while preparing the proposal! In some technical projects this may be unavoidable since the proposal includes a full-scale demonstration of the proposed solution. Developing the system for demonstration may itself be tantamount to a good- sized project.

To assure nothing is overlooked in the proposal preparation, project managers typically employ checklists that, over the years, grow to accumulate all the important items on a proposal, including, for example, key considerations for design, assembly, test, shipment, documentation, facilities, subcontractors, supplies, travel, labor rates, training, and payment. Before the proposal can be submitted to the customer, contractor top management must be briefed about the project’s scope, resources needed, price, etc., and approve it.

Proposals range in length from a few pages to many hundreds. The content varies depending on, for example, format favored by the customer, relationship between customer and contractor, technical complexity of the work, and whether the proposal was solicited or unsolicited. Figure 3.6 shows the main ingredients of a typical proposal.12 If the proposal is prepared in response to an RFP, its content and format should conform exactly to the proposal requirements or guidelines stated in the RFP. Appendix B at the end of the book is the proposal for the LOGON project prepared by the Iron Butterfly Company.

Figure 3.6 Contents of a proposal.

See Appendix A

The amount a contractor spends on preparing proposals and the proportion of contracts it wins significantly affect its company overhead since expenses for proposal preparation must be charged to overhead. Only in rare cases such as major defense contracts are the winning contractors reimbursed for proposal expenses.

Selecting the Winning Proposal

Upon receiving proposals from multiple contractors, the customer evaluates and compares them. Selecting the best proposal, reaching an agreement with the contractor, and committing funds are all part of the “project selection” process. Most companies follow a prescribed procedure for evaluating and comparing proposals. When the selection involves assessing each proposed project for its contribution to a portfolio of projects, the procedure is more involved and includes appraising the project’s contribution to company strategic goals, the resources it will entail, and its comparative financial benefits. The topics of project selection and project portfolios are expansive; interested readers should see Chapter 18 where they are covered in depth. Here we give a brief overview of the project selection process.

See Chapter 18

In general, selection of projects is based upon consideration of the following criteria (sometimes provided to contractors in the RFP):

• Project price • Ability of contractor to satisfy stated needs (solution or technical

approach) • Return on investment • Project plan and management • Contractor qualifications and reputation • Likelihood of success or failure (risks) • Fit to contractor resources and technological capability.

The customer may assume that a competent contractor with a good plan will do a good job and, thus, select the contractor with the best qualifications or best plan rather than the proposed solution or technical approach. Thus, each proposal should include a rudimentary project plan showing key activities, and start and end dates and deliverables for each. Contents of the plan and methods for preparing the plan are discussed in Chapters 5 through 10.

See Chapters 5 to 10

Selecting the best proposal often begins with prescreening the proposals and rejecting the ones that fail to meet certain cut-off requirements such as too-high price tag, too-low rate of return, or insufficient experience of the contractor.

Proposals that survive prescreening are subjected to closer scrutiny: a common evaluation method, called simple rating, employs rating proposals according to several evaluation criteria on a checklist. Each proposal is given a score sj for each criterion j. The overall score for the proposal is the sum of the scores for all criteria,

The proposal receiving the highest overall score wins. One limitation of the method is that all evaluation criteria are treated as

equally important. When some criteria are clearly more important than others, a method called weighted rating is used instead wherein the relative importance of each criterion j is indicated with an assigned weight wj. After a given criterion has been scored, the score is multiplied by the weight of the criterion, sj · wj. The overall score for the proposal is the sum of the sj · wj. For all criteria,

The procedures for the two methods are illustrated in Example 3.6.

Example 3.6: Evaluating the Proposals at MPD Company

In response to its RFP for the LOGON project (Appendix A, end of book), MPD Company received proposals from three contractors: Iron Butterfly Contractors, Inc.; Lowball Company; and Modicum Associates. Each proposal was reviewed and rated by a group of operations managers at MPD on five criteria using the following four-point scale:

Criteria 1 2 3 4

Technical solution approach Poor Adequate Good Excellent

Price of contract >1.8 1.6–1.8 1.4–1.6 <1.4 Project organization and management Poor Adequate Good Excellent

Likelihood of meeting cost/schedule targets Poor Adequate Good Excellent Reputation of contractor Poor Adequate Good Excellent

Simple Rating

The results of the assessments for the three proposals were as follows:

Scores

Criteria IronButterfly Lowball Modicum

Technical solution approach 3 1 4 Price of contract 4 4 1

Project organization/management 4 2 3 Likelihood of meeting cost/schedule

targets 3 2 4

Reputation of contractor  3   3   4  Sum 17 12 16

Based on the sum of simple ratings, Iron Butterfly was rated the best.

Weighted Rating

Using the simple rating, Lowball was clearly the worst, but Iron Butterfly and Modicum were considered too close to differentiate. The rating group then decided to look at the criteria more closely and to assign weights to the criteria based on their relative importance:

Criteria Weight Technical solution approach 0.25

Price of contract 0.25 Project organization and management 0.20

Likelihood of meeting cost/schedule targets 0.15 Reputation of contractor  0.15 

1.00

Taking the weights into account, the proposals scored as follows:

Using the sum of the weighted ratings, Iron Butterfly is clearly the superior proposal.

Assessment of proposals might also include evaluation of project risk, especially when the proposed solutions and associated levels of risk differ significantly

between proposals. Methods for identifying and assessing risks are discussed in Chapter 10.

See Chapter 10

Sometimes the contract award depends more on the contractor’s qualifications than on the proposed solution. Among factors the customer might consider are:13

• Is the contractor big enough or adequately financed to do the project? • Does it have a good track record with this kind of project? • Does it have a good reputation in the industry? • Has it been involved in litigations and arbitrations? • Will its management be accessible? • Does it have ISO 9000, ISO 14000, or other certification? • Will the relationship with the contractor likely be amicable or touchy?

Proposal finalists are notified and might be requested to provide more data or give presentations or live demonstrations of their proposed solution or system. If several contractors receive close marks or some aspects of their proposals are unspecified or questionable, then the parties must negotiate to settle upon the final terms. If none of the proposals are acceptable or the feasibility studies show the project would be too costly, risky, or time-consuming or not provide adequate benefits, the process ends and nobody gets a contract.

When a contractor does not get the job, a good practice is to conduct a proposal “post mortem” to determine why not, lessons learned, and what it would do differently next time.

Project Initiation: Variations on a Theme

Projects are initiated in response to a need, but they do not always involve an RFP or even a proposal. The RFP/proposal process as described largely applies to projects where the work is contracted out; i.e., where the customer and the contractor are not in the same organization. For internal projects—projects where the organization has the capability to perform the work on its own, the initiation

might happen with the business case study described earlier. Common examples of this are projects in product development (PD) and IT—two areas where companies often exhibit significant internal prowess. In PD the “need” is manifest as the desire or mandate to fill a perceived market niche or respond to a competitive threat. The business case study addresses the market, competition, proposed product, risk, cost, and benefits, and argues in favor of launching a new PD effort. If the case is approved, the project is turned over to the PD department to begin work. The business case study thus serves dual purposes: it is the feasibility study and the proposal combined. IT projects are similarly initiated by business case studies.

The department that would do the project if it were approved (PD or IT) prepares the business case study and argues for the proffered end-item or solution. Approval or denial of the project involves rating the case against competing cases in terms of the resources required, benefits compared to goals, and priority of needs—the selection process described in Chapter 18. If the project is approved, a project charter is created, as described in Chapter 4.

See Chapters 4 and 18

The RFP/proposal process as described represents projects with relatively few stakeholders or a single, clearly identified customer and its potential contractors. In large technical projects that touch many stake-holders the process is more protracted. Examples include projects for infrastructure and transportation systems (Boston Big Dig, Delhi Metro, telecommunication systems, Chunnel), technical systems wherein subsystems and components must be developed from scratch (commercial aircraft, SpaceShipOne, medical devices) and large-scale property developments (resorts, airports, planned communities).

In such cases—where it is more difficult to define the stakeholders and meet their multiple and sometimes conflicting needs—the RFP/proposal process includes a “front-end” component to identify the important stakeholders and incorporate their needs into a list of stakeholder requirements. The contractor gathering the stakeholder requirements might be hired solely for that purpose and not be the same contractor as the one to perform the project work. After the stakeholders and their needs have been identified, other contractors are requested

to review the requirements and suggest solutions, possibly through the RFP/proposal process. The process of identifying stakeholders and their requirements is a systems engineering effort that takes into account the system’s far-reaching effects and the many stake-holders that will touch (or be touched by) the resulting system throughout its life cycle.

3.6 Project Contracting

Contracting environment and Process14

Contracting is ubiquitous in project management since all work is done in accordance with formal or informal contracts. Even in internal projects where there is no contract, an agreement exists between user and developer groups about the work to be performed to meet pre-specified objectives and requirements.

Most projects, even internal ones, involve some degree of external, legal contracting because the customer often must hire someone externally to perform at least some of the work. In many projects, everything in the project is done or provided by external organizations. As Figure 3.7 illustrates, these “external organizations” might be linked by numerous contractual agreements. The customer might contract with a principle party (prime contractor or SDO) to oversee the entire project; in turn, this party might contract with other parties— subcontractors, consultants, material suppliers, and contract labor (union trade professionals)—to be responsible for portions of the project; these parties might then contract with still others.

The RFP/proposal process addresses the question of who will do the work, not only for the customer but also for any party seeking to hire another to do work. Whether the customer, prime contractor, or other company down the line, each follows a process identical or analogous to the RFP/proposal process to document its needs, solicit ideas, and choose between potential contractors. Thus, any contractor farming out portions of work to subcontractors or acquiring material or services from suppliers will follow the RFP/proposal process to identify and choose the most qualified subcontractors and suppliers. Just as the customer follows the process to hire a contractor, so the contractor follows it to hire subcon-tractors and so on down the line.

Figure 3.7 Contracting parties in a project.

The effort required to review and hire qualified subcontractors can be quite time consuming, especially in international projects, so extra time should be allotted for it in the project schedule. If not, the process to select subcontractors can delay the start of portions of the project and then cause the entire project to slip behind schedule.

The customer should seek to retain a measure of control over contracted work. To that end, the contract should clearly specify the areas of the project over which the customer has ultimate authority for supervision and decisions, and the customer’s role in tracking project progress. From the time when the contract is signed until when the project is closed out or terminated, the contractual agreement must be managed, which means keeping the agreement up-to-date with respect to ongoing changes to the project, the customer’s needs, and the contractor’s capability, and checking that all work conforms with the agreement. This process, called contract administration, is discussed in Chapter 11.15

See Chapter 11

Subcontracting16

Each party in Figure 3.7 must decide what portions of the project it will do itself and what portions it will contract to others. Some contractors do the work; some hire others to do it, i.e., they subcontract. For example, a customer hires a general or prime contractor to manage a construction project and, perhaps, to assemble the building structure, but then the contractor hires other companies for specialized work such as wiring, plumbing, ventilation, and interior details.

Example 3.7: Project Contracts in Construction

Large construction projects are often in the news—sometimes because of problems owing to cost overruns or schedule slippages. Although many factors are cited (labor union problems, materials shortages, weather, and inflation), the cause is frequently poor management and lack of control. Often, the project manager is either the architect, engineer, or builder’s prime contractor. This works on small construction jobs, but on big jobs it does not because designers and contractors each represent separate interests. When things go wrong and arguments arise, both tend to be self-serving and there is no one who is impartial and can reconcile differences in the best interests of the customer (owner or developer).

A better arrangement is when the customer appoints an independent construction project manager to represent her interests during the entire design and construction process. Figure 3.8 shows two possible ways to arrange this, EPCM and EPC (“Engineering, Procurement and Construction Management” vs. “Engineering, Procurement and Construction”). In the figure, EPCM and EPC represent the independent project manager. In the EPCM case the customer contracts directly with the designer and building contractor; in the EPC case the independent project manager does this. In either case the project manager’s central position in the project organization enables her to monitor and coordinate all design and building tasks in accordance with the customer’s goals.

The main role of the EPCM project manager is to ensure that the designs are within the customer’s cost allowances and building requirements, and the builder’s work is executed in accordance with contract specifications and

at a fair price. The project manager is involved in everything—overseeing preliminary design, subcontracting, and controlling site work according to design specifications, schedule, budget, and safety rules. Although the customer signs contracts with the designer and the builder, the project manager acts as the customer’s agent to facilitate relationships among the parties.

An EPC project manager acts in much in the same manner as in EPCM, however, having contracted directly with the designer and the builder, the EPC project manager has full authority and accountability for all elements of the design and building of the structure, typically as a “turnkey” facility. As a consequence, the customer is much less involved in the project than in the EPCM case.

Figure 3.8 Alternative types of project manager in a construction project.

Even a contractor that might be capable of doing all the work itself may choose to subcontract because it has limited capacity or believes a subcontractor could do the work for lower cost or less risk. For development projects of large-scale

systems, the prime contractor will usually design the overall system and major subsystems, and will produce some elements of the system itself but subcontract the production of all others. In projects where significant portions of project work are to be subcontracted, the customer often mandates the scope of the subcontracted work and the criteria for selection of suitable contractors or suppliers.

Usually, obligations in subcontracts exist solely between a contractor and subcontractor. That means, for example, that the contractor (not the customer) is responsible for ensuring that a subcontractor performs work according to the requirements, and the contractor (not the customer) is obligated to pay for the subcontracted work. The contractor is also responsible for the quality of delivered materials, equipment, or components, and inspection at any subcontractor offsite facilities. Similarly, any communication about customer changes to requirements is channeled through the contractor to the subcontractor. (If however you are a subcontractor and are having trouble getting paid, you might appeal directly to the customer to pressure the contractor into paying you.)

Work that is contracted, subcontracted, or procured from suppliers is referred to as “procured” goods, work, and services. Like everything else in projects, procured work must be planned, scheduled, budgeted, and controlled—it must be managed. Called procurement management, this is described in Chapter 5.

See Chapter 5

Contract Negotiation17

Contract negotiation is the process of clarifying technical or other terms in the contract and reaching agreement on time, schedule, and performance obligations. Negotiation is not necessary for standardized projects for which the terms are simple and costs are fairly well known, but it is for complex systems that require development work or are somewhat risky. In fact, when an IFB (invitation for bid) for a standard or well-defined item is sent out and price is the only criterion, negotiation would be unethical and is not allowed. Different contractual agreements offer advantages to the customer and contractor, depending on the

nature of the project. These agreements are discussed in the Appendix to this chapter; they are, briefly:

• Fixed Price Contract: The price paid by the customer for the project is fixed regardless of the costs incurred by the contractor. The customer knows what the project will cost.

• Cost-Plus Contract: The price paid is based on the costs incurred in the project plus the contractor’s fee. The contractor is assured his costs will be covered.

• Incentive Contract: The amount paid depends on the contractor’s performance in comparison to the target price, schedule, or technical specification. The contractor either receives a bonus for exceeding the target or must pay a penalty for not meeting it.

The specific type of contractual agreement between the customer and the prime contractor determines the type of agreement negotiated with subcontractors. If the prime contract agreement is fixed price (FP), then subcontract agreements should also be FP else the prime contractor risks being charged more by subcontractors than will be received from the customer. If the prime contract is cost-plus or incentive, the contractor has latitude to use any type of agreement for subcontracts.

Negotiation is the last activity before a contract agreement is reached, but the negotiation process often begins earlier during proposal preparation because the terms in the proposal and the contract must be mutually consistent and acceptable to both customer and contractor. During negotiation, terms in the proposal related to specifications, schedules, and price are converted into legal, contractual agreements. Performance, schedule, and cost are interrelated, and a “package” agreement must be reached wherein all three parameters are acceptable to both parties. Final negotiation is the last formal opportunity to correct misperceptions that might have slipped through the RFP/proposal process. (Customers are always negotiating—informally—to get a better deal, even after the project is underway. The contractor must always be wary of saying and writing anything that might be construed as a promise to deliver more than is specified in the contract.) In highly competitive situations, the customer will try to play contractors against each other, seeking to raise performance specifications

while shortening the schedule and decreasing the price. Throughout negotiation, the project manager pushes the merits of his proposal.

His goal is to obtain the best possible agreement for his company. In countering customer objections to the proposal, the project manager’s best defense is a well thought-out project plan that shows what can or must be done to achieve the desired results. Details of the plan are used to define which parts of the schedule, work, or price are relatively “fixed” and which are flexible and can be negotiated.

To be able to negotiate from a knowledgeable and competitive position, the project manager must learn as much as possible about the customer and the competition. She should determine if the customer is under pressure to make a particular decision, faces an impending fiscal deadline, or historically has shown preference for one particular approach or contractor over others. The project manager should also know the competition—their likely approach to the problem, costs, and competitive advantages and disadvantages. She learns this from historical information, published material, or employees who once worked for competitors. (Relying on the last source is ethically questionable and, of course, works against the contractor whenever competitors hire its employees.)

To be able to negotiate tradeoffs, the project manager must be intimately familiar with the technical details of system design and related costs. Sometimes the contract will include incentive or penalty clauses as inducements to complete the project before a certain date or below a certain cost. To competently negotiate such clauses the project manager must be familiar with the project schedule and time–cost tradeoffs.

The signed contract becomes the binding agreement for the project. Any changes thereafter should follow formal change procedures, including change notices, reviews, customer approvals, and, sometimes, contract renegotiation— topics discussed in Chapter 11.

See Chapter 11

Contract Statement of Work and Work Requisitions

The contract contains an SOW that is similar to the SOW in the proposal or the

original RFP, or is a restatement of either to reflect the negotiated agreement. This so-called contract statement of work (CSOW) defines the expected performance of the project in terms of scope of work, requirements, end results, schedules, costs, and so on. The CSOW specifies the conditions under which the deliverables or end results will be accepted by the customer. Failure to clearly state these conditions can lead to later disputes and delays in completing the project.

Contracts with suppliers and subcontractors also include a CSOW, plus for each party the responsibilities and liabilities. Contracts for procured items include specifications, quantities, delivery schedules, costs, payment schedules, and ways to handle changes or variations.

When the customer and the contractor both agree on the CSOW, the project is considered “approved” and ready to go. Before work can actually begin, however, it must be divided among the involved departments and subcontractors of the SDO, and requirements specified in the CSOW must be translated into terminology that people in these groups understand. The translations, aimed at the groups that will perform the work, must be identical interpretations of the requirements and work scope specified in the CSOW. The document containing the SOW for each work group is called a work requisition or work order. Its purpose is to describe to each party the work expected of it and to authorize the work to begin. This topic is discussed further in Chapter 11.

See Chapter 11

Signing of the project contract marks completion of Phase A and authorization to begin the project and proceed to Phase B. The steps in Phase A are summarized in Figure 3.9.

Figure 3.9 Project initiation, proposal preparation, and project authorization process.

The process of initiating projects, preparing proposals, and negotiating and finalizing contracts often involves convolutions that cannot possibly be covered in a chapter. The following story illustrates.

Example 3.8: Proposal for the Apollo Spacecraft18

The US space program to land human beings on the moon involved thousands of contracts awarded by NASA in separate competitions. The biggest contracts were for the biggest components, namely, the Apollo spacecraft, the lunar lander, and the first, second, and third stages of the

rocket that would propel the spacecraft and lander to the moon. Harrison Storms was vice president of North American Aviation’s Space Division (NA) in Los Angeles when NASA opened bidding for the Apollo spacecraft. His division had already been working feverishly to solve difficult technical problems for a proposal to build the rocket’s second stage. The technical requirements were so demanding that only a handful of contractors had stayed in the competition. Most managers in the middle of such a big effort would have considered themselves already overextended, but not Storms: he wanted to go after the big prize contract—the Apollo spacecraft contract. The Apollo spacecraft would contain systems for life-support, guidance, and navigation (ultimately comprising over 2 million parts) and would take three men to the moon and back. Problem was, NA had never built a spacecraft before, and it would be expensive to learn how. Storms gathered up his best people and put together a presentation for the company chairman and founder, old “Dutch” Kindleburger, arguing that NA should prepare a proposal for Apollo. Dutch was skeptical but he pledged $1 million support. Storms knew that wouldn’t be nearly enough but took it anyhow. Now NA would bid on both the second stage and Apollo (Figure 3.10).

The RFP for Apollo allowed competing contractors 10 weeks to submit their proposals. Three competitors had already done Apollo studies and had a 12-month head start; one already had assigned 300 people to work on the concept, spent $3 million, and prepared a 900-page report. In large bids like this companies partner up to add muscle to the proposal, but all of the big aerospace contractors had already teamed up and NA was left to go it alone. Nobody believed Storms’ proposal team had a chance, including the company president.

Storm’s team labored feverishly, 7 am to 11 pm. Feeding them information were scores of engineers in shops, offices, laboratories, and wind tunnels throughout the company; to oversee them Storms picked the best leaders at NA he could find—smart, practical people with solid experience that others looked up to.

Good news arrived: NASA announced that NA had been chosen prime contractor for the second stage. But jubilation settled into gloom over prospects of also winning Apollo; practically nobody felt that NASA would

award two major contracts for the lunar program to the same company. The allotted $1 million had long since been exceeded—maybe by three

times, but no one knew. Back then cost statements ran 30 to 60 days behind billings, and Storms gambled that NASA would receive the proposal before his boss saw the final bill. With less than 6 weeks to go he picked John Paup to be Apollo program manager, someone he thought perfect for the role, a “witty, engaging person” who understood the technology. For the next month Paup listened to presentations 18 hours a day, slept in a cot, and ate from vending machines. Every morning he gathered his team for a standup meeting; anyone not there by 7:45 was locked out. No coffee, no seats, he wanted to hear the problems and how each would be fixed within 24 hours.

The proposal was encyclopedic in size, and NASA wanted dozens of copies submitted no later than 5 pm 2 days before the presentation. The whole bundle, weighing 100 pounds, was hand-delivered just under the wire. Next day Paup and his team, looking like zombies from lack of sleep, boarded the company plane for the presentation to NASA in Virginia. Each company had 60 minutes to present its proposal to an evaluation team of 75 top engineers, some of them legends. Undaunted, Paup hit all the presentation high points and finished 10 minutes early.

Figure 3.10 Apollo/Saturn moon rocket and North American components.

Picture courtesy of NASA.

Days later Storms received a telegram: NASA wanted to know how, given NA’s second-stage contract, it could possibly handle Apollo too? The written response was too long to telegraph back so Storms and Paup jumped on a plane to hand-deliver it. This violated an unwritten rule that a contractor does not meet with the customer evaluating the proposal. But Storms had little regard for such rules, especially with so much at stake.

Meantime NA headquarters had determined that the proposal cost five times the allotted $1 million, and it was fuming. But to say the overrun was worth it would be an understatement. North American won the contract, although it would take another year to formalize the details: in return for a

target cost of $884 million and a fee of $50 million, NA was to deliver several mockups, test versions, and flight-ready Apollo spacecraft (Figure 3.11). The risks of sending humans to the moon were overwhelming, so the contract was cost-plus. By the time the lunar program ended 10 years later with the return of the seventh crew from the moon, NA as prime contractor had earned $4.4 billion—over $27 billion in 2015 dollars.

Figure 3.11 Apollo spacecraft.

Photo courtesy of NASA.

3.7 Summary

The systems development cycle can be divided into four phases: conception, definition, execution, and operation. The first three phases constitute the project life cycle.

Phase one, conception, includes formulating the problem, defining needs and user requirements, evaluating alternative solutions, and preparing a proposal to conduct the project. At the start of this phase most activities are in the hands of the customer; by the end of the phase, the activities have been taken over by the contractor or system developer. The relationship between the customer and the contractor is initiated and cemented through the RFP/proposal process and contract negotiation.

Phase A is the “foundation” part of the systems development cycle; it establishes the needs, objectives, requirements, constraints, agreements, and patterns of communication upon which the remaining phases are built. It is a crucial phase and the place where, often the seeds of project success or failure are planted.

Appendix: Kinds of Contracts

A contract is an agreement between two parties wherein one party (the seller— the project contractor) promises to perform a service for another (the buyer—the client or customer), typically in return for payment.

Requirements about the service and the payment are clearly spelled out in the contract, which typically includes the following:

• Scope of work to be done or items to be sold, including support and ancillary (side) items such as manuals, documentation, and training. Any specifications and standards referenced are considered as part of the contract.

• Duties of the contractor in providing the work or items. • Time schedule allowed. • Duties of the client regarding payments (including a schedule for

milestones). • How changes to the contract and disputes will be handled. • How risks will be handled, including warranties, penalties, or

bonuses/incentives.

Different kinds of contracts provide different advantages to the client and the contractor, depending on the project risk and difficulty in estimating costs. Each party tries to negotiate the kind of contract and the terms that best serve its own interests.

The two fundamental kinds of contacts are fixed price and cost-plus. In the fixed price contract, the price is agreed upon and remains fixed as long as there are no changes to the project scope or provisions of the agreement. In the cost- plus (or cost reimbursement) contract, the contractor is reimbursed for all or some of the expenses incurred during the project, and as a result, the final price is unknown until the project is completed. Within these two types are several variations including some with incentives for the contractor to meet cost, time, or performance targets.19

Most projects involve multiple contractors and, hence, multiple contracts and a

combination of contract types, for example, cost plus for engineering and design, and fixed price for construction. This is often a good way to contract project work, especially for large projects.

Variables

The variables specified in a contract may include the following:

Cex and Cac

Target (expected) cost and actual cost of the project under normal circumstances. “Cost” represents monies expended by the contractor in

performing the work.

Fee Amount paid to the contractor in addition to reimbursable costs.

Price The price the client pays for the project. Price includes reimbursable costs (or a percentage thereof) incurred by the contractor, plus the contractor’s

fee.

Fixed Price Contracts

Fixed Price Contract

Under a fixed price (FP) or “lump sum” agreement the contractor agrees to perform all work at a fixed price. The contractor must be careful in estimating the target cost because, once agreed upon, the price will not be adjusted. If the contractor in the bidding stage estimates the target cost too low, he might win the job but make no profit; if he overestimates, he may lose the job to a lower priced bidder.

Example A1: Fixed Price Contract

Contract agreement:

Cost estimate, Cex = $100,000

Fee = $10,000 Price = $110,000

No matter what the project actually ends up costing (Cac), the price to the client remains $110,000.

When project work is straightforward and can be specified in detail, everyone prefers this kind of contract. Clients like it because they are less concerned about project costs. Contractors like it because clients tend to request fewer changes to the contract.

The disadvantage of an FP contract is that it can be more difficult and costly to prepare. The contractor risks underestimating the cost and losing money on the project, which might motivate him to increase the bid price or cut corners (use cheaper quality materials, perform marginal workmanship, or extend the completion date) during the project to reduce costs. To counteract this, the client can specify in the contract rigid end-item specifications and completion dates, and closely supervise the work. If, however, the project gets into serious trouble, bankrupts the contractor, and leaves the project incomplete, the client may be subject to litigation from other stakeholders.

Fixed price contracts do not work well in high-risk projects. Project sponsors often impose an FP contract, thinking that it transfers the risk of overruns to the contractor. Sometimes it does, but when a large project gets into trouble and the contractor cannot absorb the losses, the sponsor will have to keep paying to sustain the project.

FP contracts can be short-sighted. A project’s success often depends on the performance of the end-item long after the project is completed, yet the “fixed price” may force contractors to jettison things (cut corners) that diminish that performance.

Fixed Price with Redetermination20

Projects with long lead times such as construction or production have contract escalation provisions that protect the contractor against increases in materials, labor rates, or overhead costs. For example, the contract price may be tied to an

inflation index and be adjusted in the advent of inflation, or it may be redetermined as actual costs become known. In the latter case, the initial price is negotiated with the stipulation that it will be redetermined later to accurately reflect actual cost data. There are a variety of redetermination contracts: some establish a ceiling price for the contract and permit only downward adjustments, others permit upward and downward adjustments; some establish one readjustment at the end of the project, others allow multiple, periodic readjustments. Redetermination contracts are appropriate wherever design efforts are difficult to specify or the final price cannot be estimated for lack of accurate cost data. The redetermined price may apply to future items and items already produced.

Because the only requirement to renegotiate the price is substantiating cost data, redetermined contracts tend to induce inefficiencies. After negotiating a low initial price, the contractor may produce a few items and then “discover” that the costs are much higher than expected. The contract thus becomes a “cost-plus” kind of contract and is subject to abuse.

Any contract wherein all costs are reimbursed is called a “cost reimbursable” contract; these include the cost-plus and incentive contracts discussed next.

Cost-Plus Contracts

In complex, uncertain, or risky projects where it is difficult to accurately estimate project costs, cost-plus type contracts allows work to begin before the costs are fully determined.

Cost Plus Fixed Fee (CPFF)

Under a CPFF contract, the contractor is reimbursed for all direct allowable costs plus an additional, fixed amount to cover overhead and profit. This contract is justified when costs cannot be accurately estimated or rise due to changes in the project scope or factors beyond anyone’s control. Regardless of the actual cost the contractor’s fee remains the same, usually computed as a percentage of the target or estimated cost, Cex.

Example A2: Cost Plus Fixed Fee Contract

Contract agreement:

Cost estimate, Cex = $100,000 Fee = $10,000 Target price = $110,000

In addition to the fee, the client will pay for all allowable costs (perhaps “all” costs, Cac). Thus, if the project ends up costing Cac = $200,000, the price to the client is $210,000.

In contrast to FP contracts, CPFF agreements put the burden of risk on the client. The client does not know the project price until the end of the project, and the contractor has little incentive to control costs or do anything beyond minimum requirements since he gets paid the same fee regardless. A major factor motivating the contractor to control costs and schedules is the negative effect of overruns on his reputation. Another is that as long as the contractor’s workforce and facilities are tied up, he cannot work on other projects.

The contractor’s “profit” is ostensibly the fee above the cost, although, in reality, that might just be the tip of the iceberg since the contractor can profit from just about anything—materials, services, travel, etc. A contractor might specify a “fee” of $10 million but then profit another $100 million from fees added to materials and services. The client will learn about these added costs only through auditing the project. Contractors sometimes argue that the costs in a CPFF agreement are proprietary, however that is nonsense and the customer needs a good auditor to check on every cost during the project and before the contractor is paid. The client may also specify who is to be project manager or assign her own project manager to work alongside the contractor’s project manager.

Despite the risks, the client might have to resort to a CPFF contract just to attract contractors. CPFF is the contract of choice whenever the project involves high risk or the costs are difficult to estimate.

Guaranteed Maximum Price

With a CPFF the final price is unknown until the project is completed and the costs tallied, so a more appealing agreement to clients is the guaranteed maximum price (GMP) contract, which is a CPFF contract with a price cap. The GMP amount is negotiated and the client agrees to pay for actual project costs up to the GMP; for costs beyond that, the contractor is responsible. The GMP includes the contractor’s fee, which can be fixed or a percentage of costs.

Suppose the fee is set at $10,000 and the GMP at $110,000. If Cac ends up at $80,000, the customer pays the contractor $80,000 + $10,000 = $90,000. If Cac is $200,000, the customer pays the GMP, $110,000, and the contractor incurs a $90,000 loss.

Time and Materials Contract

A time and materials (TM) contract is a simple agreement that reimburses the contractor for labor and materials costs incurred in the project. It provides for payment of direct labor hours at an hourly rate that includes direct labor costs, indirect costs, and profit. Sometimes a ceiling price is established that may be exceeded, depending on the agreement. Charges for private consultants and the services of electricians, carpenters, mechanics, etc., are usually based on TM.

Incentive Contracts

When a contractor is unwilling to enter into an FP agreement and the client does not want a CPFF contract, an alternative is an incentive arrangement. This has features of both kinds of contracts: it is similar to CPFF in that costs are reimbursed, but the amount reimbursed is based on shared savings, i.e., any savings from Cac being less than Cex are split between the parties.

The sharing split is determined by the cost sharing ratio (CSR). A CSR of 80/20, for example, means that the customer and the contractor split the costs 80/20. This encourages the contractor to keep costs low because he pays 20 cents on every dollar spent above Cex but earns 20 cents more on every dollar saved below

Cex. As further incentive to reduce costs, the ratio might be changed for costs above Cex such that the contractor must pay a higher percentage. The contract appeals to both parties since the contractor can earn greater profit and the client pay a lower price.

Cost Plus Incentive Fee Contract (CPIF)

In a CPIF contract the project price is based partially on a percentage of the actual cost, Cac, and the CSR. The contract specifies the target costs, Cex, and the CSR, which specifies how any savings or overruns will be divided between the client and the contractor.

Example A3: Cost Plus Incentive Fee Contract

Contract agreement:

Cost estimate = Target cost = Cex = $100,000 Fee = $10,000 Target price = $110,000 Cost sharing: CSR = 50/50

CSR of m/n (m + n = 100) means that for any difference between target and actual cost, client gets m percent of any saving and pays m percent of any overrun. Price is computed as

Under target cost: Price = Cac + (Cex − Cac) x n+ Fee Over target cost: Price = Cex + (Cex − Cac) x m+ Fee

The incentive is for the contractor to keep costs below $100,000. Suppose Cac is $80,000 ($20,000 under Cex).

Price = $80,000 + ($20,000)(.50) + 10,000 = $100,000

The client saves $10,000 on price and the contractor earns a $10,000 bonus. The client must be vigilant to ensure that the incentive doesn’t lead the contractor to “cut corners” on work and materials.

Now suppose Cac is $200,000 ($100,000 over Cex).

Price = $100,000 + ($100,000)(.50) + $10,000 = $160,000 The contractor is $200,000 − $160,000 = $40,000 in the red.

A variation of CPIF is guaranteed maximum price—GMP. To continue the previous illustration, suppose the GMP is $130,000. If Cac is $200,000, the customer pays only $130,000, the GMP. With the GMP, the contractor is $200,000 – $130,000 = $70,000 in the red.

Commonly two CSRs are used, a different one each for under target and over target. See end-of-chapter review question 27.

Fixed Price Incentive Fee Contract

A Fixed Price Incentive Fee Contract (FPIF) is similar to a CPIF contract but has a ceiling on both price (GMP) and profit. The contractor negotiates to perform the work for a target price based upon a target cost (Cex) plus a fee, and for a GMP and a maximum profit. If the project cost ends up being less than the target cost, the contractor can earn a higher profit but only up to the maximum. If there is a cost overrun, the contractor will have to absorb some or much of it.

Example A4 Fixed Price Incentive Fee Contract

Contract agreement:

Cost estimate, Cex = $100,000 Fee = $10,000 Target price = $110,000 GMP = $125,000 (fee + reimbursement), client will pay no more than this Maximum profit = $15,000, contractor profit cannot exceed this

Cost sharing: CSR = 50/50, therefore:

• If Cac < $100,000, client will reimburse Cac plus an additional 50

percent of amount below $100,000, as long as the additional amount does not exceed $5,000.

• If Cac > $100,000, client will reimburse $100,000 plus an additional 50 percent of amount above $100,000, but the price cannot exceed $125,000.

Again, the incentive is for the contractor to keep costs low and not exceed $100,000. However, because the contractor cannot earn a profit of more than $15,000, there is little incentive for the contractor to cut corners to increase profit. Suppose Cac is $80,000 ($20,000 under Cex). The contractor gets paid $80,000 plus the $10,000 fee, plus an additional $5000 for the cost savings (50 percent of the $20,000 savings is $10,000, of which only $5000 is allowed because the maximum allowable profit is $15,000). Total price to client: $95,000, a $15,000 savings from the target price.

Suppose Cac is $200,000 ($100,000 over Cex). Fifty percent of the overrun is $50,000; that plus the fee plus $100,000 is $160,000. But the specified GMP is $125,000, which is all the client pays. The contractor suffers a $200,000 – $125,000 = $75,000 loss.

FPIF contracts are not true fixed price contracts. They invite a contractor to negotiate an unrealistically high Cex so that extra profits can be made through the incentive features. But unlike cost-plus contracts, they provide some assurance about a maximum price and some protection against the contractor cutting corners to gain a hefty profit. FPIF contracts apply to long duration or large production projects. They do not apply to R&D or other projects where the target cost is difficult or impossible to estimate.

Other Incentives Contracts21

Incentives can be applied to schedules and performance as well as cost or price. Similar to the CPIF and FPIF contracts, these agreements specify target project completion dates or target performance parameters for the end-item. The final price of the project “rewards” the contractor for exceeding the target or

“penalizes” the contractor for missing the target. Incentive agreements sometimes have negative effects, such as cost incentives

leading to schedule slippage. To offset this are so-called multiple incentives contracts that reward contractors for achieving targets associated with multiple criteria such as schedule, cost, and performance. Fee weights assigned to the criteria are used to determine the amount of “fee swing” allocated to each criterion. Consider the example shown below where the fee structure is similar to the CPIF example. Here the “fee swing” (Fmin to Fmax) is between 2 percent and 14 percent, or 12 percent.22

Cex = $100,000 Fex = $8 (8%) Fmax = $14 (14%) Fmin = $2 (2%)

The 12 percent fee swing is then divided among the criteria; for example:

Criterion Weight Fee Swing Performance (x) 0.5 6%

Cost (y) 0.25 3% Schedule (z) 0.25 3%

Total 1.00 12%

In engineering contracts, typically the largest weight is given to performance, followed by schedule and cost. To assess performance, several measures might be used at once, such as accuracy, range, reliability, and speed; an index is devised so all measures can be represented by a single performance factor.

In this example, performance is given a weight of 0.5, which yields a profit swing of 6 percent; schedule and cost are each given weights of 0.25, so each have a profit swing of 3 percent. The profit percentage is computed as a function of the three criteria according to the formula

P = (8 + x + y + z)% (Cex).

Values for x, y, and z, determined at the end of the project, would be based on the curves in Figure 3.12.

Figure 3.12 Multiple incentive contract.

Since the multiple criteria in this kind of contract tend to be interrelated (e.g. performance targets can be met, but for greater time and cost), the terminology and computations involved in structuring the contract tend to be tricky; hence, this type of contract is rarely used.

Review Questions

1. How are projects initiated? Describe the process. 2. What factors determine whether or not an idea should be investigated? 3. Who is the user in the systems development process? Who is the

contractor? 4. Besides the user and the contractor, what other parties are involved in

the systems development cycle? Give examples for particular projects. 5. What does the term “fast-tracking” imply? 6. How does the contractor (SDO) become involved in a project? 7. What is the role of an RFP? Describe the contents of an RFP. 8. What is a feasibility study? Describe its contents and purpose. 9. What are user needs? Describe the process of defining user needs and

the problems encountered. 10. What are user requirements? How do they differ from user needs? 11. Who prepares the proposal? Describe the proposal preparation process. 12. What is the statement of work (SOW)? In what documents does the

SOW appear? 13. Describe the contents of the proposal. 14. How is the best proposal selected? Describe the process and the criteria

used. 15. Three proposals (W, X, and Y) have been rated on six criteria as follows:

1 = poor, 2 = average, 3 = good. Choose between the three proposals using (a) the simple rating method and (b) the weighted rating method.

Criteria Weight W X Y Attention to quality 0.25 2 1 3

Cost 0.20 3 3 1 Project plan 0.20 2 2 1

Project organization 0.15 3 2 3 Likelihood of success 0.10 2 3 3

Contractor’s credentials 0.10 2 2 3

16. What contractor qualifications might the customer look for in a proposal? What else about the contractor might the customer look for?

17. What parties are considered subcontractors in a project? 18. Discuss the purpose of a business case study for internal projects. What

does the study include and who prepares it? 19. How is the RFP/proposal process adapted to large projects that

potentially have numerous stakeholders but initially only a few have been identified?

20. In contracting out work, does the customer relinquish all control over the project to the contractor? Explain.

21. How can a contractor be both the sender and receiver of RFPs; i.e., how can it both prepare and submit proposals, and receive and review proposals?

22. When a contractor hires a subcontractor, to whom is the subcontractor obligated—the end-user customer or the contractor?

23. What must the project manager know to be able to effectively negotiate a contract? Consider aspects of the customer, competition, and technical content of the proposal.

24. Discuss the difference between the SOW, CSOW, and work requisition or work order.

25. Describe the different kinds of contracts (refer to chapter Appendix). What are the relative advantages and disadvantages of each to the customer and the contractor?

26. A customer accuses a project manager for cost overruns and a delay in delivery. Why is it relevant whether the relationship between the customer and the project manager is governed by an EPC or EPCM contract?

27. Refer to the CPIF and FPIF example problems in Examples A.3 and A.4 in the chapter Appendix.

a. In both CPIF and FPIF cases, what is the price if Cac = $90,000? What is the contractor’s profit?

b. In both cases what is the price if Cac = $160,000. What is the profit?

c. Commonly two CSRs are used, a different one each for underruns and overruns. What are the answers to (a) and (b) if the CSR is 70/30 for underruns and 80/20 for overruns?

Questions About the Study Project

As appropriate, answer Questions 1–14 regarding your project. Also answer the following questions: How are contracts negotiated and who is involved in the negotiation? What kinds of contracts are used in the project?

Case 3.1 West Coast University Medical Center

West Coast University Medical Center (WCMC) is a large teaching and research hospital with a national reputation for excellence in health care practice, education, and research. Seeking to sustain that reputation, the senior executive board decided to install a comprehensive medical diagnostic system. The system would be linked to WCMC’s servers and be available to physicians from their homes and offices via the Internet. By clicking icons to access a medical specialty area, then keying answers to queries about a patient’s medical symptoms and history, a physician could receive a list of diagnostics with associated statistics.

The senior board sent a questionnaire to every department asking managers about the needs of their areas and how they felt the system might improve doctors’ performance. Most managers replied that the system would save doctors’ time and improve performances. The hospital information technology (IT) group was assigned to assess the cost and feasibility of implementing the system. They interviewed managers at WCMC and several vendors of diagnostic software. The study showed high enthusiasm among the managers and a long list of potential benefits. Based on the feasibility study, the board approved the system.

The IT manager invited three well-known consulting firms that specialized in medical diagnostic systems to give presentations, and then hired one to assist his group in selecting and integrating several software packages into a single, complete diagnostic system.

One year and millions of dollars later the project was completed, but 6 months later it was clear the system was a failure. Although it did everything the consultants and software vendors had promised, few doctors used it; of those that did, many complained that the “benefits” were irrelevant and that features of the system they would have liked were lacking.

Questions

1. Why was the system a failure? 2. What was the likely cause of its lack of use? 3. What steps or procedures were poorly handled in the project

conception phase?

Case 3.2 X-Philes Data Management Corporation: RFP Matters

X-philes Data Management (XDM) Corporation (motto: “The truth is out there”) is preparing to contract out work for two large projects: Scully and Mulder. The projects are comparable in terms of size, technical requirements, and estimated completion time, but are independent and will be performed by separate project teams.

Two managers at XDM, one each assigned to Scully and Mulder, prepare RFPs for the projects and send them to several contractors. The RFP for Scully includes the following: a SOW that specifies system performance and quality requirements, maximum price, completion deadline, and contract conditions; an incentives clause stating the contractor will receive a bonus for exceeding minimal quality requirements and finishing the project early, or will be penalized for poor quality and late completion; and a requirement that the contractor submit detailed monthly status reports showing progress on key quality measures. The RFP for Mulder includes a brief SOW, a maximum budget, and the desired completion date.

Based on proposals received in response to the RFPs, the managers

responsible for Scully and Mulder each select a contractor. Unknown to either manager is that they select the same contractor, Yrisket Systems. The Scully manager selects Yrisket because its bid price is somewhat below the budget limit and its reputation in the business is good. The Mulder manager selects Yrisket for similar reasons—good price and reputation. In preparing the Scully proposal, Yrisket managers had to work hard to meet the maximum price specified on the RFP, but they felt that by doing quality work they could make a tidy profit from the incentive offered.

A few months after the projects are underway some of Yrisket’s employees quit. To meet their commitments to both projects, Yrisket workers have to work long hours and weekends. It is apparent, however, that these extra efforts might not be enough, especially because Yrisket has a contract with another customer and must begin work soon.

Questions

1. What do you think will happen? 2. How do you think the crisis facing Yrisket will affect the Mulder

and Scully projects? The two projects are very similar, yet do you expect Yrisket to treat them the same?

Case 3.3 Proposal Evaluation for Apollo Spacecraft23

Five proposals were submitted to NASA to design and build the Apollo spacecraft. An evaluation board of more than 100 specialists reviewed the proposals and ranked them as follows (maximum = 10)

Technical Approach

(30%)

Technical Qualification

Business Strength (30%)

Weighted Total (40%)

Martin Company 5.58 6.63 8.09 6.90 General

Dynamics Astronautics

5.27 5.35 8.52 6.59

North American Aviation

5.09 6.66 7.59 6.56

General Electric Company

5.16 5.60 7.99 6.42

McDonnell Aircraft 5.53 5.67 7.62 6.41

Corporation

The board unequivocally recommended to NASA senior management that Martin be awarded the contract but suggested North American as the next- best alternative based upon NA’s experience in developing high- performance military and research aircraft. This experience (technical qualification) sufficiently impressed the board that it put NA ahead of General Dynamics, despite NA’s lower ratings on technical approach (design of the space capsule) and business strength (organization and management). The board mentioned that any shortcomings in NA’s technical approach could be corrected through additional design effort. Seeing the board’s recommendations—and aware of NA’s long, close association with NACA (NASA’s predecessor agency), NASA senior management immediately selected North American.

Questions

1. How were the points in the “Weighted Total” column determined? Show the computations.

2. North American rated third out of five contractors in the Weighted Total column, yet was awarded the contract. How did that happen? What are the lessons from this example?

Case 3.4 Contract Mess-Up at Polanski Developers

LaPage Power Company needed to upgrade the fire extinguishing system for the control room of a nuclear power plant. It selected Polanski Developers Company because Polanski was the only contractor willing to do the work for a fixed-price contract. Polanski’s $11 million price was based on its $9.5 million estimated cost for work and materials, and a fee of $1.5 million. Polanski managers felt the fee was large enough to provide ample profit and absorb any unforeseen work difficulties. The upgrade would require interfacing with many plant safety systems, some dating back to when the plant opened in 1985, and others that had been upgraded many times since.

The interfaces with other systems would make the upgrade complex and challenging. Polanski anticipated this, and to reduce the risk of a cost overrun contracted with Moreland Systems, a company with substantial experience in nuclear power plants. Moreland would be responsible for virtually all of the actual system design and installation. Said Billy Chester, Moreland’s project manager, “You never know what you’ll find in these kinds of projects.” He told Polanski that Moreland would take on the job, but

on a cost-plus basis only. The CPFF contract specified a target price of $10 million using Polanski’s $9.5 million cost estimate and a fee of $500,000. Polanski agreed.

When the project was completed—having encountered several unanticipated problems—Moreland’s bill was $14.5 million. The CPFF contract had specified periodic audits of Moreland’s costs but none were ever done.

Discuss the financial consequences to Polanski, Moreland, and LaPage. What should Polanski have done that could have altered the consequences? How does the choice of contract-type depend on the risks involved?

Endnotes

1. It could be argued that Phase D in an election-campaign project will be extended if the candidate is

elected, whereupon the “operation” phase represents the elected official’s full political term—but that

would be stretching the analogy.

2. Based upon information collected and documented by Cary Morgen from interviews with managers of

Jamal Industries (factual case, fictitious name).

3. Cusumano M. and Selby R. Microsoft Secrets. New York, NY: Free Press; 1995, p. 210.

4. A need is a value judgment that a problem exists. Different parties in an identical situation might

perceive the situation differently; as a consequence, a need is always identified with respect to a

particular party—e.g. the user. See McKillip J. Need Analysis: Tools for the Human Services and

Education. Newbury Park, CA: Sage Publications; 1987.

5. Cusumano and Selby, Microsoft Secrets. p. 210.

6. In the US a request for quotation or invitation for bid (IFB) commonly suggests that selection of a

contractor will be based primarily on price; in an RFP, the nature of the solution and competency of the

contractor are as or more important than price. Elsewhere in the world, the terms proposal and bid often

are used interchangeably, a bid being the equivalent of a full-fledged proposal.

7. Adapted from Frame J.D. Managing Projects in Organizations. San Francisco, CA: Jossey-Bass; 1987, pp.

109–110.

8. Ibid., pp. 111–126.

9. Sundblad D. “Sustainable Construction Techniques.”

http://greenliving.lovetoknow.com/Sustainable_Construction_Techniques, accessed November 12, 2014.

10. Hamilton G., Byatt G. and Hodgkinson J. “How project managers can help their companies ‘go green’:

Program and project managers can contribute to sustainability.” CIO, November 2, 2010.

http://www.cio.com.au/article/366509/how_project_managers_can_help_their_companies_go_green_/,

accessed November 14, 2014.

11. Hajek V.G. Management of Engineering Projects, 3rd edn. New York, NY: McGraw-Hill; 1984, pp. 39–57;

Rosenau M.D. Successful Project Management. Belmont, CA: Lifetime Learning; 1981, pp. 21–32.

12. Roman D. Managing Projects: A Systems Approach. New York, NY: Elsevier; 1986, pp. 67–72; Stewart R.

and Stewart A. Proposal Preparation. New York, NY: John Wiley and Sons; 1984.

13. Murphy O. International Project Management. Mason, OH: Thompson; 2005, pp. 159–161.

14. This section gives an overview of the important contracting issues. It is not intended to provide legal

advice about contracts; for that you need an attorney or contracts specialist.

15. Management of the complete project contracting process, including what and where to contract,

soliciting and assessing proposals, reaching a contract agreement, and administering the contract is

called “contract monitoring.” See Hirsch W. The Contracts Management Deskbook, revised edn. New

York, NY: American Management Association; 1986, Chapter 6.

16. Ibid., pp. 290–315.

17. See Hajek, Management of Engineering Projects. Chapters 8 and 9; and Rosenau, Successful Project

Management, pp. 34–41.

18. Primary source for this example is Gray M. Angle of Attack: Harrison Storms and the Race to the Moon.

New York, NY: W.W. Norton; 1992, pp. 87–116; the other source is Brooks C., Grimwood J. and Swenson,

Jr., L. Chariots for Apollo: A History of Manned Lunar Spacecraft. Washington, D.C.: NASA Scientific

and Technical Information Office, SP-4205; 1979, sections 2.5 and 4.2.

19. A complete description of contracts is given in Hirsch W. The Contracts Management Deskbook, revised

edn. New York, NY: Amocom; 1986, pp. 43–75. For construction contracts: Furst S. and Ramsey V. (eds)

Keating on Construction Contracts, 8th edn. London: Sweet and Maxwell; 2006.

20. Hajek, Management of Engineering Projects, pp. 82–83.

21. Miller R. Schedule, Cost, and Profit Control with PERT. New York, NY: McGraw-Hill; 1963, pp. 173–184.

22. Example from ibid., 174–175.

23. Brooks, Grimwood, and Swenson, Chariots for Apollo, Chapters 2–5.

Chapter 4 Project Definition and System Definition

When one door is shut, another opens.

—Cervantes, Don Quixote

If you build it they will come.

—Field of Dreams

The result of Phase A is a formalized systems concept that includes a (1) clear problem formulation and list of user requirements, (2) rudimentary but well- conceptualized systems solution, (3) elemental plan in the project proposal, and (4) agreement between the customer and the contractor about all of these. The project is now ready to move on to the “middle” and “later” phases of the systems development cycle and bring the systems concept to fruition.

Much of this, and the previous chapter, concern conceptualizing and defining the “system”—the end-item of the project. This is also a major thrust of the systems engineering methodology, which is often applied to projects that involve more stakeholders, greater technical complexity, greater risk, and have farther- reaching consequences than other projects. Interested readers are encouraged to see Appendix A at the end of the chapter for additional systems engineering

methods and tools.

4.1 Phase B: Definition

As Figure 4.1 shows, with approval of the project in Phase A, the thrust of the effort now moves to definition, design, production, and implementation of the solution. Most of the effort in Phase A was devoted to investigating the problem— what is it, is it significant, should it be resolved, and can it be resolved in an acceptable fashion? Now in Phase B, Definition, the solution is scrutinized: it is analyzed and defined sufficiently so that designers and builders will be able to produce a system that meets the customer’s needs.

The underlying principle behind Phase B, Definition, is, simply, prepare as best you can for what you intend to do before you start doing it. Definition says “Think through what you want to happen and how best to make it happen; do not just jump in and begin!” Definition is important because its outcomes dictate what will happen in the future. In the Definition phase, before things are defined and plans are set, planners still have broad latitude in decisions and the ability to influence project outcomes. Things are still easy to change because the “things” are just plans. Later in the project, after plans are set and work is underway, things are hard to change because the “things” include work already done or fully committed to. At some point the project will be stuck conforming to decisions already made, even bad ones. For instance, it is easy to decide in Definition whether a building will have 5, 10, or 15 floors. But once you decide on 10 floors, after 8 floors have been built you cannot change the decision to 5 floors (without tearing down 3 floors) or to 15 floors (if the foundation was built for only 10).

Figure 4.1 Four-phase model of system development cycle.

This is illustrated by three curves in Figure 4.2. Early in the project it is easy to make decisions that will affect the project outcome, and the cost of changing those decisions is little. Early on very little will have been spent (cumulative cost), so it is also easy to cancel the project then. As the project progresses, however, and especially after it enters Execution, the cumulative cost rises dramatically. It is not so easy to cancel the project then because of the high sunk cost. It is also not so easy to change decisions (go from 10 floors to 5 or 15 floors) because so much has already been done and it is costly to redo, undo, or alter it. Definition is that phase where ideas and plans are thoroughly flushed out before final commitments are made and work begins. The thrust of the phase is twofold: project definition and system definition.

Project Definition vs. System Definition

There are two ways to look at a project: one is to see the end-item or result of the project, the other is to see the effort directed at achieving that result. Looking at both is necessary: if you focus too much on the end-item and too little on the

effort, the project will run into problems for lack of preparation and coordination of resources, costs, and schedules; if you focus mostly on the effort and less on the end-item, the project will run into problems–this time for not meeting user requirements. System definition and project definition are equally important. System definition aims at achieving a good understanding of what the end-item must do to satisfy user requirements; project definition aims at specifying what the project team must do in the project to produce the end-item. While it is not surprising that much of the literature on project management is preoccupied with project definition, it is surprising how little attention it gives to system definition.

System definition begins with defining user needs and requirements; project definition begins with addressing those requirements in the project proposal. Hence, some of the definition work necessary for the project is initiated in Phase A. Phase B continues this definition work and concludes with a set of system specifications and a project plan—a full suite of everything necessary to execute the project in Phase C.

Figure 4.2 Project costs and ability to influence outcomes vs. project phase.

Project Kickoff

The project formally begins with a kickoff meeting—the first formal meeting of the project team and key stakeholders. The purpose of the meeting is to announce that the project is about to commence, communicate what the project is about, develop common expectations, and generate enthusiasm and commitment to project goals and deliverables. The project manager plans and runs the meeting. Attendees include the project team (or, if too large, only managers, team leads, and project staff), supporters, and others who should know that the project is about to begin. For a multi-location project, multiple kickoffs at each location or

a video or phone conference might be necessary. The kickoff runs 1.5 to 2 hours and is mostly a formal presentation with questions and answers at the end.

Invited attendees should be formally notified in advance and provided information about the meeting agenda, a list of invited participants and their project roles, and a rudimentary project plan. The meeting introduces the following: the project manager; the project SOW, goals, and deliverables; the proposed plan—budget, schedule, main work packages; constraints and risks; the customer, other key stakeholders, and their needs and requirements; the project organization and key team members; and immediate next steps and who is to do what. Much of this information will have been worked out for the project proposal; if not, the project manager and project team must prepare it prior to the meeting.

Every project should start with a kickoff meeting. For a large project, the proposal preparation effort should be preceded by a kickoff meeting; similarly, each project phase should be initiated with a kickoff.

The purpose of the kickoff is to provide information, not to reach consensus of opinion, develop working relationships, or establish guidelines so team members can work together. The latter is the purpose of team building, for which subsequent meetings should be held shortly after the kickoff. Team building is discussed in Chapter 16.

See Chapter 16

Project Name

The project name is often the first thing that people hear about the project—often with no accompanying explanation.1 The name will appear again and again in virtually all communication and persist for as long as the project—and perhaps longer. A carelessly chosen name can cause misunderstanding or a blank stare about the project; it can cause people to confuse the project with other projects; and it can influence the way they react to the project. Unless the intention is to obfuscate the project’s purpose (“Manhattan Engineering District”—the atomic bomb project; “Have Blue”—the F-117 stealth fighter project), the name should

clearly suggest what the project is about. Clever or cute names should be avoided; they tend to be ambiguous and,

sometimes, annoying. All projects are apt to acquire nicknames, which tend to indicate how people feel about the project (“Project from Hell”) but not much else. If, however, the nickname gains widespread usage, then sometimes the sensible thing is to formally adopt it. (Boston’s Central Artery/Tunnel became the “Big Dig”—not to be confused with Canada’s “Big Dig,” the Wascana Lake Urban Revitalization Project in Saskatchewan. The 1960s geological research project to drill through the earth’s crust to the Mohorovicic discontinuity was named Project Mohole, but as political and technical problems mounted, it became known as “Project Nohole.”) A project is often named for a place, person, or the end-item it creates (Petronas Towers; Bandra-Worli Sea Link Bridge), and for long-named end-items it is okay to adopt an acronym (BWSL)—though it’s always a good idea to first check the project name’s acronym before keeping the name; a serious project should not make people chuckle whenever they see its acronym (Automated Network for Uniform Security).

4.2 Project Definition

Project definition addresses the question: What must the project do to deliver the system concept and satisfy the user and system requirements? Project definition and system definition happen concurrently and interactively. The work to be done as laid out in the project plan must meet the system requirements, but the system requirements must conform to the work methods, budgets, and schedules specified in the project plan.

Detailed Project Planning

Prior to Phase B a portion of the project definition will already have been done: at minimum, some project definition was necessary in Phase A to prepare the project proposal. But that definition effort will have resulted at best in an outline of what is to come. During Phase B that outline must be expanded and elaborated in detail. The renewed definition effort will involve identifying the necessary work tasks and resources, creating schedules, budgets, and cost control systems, and the project team, its leaders, subcontractors, and support staff.

The project team begins to evolve from the skeletal group that prepared the proposal, sometimes in a cascading manner: the project manager selects team leaders who, in turn, fill in team positions under them. The project manager negotiates with functional managers to get specific individuals or people with the requisite expertise assigned to the project. Sometimes she seeks the customer’s approval in adding members to the project team, which is advisable whenever the customer must work closely with the team or when the customer might have an objection. Good customer–project team rapport is crucial to maintaining a healthy customer–contractor relationship.

Project Execution Plan

As key members of the project team are assembled they begin preparing the

detailed project plan—the “execution plan.” The audience of the execution plan is whoever will be doing the project, so the plan should address whatever they will need to know, including, for example:

• A scope statement or SOW that includes high-level user requirements and system requirements.

• Work breakdown structure and work packages or tasks. • Project organization and responsibility assignments. • Assignment of key personnel to work packages. • Project schedules showing events, milestones, or points of critical action. • Budget and allocation to work packages. • Quality plan for monitoring and accepting project deliverables, including

testing plan. • Risk plan and contingency or mitigation measures. • Procurement plan. • Work review plan. • Change control plan. • Implementation plan to guide conversion to, or adoption of, deliverables. • Health, safety, and environmental (HSE) policy/plan.

The execution plan is described more fully in Chapter 5, and elements of the plan are described throughout the book. Concerning the last element above, HSE, it is perhaps obvious that project management is responsible for protecting the project team, stakeholders, and society from injury during the project and long- term health hazards associated with the project and its outcomes. Minimally, the project plan must address measures to guard against accidents and health hazards as required to comply with industry standards and municipal, state, and federal laws and regulations, and, additionally, to meet the unique circumstances of the project.2 Company policies regarding HSE should be included or referenced in the project plan, and the project manager is responsible for ensuring the policies are implemented, that specific HSE roles and responsibilities are defined, and staff receive appropriate H&S training.3 Significant hazards that cannot be eliminated should be included in the risk management plan. Preparation of the HSE includes consideration of environmental and sustainability matters as discussed in

Chapter 3.

See Chapter 5

See Chapter 3

All of the elements of the execution plan must be integrated; each must be tied to, compatible with, and supportive of the others. Details of these elements are discussed in Part III, starting with the next chapter. Appendix C at the end of the book is a sample project execution plan.

In large projects the planning is divided into sub-plans created by subordinate members of the project team. The project manager coordinates and oversees their efforts to ensure that the sub-plans are thorough and tie together. The final plan is reviewed for approval by contractor top management and the customer. Contractor top management makes sure that the plan fits into existing and upcoming projects and capabilities, and the customer makes sure it conforms to user requirements and the conditions stated in the contract.

Anxious to get the project underway, many contractors skip reviewing the project plan with the customer. This is shortsighted since the plan might contain elements to which the customer objects. Often the project is conducted and implemented within the customer’s organization, so everything in the plan must fit: the project schedule must fit the customer’s schedule; project cash flow requirements must fit the customer’s payment schedule; the contractor’s personnel and procedures must complement those of the customer; and materials and work methods must be acceptable to the customer.

Once the project plan and system specifications have been approved by management and the customer, the project team turns its attention to the detailed design and building of the system; this is what happens in Phase C, as covered in Chapters 11 and 12. As will be explained later, however, project planning never stops; it continues throughout the project life cycle.

See Chapter 11 and Chapter 12

4.3 Phased (Rolling Wave) Project Planning

A major thrust of Phase B is to develop the project plan, but seldom does it produce a comprehensive, detailed plan for the entire project. The fact is, despite all the effort devoted to planning in Phase B, often the plan is developed in phases, not all at once. At the start of a project there are too many unknowns and it is impossible to specify exactly what will or should happen for the whole project. Only as the project progresses and the unknowns decrease can details in the plan be filled in. The situation is analogous to planning an off-the-road route to some destination, but without the benefit of knowing the obstacles. Since you can only see the landscape directly ahead, you can only plan the first part of the route in detail; beyond that, the route is vague. This is represented by Phase I in Figure 4.3a. As you move through Phase I, you see more of the obstacles ahead, which enables you to plan the next part of the route, Phase II (b). The process continues, filling in details of the route, phase by phase, until you reach the destination (c and d).

Figure 4.3 Phased project planning.

At the onset of a project the customer wants to know the project cost and completion date, which can be estimated by preparing an initial rough plan. Although much of the initial plan is somewhat vague (analogous to the shaded blob in Figure 4.3), the plan is usually sufficient to enable managers to estimateproject resources, time, and cost. As the project gets underway, more- detailed plans are created but only for the most immediate phase of the project (dotted line, Figure 4.3). Whereas the initial plan was based upon information from similar projects, estimates, and forecasts, the detailed portions of the plan are based upon facts about upcoming work, facts identified as the approaching work gets closer.

For highly unique projects, the initial rough plan should be seen as just that—a

rough indication of project deliverables, cost, and delivery date—but not necessarily a commitment. That plan was first prepared during the feasibility study or business case study, but as the project progresses, it is replaced with more detailed plans and more-specific work tasks and schedules. Only for the most immediate phase where the “terrain” is clearly visible is it possible to create a detailed plan and make commitments to work, dates, and costs. Application of this rolling-wave planning is a major feature of Agile projects, described in Chapter 13.

See Chapter 13

In some projects each phase concludes with a milestone or phase-gate where the customer or executive managers review the deliverables and project performance; if satisfied, they approve the deliverables and pay for work done thus far. At the same time, they review the detailed plan for the next phase and assess the costs, risks, etc. of the updated high-level plan for the rest of the project. Note that this requires the plan for each phase to be largely prepared in the prior phase, as illustrated in Figure 4.4. If satisfied with the plan, they authorize the project to proceed to the next phase. If a project is to be terminated, that happens only at the end of a phase; termination before then occurs only as the result of unforeseen events external to the project.

Figure 4.4 Detailed planning for each project phase.

Source: Adapted from Steyn H. (ed.) Project Management–A Multi-Disciplinary Approach. Pretoria: FPM

Publishing; 2003, p. 27.

In some organizations this “phase-gate” review process is a mere formality and a “rubber stamp” to proceed to the next phase. More often, however, it serves an important purpose, in some cases having strategic implications. For example, each phase-gate review can result in a:

(a) Green Light: all relevant stakeholders are satisfied with the work per form ed so far. Also, they accept the plans for the rest of the project and that the risks identified and the business impact of the project justify continuing with the project. The project is authorised to proceed to next phase.

(b) Yellow Light: the stakeholders feel the business impact of the project justifies continuing the project but do not feel that objectives of the previous phase were met or plans for the rest of the project are adequate.

The project team must re-do part or all of the preceding phase and/or improve the plan.

(c) Red Light: due to changes in the business environment, risks, or disappointing results from the preceding phase, stakeholders consider the business impact of the project as insufficient. The project is terminated. If the possibility exists that conditions might improve later, the project can be “put on ice” for later reconsideration.

In companies that do multiple simultaneous projects, phase-gate reviews are sometimes used to compare the projects—their benefits, resource requirements, and relative performance, and to determine which get the green, yellow, or red light; this is discussed in Chapter 18. The phased approach to project planning and approval is illustrated with Mary and Peter.

See Chapter 18

Example 4.1: Mary and Peter’s New House

Mary and Peter buy property to build a new house upon. They approach NewHome Construction and describe to Paul, the owner, what they have in mind. Among other things, they want to know what it would cost. Having been in the business for a number of years, Paul has an idea of the cost but is wary to quote a fixed price since he doesn’t know Mary and Peter very well and whether their tastes are cheap or expensive. Also, he is wary of possible hidden costs arising from, for example, poor soil conditions of the site. He therefore gives a range of possible prices based upon the estimated square footage of the house, and an estimate of when the house would be completed. Nobody has as yet made any commitments. On the question, “Where do we go from here?” Paul answers that the first phase is to do a concept design, after which he will deliver sketches of the house. He also describes the other phases of the project he foresees, and the deliverables, approximate schedule, and approximate cost for each.

Mary and Peter sign a contract for Paul to provide a preliminary design

and sketches. The contract specifies when they will see the design and sketches, what the sketches will include and exclude, and what they will cost. Within a month they receive and approve the design and sketches.

Paul now presents them with a second contract, this time for the detailed design to include drawings that the construction team will use to build the house. Just like the first phase, the contract specifies the deliverables (drawings), the delivery date, and the price. A few months later Mary and Peter approve the drawings and construction begins.

Paul notes that the construction work will also be done in phases, although now, he says, there is sufficient information about the project and its cost so that only one contract is needed. He shows them the contract, which lists the remaining phases of the project and includes a guarantee period (following completion of construction) during which NewHome will fix any defects free of charge. The contract indicates milestones and deliverables for each of the phases and specifies that a payment will be due upon reaching each milestone. Before each payment, Mary and Peter will have the opportunity to inspect the work and verify that it has been completed and meets workmanship standards as specified in the contract.

This example illustrates the benefits of phased project planning: at the start, NewHome does not have to commit to the cost of building an as-yet undefined structure, and during the project Mary and Peter do not have to commit to work beyond any one phase (in fact, at the conclusion of any contracted phase they can walk away from the project). The milestone payments improve NewHome’s cash flow and reduce interest payments on money for construction borrowed from the bank. They also provide NewHome with some protection against bad debt: if Mary and Peter miss a milestone payment, NewHome simply stops work.

Project phases form the basis of project methodologies and phase-gating as discussed in Chapters 17 and 18. In organizations that have project methodologies, project managers follow the prescribed sequence of standard phases for planning and executing projects.

See Chapter 17 and Chapter 18

Project Charter

The project charter is a proclamation that management has approved a project. For some projects, it is created once, following a feasibility study or acceptance of a proposal; for others, it is created and expanded at multiple points during the conception and definition phases. For internal projects, the charter serves the purpose of announcing and formally authorizing the start of the project. For external projects, that purpose is served by a contract, so, generally, no charter is required.

The charter describes the project to stakeholders in the organization and establishes the project manager’s authority to organize and make use of resources; thus, it should be signed by at least one executive manager. It includes whatever information is necessary to give the reader a good overview of the project. Often the charter contains sections similar to the project plan. Sometimes it is the project plan, although commonly it is somewhat brief and provides only an overview of the execution plan described earlier.

For any reasonably-sized project, the project charter is developed after some prior planning and a feasibility study. In large projects conducted in phases (e.g. FEL, described later), a charter is created for and used to authorize each phase. The PRINCE2 methodology prescribes three charters: one (called a “mandate”) authorizes the first, pre-project, stage of the project; another (a “brief”) authorizes the second, initiation, stage; and a final set of documents (“project initiation documentation”) authorizes subsequent stages.

For a small project or initial phase of a project, the charter can be a short document simply stating approval for the project or phase. For most projects, however, it is more comprehensive and can include the following:

• Project vision, purpose, benefits; problem it will solve or opportunity it will exploit.

• Project justification (business case and environmental impact analysis findings).

• Approach to be followed. • Project scope statement. • Main deliverables, criteria for acceptance, individuals responsible for

acceptance. • Clients and key stakeholders. • Identification of the project manager and his authority and responsibilities. • Identification of other decision makers, their authority, responsibilities, and

reporting relationships. • Listing of resources, including project team staff, required training,

subcontractors, etc. • Project organization and work breakdown structure. • Project budget summary and cash flow plan. • Master schedule, project phases, key milestones, planned due dates. • Perceived risks and issues. • Plans for: procurement: safety, health, environmental protection;

communication. • Control procedures.

Despite similarities, the project charter and the execution plan differ in two important ways. First, the purpose of the charter is to describe, justify, and authorize the project; the purpose of the execution plan is to give direction to stakeholders working in the project. This leads to major differences in the content of each and, usually, an execution plan that is substantially longer, more detailed, and comprehensive than the charter.

Front-end Loading4

A variation of phased project planning and approval used by some industries (chemical, mineral, oil, and gas) in major industrial infrastructure projects (typically costing over $1 billion) is the “front-end loading” (FEL) approach. FEL overlaps the Conception and Definition phases in Figure 4.1 and includes all the data gathering, analysis, and documentation necessary to justify and launch a project. It is divided into three phases, FEL-1, FEL-2, and FEL-3.

FEL-1, called “Opportunity Identification,” is the idea-generation and

evaluation phase; it corresponds somewhat with the “pre-project stage” in the PRINCE2 methodology. The proposed project is in competition with other projects to receive funding, thus the objective of FEL-1 is to confirm that the project is compatible with organizational strategy and is a “preferred project” (discussed in Chapter 18). The output of FEL-1 is a preliminary business case that confirms the feasibility of the proposed capital investment.

See Chapter 18

FEL-2 goes by different names depending on industry, for example “business planning,” “concept study,” and “appraise.” In this phase the project is “shaped” in terms of scope, technology selection, and execution strategy. The output of FEL-2 is a detailed business case as well as a scope statement that enables reliable cost and schedule forecasts. Typically only 1 percent of the total project costs are incurred during FEL-1 and FEL-2.

FEL-3 is “project definition” and includes preparation of a detailed project execution plan, advanced conceptual design, and some detailed system design (which in the Figure 4.1 methodology is placed as the first stage of Execution). FEL-3 is often divided into sub-phases that go by such terms as “facilities planning/execution planning,” “pre-feasibility/feasibility,” and “select/FEED (Front-End Engineering Design).” The output of FEL-3 is a project execution plan, conceptual (ready for detail) design, basic engineering plan, and detailed project charter. By the end of FEL-3, typically 3 to 5 percent of the total project cost is spent, a relatively small amount to ensure that project risks are acceptable before committing full funding to the project.

Each FEL phase is followed by a gate: FEL-1 to assess the robustness of the business case, FEL-2 to assess the completeness of the scope definition, and FEL-3 to determine if the project is ready to execute. Since FEL-3 is the most expensive part of FEL, it is not undertaken unless the project has already been approved. The project approval decision happens at the FEL-2 gate, which means that the FEL-2 phase must be very thorough and address all factors important in the decision. Project cancellation at the FEL-3 gate happens rarely and only with changes in the project environment (sharp drop in market, business downturn, dropout of a major business partner).

Besides project definition, FEL also addresses system definition, described next.

4.4 System Definition

Systems are defined from their requirements. Requirements are therefore the starting point for all systems development projects and the foundation for project planning. Each requirement impacts end-item scope and complexity, which in turn impact project work effort, time, cost, and risk. Unless the requirements are clearly defined and agreed upon, it will be impossible to fully conceptualize the end-item and create a viable project plan. With the contract signed and the project about to get underway, the user requirements defined in Conception should be reviewed and any gaps and ambiguities eliminated.

User Requirements Revisited

For products and systems in competitive markets, user requirements are initially framed in general terms; for example, outperform the F-22, taste better than Joe’s beef jerky, obtain at least a 20 percent rate of return, or upgrade to the latest software release. General requirements such as these must be expanded before serious development work and project planning can be started. As shown in the next example, poor requirements definition can lead to project failure.

Example 4.2: User Requirements for Product Development

The marketing group for a kitchen appliance manufacturer wrote the requirements for a new food processor. The requirements specified the general size, weight, usage, price, and sales volume of the proposed product, but nothing about product performance, which the engineering design group set by studying competitors’ products. The food processor as developed met all the requirements set by marketing and engineering, yet it was obsolete before it even launched because competitors had released products better-

suited to customer needs. In defining the product, both the marketing and engineering groups had ignored the user requirements for the food processor —i.e., the requirements as specified by actual user customers.

Defining complete, accurate requirements is not easy. Among the problems are:

• Requirements must incorporate information from not only the user but also functional areas such as marketing, engineering, manufacturing, and outside stakeholders.

• The information needed to define requirements is not always available when definition occurs, so it is easy to overlook necessary requirements or include unnecessary ones.

• The requirements include vague terms that cannot be accurately measured (e.g. “modern” or “low cost”).

• The user or contractor are unable to adequately describe the requirements because the end-result is complex, abstract, or artistic.

• The customer or contractor intentionally define requirements in ambiguous terms to allow latitude in results later in the project.

Problems like these result in confused project planning and, later, disputes between the customer and contractor over whether the end-result met the requirements. The following steps can reduce such problems.5

• Convince both the user and contractor groups of the importance of clear, comprehensive definition of requirements. Users and contractors often are reluctant to devote the time necessary to define clear and complete requirements.

• Check for ambiguities and redefine the requirements so none remain. • Augment written requirements with nonverbal aids such as pictures,

schematics, graphics, and visual or functional models. • Avoid rigid specification of requirements that are likely to change due to

uncertainty or changing environment. • Treat each requirement as a commitment to which both the user and the

contractor agree and sign off. • After the project begins, monitor the requirements and resist attempts to

change them. • Use a change control system to assess the necessity and impacts of changes

before deciding whether or not to approve them.

Detailed user requirements come from one source: the user. The project manager, however, should not be accepting of just any requirements provided by the user, but should offer assistance in defining them. Just as users sometimes require help in understanding the problem or need, they also might need help in specifying their requirements. They may not understand the cost, schedule, or other ramifications of requirements, or what will be necessary to fulfill them.

For most projects the list of high-level user requirements (summary or bullet points) should fit on one page for easy reference. Early in the project the contractor will refer to the list when preparing the project’s scope statement; at the end of the project the customer will refer to it to determine the acceptability of project results and end-items.

Preliminary definition of user requirements happens during the feasibility study and proposal preparation, and a summary of user requirements is included in the contract. In simple systems, user requirements rarely exceed a few lines or a page. In big systems, however, they might fill volumes. An example of the former is user requirements for a contract to perform a 1-day management seminar; an example of the latter is user requirements for the 9-year, multibillion dollar Delta Project to prevent the North Sea from flooding the Netherlands.

System Requirements

A major thrust of Phase B is translating user requirements into system requirements. System requirements are oriented toward the solution; they specify the contractor’s approach and objectives for satisfying the needs as spelled out in the user requirements. But beyond fulfilling user requirements, a project must also fulfill contractor needs. For example, besides being profitable the contractor might specify requirements to keep skilled workers and costly production facilities occupied.

System requirements define the system or solution approach—including the principle functions, system architecture, and resulting end-item (system, solution, or product)—and provide a common understanding among project team members as to what must be done in the project. Whereas user requirements represent the user’s perspective, system requirements derive from the contractor’s perspective. They state what the systems must do to satisfy the user requirements. Following are examples contrasting user requirements and system requirements:

User Requirements System Requirements Will Address 1. Vehicle must accelerate from 0 to

60 mph in ten seconds and accommodate six people.

Vehicle size and weight, engine horsepower, kind of transmission.

2. House must accommodate a family of four.

Number and size of rooms.

3. House must be luxurious. Quality and expense of materials and decorative features.

4. Space station must generate electricity for life support,

manufacturing, and experimental equipment.

Type and kilowatt capacity of power- generating equipment; technology for

primary operation and backup operation.

5. Aircraft must be “stealthy.” Design of configuration and external surfaces; types of materials; usage of

existing or newly developed components.

System requirements specify what the project’s designers and builders must address in designing and building the end-item. The following illustrates this for the X-Prize/SpaceShipOne project introduced in Chapter 1.

See Chapter 1

Example 4.3: High-Level System Requirements for Spaceship

Below are five user requirements for the spaceship, each followed by one or

more system requirements. The former specify the user requirements, the latter what the spaceship and its subsystems and components must do to satisfy those requirements.

1. Attain altitude of at least 100 km:

1.1 Motor must provide enough thrust (i.e., be powerful enough)

1.2 Motor must burn long enough 1.3 Vehicle must be lightweight

2. Capacity for three people:

2.1 Cabin must be large enough

3. Comfortable flight:

3.1 Cabin temperature must remain at comfortable level 3.2 Cabin pressure must remain at comfortable level 3.3 Vehicle acceleration force must not exceed certain level 3.4 Cabin must have sufficient elbowroom

4. Relatively inexpensive to design, build, and launch:

4.1 Fuel and fuel handling procedure must be economical 4.2 Structural materials of vehicle must be economical 4.3 Whenever possible, uses existing, off-the-shelf technology

and systems 4.4 Requires few people to maintain vehicle

5. Capable of being “turned-around” in at most 2 weeks:

5.1 Minimum repair/replacement of parts/modules between flights

5.2 Minimum refueling time 5.3 Minimum cabin cleaning time

Notice, the system requirements specify “what” the system must do, not “how” it will do it. They say, e.g. “the motor must generate enough thrust to propel the spaceship to 100 km. before it runs out of fuel,” but not how. Addressing the “how” comes later.

Defining requirements sufficiently so that designers will know what they are striving for is called requirements analysis. The result of the requirements analysis is a comprehensive list of functional requirements.

Functional Requirements

Functional requirements specify the functions that the new system must be able to perform to meet the user requirements. For example, the functions of the spaceship include propulsion, handling and maneuverability, human habitability, safety, and support and maintenance. The common tool for identifying the functional requirements of a complex system is the functional flow block diagram, FFBD, described in Appendix A to this chapter. All significant functions for the system, its subsystems, components, and interfaces, including for support and maintenance must be identified. Most systems perform several basic functions, each of which has numerous sub-functions.

Associated with each functional requirement are targets or performance requirements. These specify in technical terms—e.g. physical dimensions, miles per hour, turning radius, decibels of sound, acceleration, percent efficiency, operating temperature, operating cost—the target requirements that the function must satisfy as well as the tests, procedures, and measures to be used to prove that the targets have been met. The project team refers to these performance requirements in the design or purchase of components for the system.

In addition, other requirements might be imposed on the overall system or on specific subsystems and components. The following are typical:6

1. Compatibility. Ability of subsystems to be integrated into the whole system or environment and to contribute to objectives of the whole system.

2. Commonality. Ability of a component to be used interchangeably with an existing but different type of component. A “high commonality” system contains many available off-the shelf (OTS) components; a “low commonality” one has many that must be newly developed.

3. Cost-effectiveness. Total cost of the system if a particular design is adopted. This includes the cost of the design as well as the cost for implementing and operating the design to achieve a given level of benefit.

4. Reliability. Ability of the system or component to function at a given level or for a given period of time before failing.

5. Maintainability. Ability of the system to be repaired within a certain period of time (i.e., the ease with which it can be repaired).

6. Testability. Degree to which the system can be systematically tested and measured for its performance capabilities.

7. Availability. Degree to which the system can be expected to operate when it is needed.

8. Usability. Amount of physical effort or strain, technical skill, training, or ability required for operating and maintaining the system.

9. Robustness. Ability of the system to survive in a harsh environment. 10. Expandability. Ability of the system to be easily expanded to include

new functions or be adapted to new conditions.

These requirements are sometimes called “non-functional” requirements (!) because they are not tied to particular functions and are desired of the entire system and its components.

Requirements Priority and Margin

Two properties of each requirement are its priority and margin. The priority of a requirement is, simply, the relative importance of the requirement. When multiple requirements conflict so that not all of them can be met, priority determines which will be met and which not. Suppose a product is specified to perform in a certain way and be a particular maximum height, but performance has priority. Knowing this will be useful to the design team if later they determine that to achieve the specified performance the height requirement must

be exceeded. Related to priority is the margin on a requirement—the amount by which the

requirement can vary. For example, the requirement “maximum height of four feet; margin of two inches” tells designers that in case they must exceed the height requirement, they have at most two more inches.

Requirements Breakdown Structure

During requirements analysis, system functions are sorted and assigned to logical groups. The requirements breakdown structure (RBS) in Figure 4.5 is a simplified example showing ways of grouping requirements. The RBS should include every identified functional requirement; in large systems these can number in the hundreds or even thousands.

The purpose of the RBS is to provide a common reference for everyone working on the project. Often a requirement will pertain to multiple system components, which means that multiple project teams will be working to meet that requirement. The RBS enables these teams to coordinate efforts and avoid omissions or duplication.

System requirements provide general direction for the project, but they are high-level and not detailed enough to tell the project team what it must design, build, or purchase to create the end-item system. Stipulations must be placed on each of the requirements; these are called system specifications.

Figure 4.5 Requirements breakdown structure.

System Specifications

System specifications are derived from system requirements. They define the end-item and its subsystems, components, and processes in sufficient depth so that the project team will be able to design, build, and/or purchase those subsystems and components.

System specifications are the basis for specifications of lower-level subsystems, which are the basis for specifications of even lower-level subsystems. From the system specification for a new automobile, for example, specifications are derived for the auto’s drive train, suspension, steering system, brake system, etc. The specifications for these lower-level components normally take the form of a drawing or, for a commercially-available “off-the-shelf” (OTS) item, a catalog number.

Example 4.4: System Specifications for Spaceship

The progression from user requirements to system requirements and from system requirements to system specifications is illustrated in Figure 4.6. At the top, the system requirement “Motor must provide enough thrust” is derived from the user requirement “Spaceship must reach 100 km”; in turn, the system specification “Motor must provide ≥ 88 kN thrust” is derived from the system requirement “Motor must provide enough thrust.” (Note, kN or kilo newton, is a measure of force.) System specifications tell the project team what it must do and targets it must meet. For example, besides the motor having a specific thrust, another specification, 4.1.1, says the motor will burn nitric oxide and rubber. Since there are no OTS motors that do this, this says the team will have to design and build one from scratch. The multiple arrows to each specification in the last column indicate that each specification must satisfy multiple requirements.

Figure 4.6 Relationships between user requirements, system requirements, and system specifications

for spaceship.

Traceability

Developing clear specifications is important, but so is keeping track of their relationships to each other and to system requirements. Throughout the systems development cycle numerous changes and tradeoffs will be made to the requirements that will each impact multiple specifications.

For example, altering the spaceship weight (Figure 4.6, system requirement 1.3) will impact the spaceship’s required launch altitude (specification 1.20.1) and the motor’s required thrust and burn time (1.1.1 and 1.2.1). Because weight impacts so many of the specifications, a designer cannot be cavalier about doing anything that might alter it. Any decision affecting weight must be assessed for the impact it will have on the specifications for launch and rocket motor. The ability to trace the effects of changes in some specifications and requirements to others is called “traceability.” A useful tool for this purpose is the traceability matrix, described in Appendix A to this chapter. The process of managing all of this—identifying specifications, tying them to physical components, tracing the impacts of changes, and controlling changes so requirements are met and do not conflict is called configuration management and change control, discussed in Chapters 9 and 11.

See Chapter 9 and Chapter 11

System specifications are the criteria that will guide actual project work; they are written by and for project subject-matter specialists—systems analysts, programmers, engineers, product and process designers, consultants, etc.—and they address all areas of the project—design, fabrication, installation, operation, and maintenance. System specifications should be set so as to meet but not exceed customer baseline specifications, which are high-level specifications the customer can understand. This is one way to prevent “scope creep,” i.e., the growth of project requirements that causes project budgets and schedules to also grow.

Iterative Design-Testing and Rapid Prototyping

The definition of requirements and specifications, and the design and testing of the system usually happens iteratively, particularly when the project end-item is complex. The requirements cannot be completely defined without some amount of prior design work, and the design work cannot be completed without some amount of prior fabrication and testing. The overall process generally cascades down as illustrated in Figure 4.7, with occasional loops-back and repeated steps. Work that flows from stage to stage like this is called the waterfall process. To assess and modify specifications, often a prototype is used. A prototype is an early running model of a system or component built for purposes of demonstrating performance, functionality, or proving feasibility. It is built according to initial specifications and then tested; if, based upon tests, the specifications are changed, then the prototype is modified and tested again. This process ensures that the basic system design supports the system specifications.

Figure 4.7 Iterative development cycle (waterfall process) for complex systems.

It can be difficult to conceptualize the system when no system exists like the one to be developed. The system that the customer “sees” might be very different from the one the developer envisions, yet without a physical or working model the difference might not be apparent. Requiring the customer to specify and sign- off on requirements early in the project only intensifies the problem. It forces the customer and developer to commit to decisions before they reach a mutual understanding about the requirements.

In a process called rapid prototyping, a rudimentary, intentionally incomplete model of the product that is initially somewhat simple and inexpensive is produced.7 The rapid prototype (RP) model represents key parts of the system but not the complete system, and is somewhat easy to create and modify. The customer experiments with the RP to assess the system’s functionality and determine any necessary modifications or additions. After a few iterations of experimenting and modifying requirements, the final requirements and design concept are firmed up. In software development, the RP might be a series of screens or windows with queries to allow a user to “feel” what the system would be like. Architects use physical scale models of buildings for the same purpose. They know that a physical model is always better than a drawing or lists of requirement for conveying the look, feel, and functionality of a design. Drawings and requirements tell the development team what is expected, but the RP process ensures that drawings and requirements are finalized only after the customer has accepted them as represented by the RP model.

Ordinarily, the RP process will not speed up the definition phase; instead, it might lengthen it. The first RP model will likely be incorrect, though it will enable the customer and developer to experiment, learn, and eventually select optimum requirements. RP models and mockups are used, for example, to demonstrate the form and functionality of the shapes and sizes of control panels used in plants and equipment, and to design the interior layouts of automobiles and aircraft cabins.

Agile Project Management

The waterfall approach in Figure 4.7 (and, generally, the phases of A, B, and C in

Figure 4.1) applies to projects where the requirements can be defined early in the project and will not change afterward. Such situations are like a waterfall: the projects move “down” from one stage to the next. But also like a waterfall, it is hard to go the other way, which is analogous to what happens when the stages of a project must be repeated. When the requirements in a project cannot be completely defined early on or will change significantly, then steps in the project have to be repeated. The waterfall process is able to accommodate this (the back- arrows in Figure 4.7), although not very effectively, because altering the requirements midstream is costly and time-consuming. Waterfall applies to projects where requirements can and must be defined early (e.g. designing and constructing a new building or airplane); for projects where the requirements cannot be defined or will certainly change (e.g. some software projects), so-called agile methods are better.

In agile project management, the project is divided into a sequence of small, iterative efforts, each conducted by a team devoted to meeting a limited set of requirements and releasing a partial result or solution. The end-item system is developed in a series of quick iterations, where, in effect, the stages of definition, design, development, and testing are repeated. Each iteration (called a “sprint” because it is short—a month or less) delivers a partial yet stand-alone and fully functional result. At whatever time the project is terminated, the customer is left with usable results as produced up to that point. Agile project management is the topic of Chapter 13.

See Chapter 13

Team Involvement in Definition

As requirements and the project plan are being developed, questions arise, “How do you know when the requirements are complete?” and “How do you keep everyone in the project focused on those requirements?” The problem is especially tricky when the project involves numerous people and teams, and spans months or years. Part of the answer is: make the system and project definition a team effort incorporating the perspectives of everyone who has or

will have a significant stake in the project—customers, suppliers, functional areas such as engineering, marketing, manufacturing, customer service, and purchasing, and users and operators. The more these individuals and groups have a hand in defining requirements and the project plan, the better the project plan will account for the requirements and the needs and interests of all stakeholders throughout the system life cycle. Everyone in the project should be working to the same set of requirements—a master requirements document, RBS, or equivalent. Any additional, necessary requirements should be derived from and compatible with this master document.

In product development projects, a good way to generate product requirements is at an off-site workshop for all the key project stakeholders, including functional groups, users, and suppliers. Beginning with a list of customer needs or requirements, the team develops the system requirements (or, lacking adequate user requirements, develops them too). For complex systems, a better approach is to create a team comprised of all key stakeholders for the purpose of defining requirements. The term for this is concurrent engineering, which implies the combined efforts of key stakeholders to define requirements to the satisfaction of everyone. The term is somewhat misleading because concurrent engineering involves not just engineering but marketing, purchasing, finance, quality, and more.

Concurrent engineering teams are sometimes called design-build teams because they combine the interests and involvement of designers and builders into a single effort.

Example 4.5: Design-build Teams at Boeing8

At one time in the Boeing factory the production plant was located on the main floor and the engineering group was upstairs. Whenever a problem occurred in the plant, engineers just walked down to take a look. Today, Boeing employs many thousands of people at several locations, and such easy interaction isn’t possible. Similar to other large corporations, as Boeing grew, its finance, engineering, manufacturing, and planning units evolved into “silos,” each with strong self-interests and little interaction with the

others. In the development of the 777 commercial aircraft, Boeing wanted to change that and implemented the “design-build team” concept, or DBT. Each DBT includes representatives from all involved functional units, customer airlines, and major suppliers. The concept emerged from one question, “How do we make a better airplane?” The answer required not simply a good understanding of aircraft design and manufacture, but also knowledge of aircraft operations and maintenance. To capture such knowledge, customers, manufacturers, and designers joined together early in the project to discuss ways of incorporating all their objectives into the aircraft design.

The formation of DBTs mirrored the physical breakdown of the major subsystems and subcomponents of the airplane. For example, the wing was divided into major subsystems such as wing leading edge and trailing edge, and was then further broken down into components such as inboard flap, out-board flap, and ailerons; responsibility for each subsystem and component was handled by a DBT.

The project required 250 DBTs, each with 10 to 20 members and run like a little company. The teams each met twice weekly for a few hours, following a preset agenda coordinated by a team leader. The concept of having so many people at design meetings—people from airlines, finance, production, and quality—was totally new, but with so many people representing so many interests there were actually few conflicts.

Since most components in an airplane interact (interface) with numerous others, most participants in the program had to be assigned to multiple DBTs (to insure their components would work with other DBT’s components). The manufacturing representative, for instance, belonged to 27. His duty was to tell engineers what would happen when their elegant designs met with the realities of metal, manufacturing processes, and assembly line and maintenance workers, and he offered suggestions that would improve the airplane’s maintenance. One suggestion concerned the cover on the strut-faring that holds the engine to the wing. The faring would contain a lot of electrical and hydraulic components that maintenance personnel would need to access, but engineers hadn’t noticed that repairing the components would require removal of the entire faring. The manufacturing rep noticed, however, and suggested adding two big doors,

one on each side of the faring. This improved access to the components inside and greatly simplified their repair.

Concurrent engineering teams are discussed more fully in Chapter 14. Another practice for defining requirements and keeping the project focused on them is quality function deployment (QFD). This is covered in Appendix B to this chapter.

See Chapter 14

4.5 Summary

There are good reasons why the project life cycle approach is used in so many kinds of projects. First, it emphasizes continuous planning, review, and authorization. At each stage results are examined and used as the basis for decisions and planning for later stages. Second, the process is goal oriented—it strives to maintain focus on user requirements and system objectives. Mistakes and problems are caught early and corrected before they get out of control; if the environment changes, timely action can be taken to modify the system or terminate the project. Third, user requirements and system requirements are always in sight and activities are done so that they are coordinated and occur at the right time and in the right sequence.

The front-end phases of a project—conceptualization and definition—are important to the viability and success of the project. What is surprising is the short-shrift given to user and systems requirements definition in so many projects, and the impetus to begin preparing a plan without even knowing what the end result of the project is supposed to be. Project definition and system definition go hand in hand; only in cases where there is much latitude in terms of what the customer wants, when he wants it, and how much he is willing to pay can a project succeed in the absence of good requirements. In the more usual case (the customer is more demanding and the schedule and budget are constrained) success is predicated on a well-defined description of what the end result must be and do—the user requirements and the system requirements.

Appendix A: Stages of Systems Engineering9

The systems engineering methodology described in Chapter 2 follows a series of stages that closely parallels that of the project life cycle and systems development cycle. A misnomer, really, systems engineering is not “engineering” in the same context as other engineering disciplines. Rather, as described earlier, it is a logical process employed in the evolution of a system from the point when a need is first identified, through the system’s planning, design, construction, and ultimate deployment and operation by a user. The process, outlined in Figure 4.8, has two parts, one associated with the system’s development and production (Stages 1 through 4), the other with the system’s utilization (Stage 5).

See Chapter 2

Stage 1. Needs Identification and Conceptual Design10

The main tasks of this stage, which are analogous to project life cycle Phase A, are to define stakeholder needs and requirements, perform feasibility analysis, and perform high-level requirements analysis, system-level synthesis, and system design review. The result of this stage is a “functional baseline” design—a list of high-level requirements and high-level functions of the intended end-item system.

Stakeholder and Needs Identification

Figure 4.8 Stages of the systems engineering process.

Systems engineering deals with poorly defined problems. The customer may feel that something is wrong, or something new is required but be unclear about the source of problem or need, or what thesystem should look like or do. Sometimes it is not even clear who has the problem or need. The first step in systems engineering is identifying the parties who will be affected by or able to impact the system. Even identifying the “customer” is not trivial; it might be an organization, but within the organization only certain parties will have the authority to make decisions relating to the system, or will use, operate, or be impacted by it. These parties must be singled out and their needs identified.

Developing a clear conception of the need or problem begins by asking basic questions:11

1. How did the problem or need arise? 2. Who believes it is a problem or feels the need? 3. Is this the root problem or need, or is it a manifestation of a deeper

problem? 4. Why is a solution important? How much money (or time, etc.) will it

save? What is the value of the system that will solve the problem? 5. How important is the need? Would resources be better applied to another

need?

Answers to these questions lead to a preliminary description of a system that addresses the need or problem, including its expected performance, cost, and schedule. The customer reviews the description and perhaps redefines the need, in which case the contractor must redefine the system description. The process continues back and forth until parties agree on the need definition and proposed system.

Requirements Definition

High-level requirements specify everything important about the system—its objectives, life cycle, operational modes, constraints, and interfaces with other systems. As discussed earlier, they should address all the stakeholders—producers, suppliers, operators, and others who will ultimately use and benefit from, manage, maintain, and otherwise impact or be impacted by the system—and reflect their interests and perspectives: for example, corporate customers who are interested in the system’s market, capacity, and operating and capital costs; operators who are interested in its performance, durability, reliability, parts availability, etc.; and users who care about its comfort, safety, and usability.

In systems engineering practice, the initial requirements are stated in the language of the stakeholders and compiled in a list called the stakeholder (or user) requirements document (SRD). Anyone reading the SRD should be able to readily understand the mission and application of the intended system. The project should not be started until the principle stakeholders have reviewed and endorsed the SRD.

Example A4.1 SRD for the Spaceship12

As an example, let’s revisit the X-Prize/SpaceShipOne project described in Chapter 1. The criteria of the competition were to send a reusable vehicle capable of carrying three people into space twice within 2 weeks. Besides winning the X-Prize, a goal of developer Burt Rutan and customer Sir Richard Branson was to develop technology that would enable low-cost space tourism. Among the constraints were a relatively small budget and a small development company with limited resources. Hence, the SRD would include developing a spaceship with the following requirements:

See Chapter 1

1. Can minimally attain 100 km altitude. 2. Carries three people. 3. Provides comfortable flight. 4. Is relatively inexpensive to design, build, and launch. 5. Can be turned around in 2 weeks or less. 6. Is inherently safe to operate.

Feasibility

The next step is to identify high-level (system-level) alternative ways to meet the needs, objectives, constraints, and requirements. The alternatives are evaluated in terms of costs, risks, effectiveness, and benefits using studies and models; the most feasible solutions are recommended to customers and supporters.

Requirements Analysis

With approval of the project and system-level alternatives, the next step is to specify what the system must do to be able to meet the requirements in the SRD. For example, the stakeholder requirement that the spaceship “provide comfortable flight” implies system requirements that the spaceship’s cabin

temperature, humidity, and pressure all remain at “comfortable” levels throughout the flight. This implies that the spaceship will be equipped to perform the necessary functions to make this happen. Whereas the SRD specifies the system in terms of stakeholder wants or needs, the system requirements tell the designer the functions the system must perform and the physical characteristics it must possess to meet the SRD. This process of defining requirements, called requirements analysis, results in a document called the system specification, described later. Requirements analysis for physical systems addresses three kinds of requirements: functional, performance, and verification.

Functional Requirements

Figure 4.9 FFBD for decomposing system-level functions into lower-level functions.

Functional requirements specify the functions that the new system must perform to meet all the requirements in the SRD, including those for system support,

operation, and maintenance. A popular tool for analyzing and defining functional requirements is the functional flow block diagram, FFBD, illustrated in Figure 4.9. Each block represents a function that the system must perform to satisfy requirements. As illustrated, each function is defined in greater detail by decomposing it into sub-functions; for example, as shown function 3 is logically comprised of five sub-functions, 3.1 through 3.5. In the conceptualdesign stage, the decomposition of functions into smaller, better-defined sub-functions proceeds only to the next level (e.g. subdivides function 3 into 3.1–3.5). Later, in the preliminary design stage, the decomposition will resume and continue to whatever level necessary to arrive at the best possible requirements definition. In the figure, this is shown by decomposing function 3.5 into functions 3.5.1–3.5.4.

Notice the numbering scheme used in Figure 4.9: each and every function has a unique identifier that enables it to be traced to the original system-level function; e.g. function 3.5.4 contributes to function 3.5, which contributes to function 3. This “traceability” of functions is essential because throughout the system life cycle numerous changes will be made to components and functions, and for each change it is necessary to know the impact on higher-level and lower-level functions. This helps prevent mistakes that could lead to later problems. For example, the cryogenic tanks in the Apollo 13 spacecraft were originally designed to operate at 28 volts. Later on, the spacecraft design required that certain controls be changed to 65 volts. This involved changes to numerous components, including to the cryogenic tanks, but somehow the linkage between tanks and controls was missed, and the changes were never made. During the mission this mistake caused a tank to explode, which ruined the mission and nearly cost the lives of the three astronauts.

Example A4.2: Functional Requirements Breakdown for the Spaceship

Figure 4.10 shows a portion of the FFBD for the spaceship, and decomposition of the system-level functions that address stakeholder requirements 3 and 5. The other system-level functions would be decomposed as well.

Figure 4.10 System-level breakdown of functions for spaceship.

Performance and Verification Requirements

Associated with each functional requirement are performance requirements and verification requirements. Whereas a functional requirement states what the system must do, a performance requirement states how well it must do it. Performance requirements are usually specified in physical parameters such as speed, acceleration, weight, accuracy, power, force, or time. They are the targets on which designers set their sights. For example, the stakeholder requirement “provide comfortable flight” has many functional requirements, including some for cabin temperature and pressure. The associated performance requirements for these might be:

1. Cabin temperature: 75–85 degrees F 2. Cabin pressure: 4.2–3.2 psi.

Accompanying each performance requirement is a set of verification requirements; these specify procedures, measures, and tests to verify that the performance requirement has been met. For example, verification requirements would specify the kinds of tests to prove that cabin temperature and pressure will remain at the required performance levels during spaceflight.

Synthesis

Up until now the systems engineering process has been focused on top-down analysis, resulting in a big list of functional, performance, and verification requirements. The next step, synthesis, looks at relationships among the system- level requirements and alternative ways of satisfying the requirements. One question is, can these requirements be satisfied using existing, “off the shelf” (OTS) designs and products, or will it be necessary to employ new and different designs or technologies? An OTS item is one that can be readily purchased or built; if it meets the requirements, an OTS item is often preferable to a newly designed one because it is readily available and usually less costly. Sometimes there is no OTS item and to create a new design that meets the requirements would be overly costly, risky, or time-consuming; in such cases the requirements must be revised.

The result of synthesis is called the “system specification,” which is a comprehensive list of all the functions the new system must satisfy plus a firm or tentative solution (to be developed or bought) for each function. The system specification serves as a guide for designers in the later stages of preliminary and detailed system design.

Example A4.3: System Specification for Spaceship Motor

A decision must be made about the kind of rocket motor the spaceship will have. Among the functional requirements for the motor are:

1.1 Must provide thrust of x 4.1 Cost of fuel and fuel handling must be economical 5.3 Refueling procedure must be simple 6.1 Fuel, fuel system, and fuel must be inherently safe

A check of existing OTS rocket motors used to launch satellites shows that none fit the requirements; all are too costly to fuel and operate and are somewhat dangerous. Hence, a new rocket motor must be developed—one that will be simple and inexpensive to fuel and operate, safe, and provide the necessary thrust. Experiments reveal a promising solution: a motor that uses ordinary rubber as the fuel and nitrous oxide (laughing gas) as the oxidant; both materials are stable, safe, inexpensive, and easy to handle. The decision is made to adopt the technology and design and build a completely new motor. Thus, one system specification for the spaceship (of many hundreds) is that the rocket motor burns nitrous oxide and rubber.

The system specification is reviewed and checked against the functional requirements at a formal meeting. When approved, it becomes the “functional baseline” or template for all subsequent design work.

Stage 2. Preliminary Design13

The purpose of the preliminary design stage is to translate system-level functional requirements into design requirements for the subsystems. This stage roughly corresponds with Phase B. Studies are performed of the high-level elements comprising the system, and the system-level requirements are allocated among the subsystems.

Functions of Subsystems

The FFBD process as illustrated in Figure 4.10 is now repeated to decompose the system-level functions into subsystem-level functions and, as before, to define

functional, performance, and testing requirements for each functional block. The functions are decomposed to whatever level necessary to completely define each subsystem and permit decisions about whether each function can be met with an OTS design or product, or whether it must be designed and built from scratch. In preliminary design, there is a subtle shift in focus away from what the system will do to how it will do it. The shift is from functional design to physical design.

Example A4.4 Decomposing Functions into Subfunctions

Figure 4.11 shows the FFBD for function 5.5, mating (attaching) the spaceship with the launch vehicle. This requirement is derived from the system-level requirement of “turnaround in 2 weeks or less.”

Figure 4.11 FFBD for mating SpaceShipOne and White Knight.

Suppose the performance requirement for mating the spaceship to the underbelly of the mothership is set at 10 hours. Having decomposed the function into all of the subfunctions in the procedure, planners are then able to set time requirements for the subfunctions such that the overall mating procedure will not exceed 10 hours.

Grouping of Functions: Architecture and Configuration Items

The next step is to group the identified functions and requirements according to the physical architecture of the system. In general, the term “architecture” refers to the major components in a system and how they are configured or arranged to

satisfy the functions of the system; for example, the architecture most people have in mind for a bicycle is:

• Major components: two wheels, frame, seat, pedals and chain, handle bar. • Configuration: wheels attached at ends of frame; front wheel pivots on

frame; seat mounted on frame between wheels; pedals attached to frame, linked by chain to rear wheel; etc.

Sometimes the architecture “looks right,” sometimes not. Often, in order to satisfy unique requirements, designers are forced to stray from the commonplace architecture, the result being a “funny-looking” architecture.

Example A4.5: Architecture of the Spaceship

The spaceship will have airplane features of a fuselage and wings, but also spacecraft features of a rocket motor and ability to maneuver in space. Unlike an airplane where the cabin and fuselage walls are the same, the cabin in a spaceship is a separate “pressure vessel” fitted inside the fuselage. The spaceship architecture will include the following subsystems:

• Fuselage: structure containing or attached to other subsystems (cabin pressure vessel, hydraulics, avionics, motor, fuel system, wings, etc.).

• Cabin pressure vessel: contains seats, storage space, instruments and flight controls, and environmental control system.

• Rocket motor: main propulsion system, fuel system, motor controls. • Avionics: aviation electronics; computers, subsystems for

communication, navigation, flight controls, auxiliary power system, etc.

• Wing/aerodynamic surfaces: main wings, tail, and hydraulic/electronic actuators.

• Landing gear: gear doors, braces, skids or tires, brakes.

Each major subsystem will perform a major function or set of system-level

functions as listed in the functional baseline. From this point onward, each of these subsystems will be called a configuration item or CI. In general, a CI is a subsystem or component whose history is documented and monitored throughout the system’s complete life cycle—its design, production, and usage. The purpose of this documenting and tracking (i.e., configuration management) is to ensure that any changes in the design, production, or usage of the CI do not alter or degrade its ability to meet the functional requirements. Configuration management utilizes “traceability” to prevent snafus such as the voltage change that caused the Apollo 13 accident mentioned earlier. It pertains to not only major subsystems, but any items identified as critical to performance, risky, or costly.

Requirements Allocation

As of this point the design consists of (1) a list of the functional requirements and (2) a high-level design of the system—the major subsystem or CIs (the system architecture). The next step is to “allocate” the functional requirements to the CIs, which means to assign responsibility for each functional requirement to one or more of the CIs. The purpose here is to ensure that every functional requirement will be addressed (and hopefully satisfied) by at least one of the subsystems or CIs. The resulting allocations are shown in an “allocation matrix” or “traceability matrix”: shown in Figure 4.12, the matrix columns are the subsystems responsible for meeting the requirements; the matrix rows are the requirements that the subsystems must fulfill.

With this allocation the transition from functions to physical items accelerates. Since each of the CIs represents something that will ultimately be a physical item —a piece of hardware, software, or both, assigning functional requirements to CIs represents a transition in thinking from what must be done (e.g., travel 100 km above the Earth) to how it will be done (with a spacecraft that has a fuselage, cabin, wings, and engine, configured in a certain way).

Notice in Figure 4.12 that responsibility for some requirements is shared by more than one CI. For example, the weight of the system (requirement 1.5) is shared by all the CIs. That is to say, the spacecraft weight is the sum of the

weights of all the CIs, and if the weight of any one is changed, so is the weight of the spacecraft. If the maximum loaded weight of the spacecraft is set at 3,600 kg, the CIs must be designed so that all of them combined will not exceed that weight.

Figure 4.12 Allocation or traceability matrix.

Source: Adapted from Falconbridge R. and Ryan M. Managing Complex Technical Projects. Boston: Artech;

2003, p. 78.

Example A4.6: Allocation of Weight among CIs

Question: How do you design and develop all of the CIs such that in the end the total weight (shared requirement) does not exceed 3,600 kg? Answer:

estimate the percentage of the total spaceship weight that each CI should account for, and set that as the “target” design weight for the CI. For example, allocate, say, 30 percent of the total system weight to the fuselage and contents, 20 percent to the motor, 20 percent to the wings, 10 percent to avionics, and 10 percent for everything else. Hence, the fuselage target weight would be 0.30 x 3,600 kg = 1,080 kg, the motor target weight is 0.20 x 3,600 kg = 720 kg, and so on. Since achieving targets is critical, each is designated as a Technical Performance Measure, or TPM, which means that as the CIs are being designed their estimated and actual weights are carefully compared to the targets. If during the project it becomes clear that a target cannot be achieved (as will surely happen), then the allocations are readjusted. If, say, the weight of the motor cannot be held to its target but must be increased by 30 kg, then either the allotted weights for other subsystems must correspondingly be reduced by or the target spaceship weight increased by 30 kg. Throughout the design process it will be necessary to adjust the CI targets and allocations as guided by the TPM process. This process is described in Chapter 11.

See Chapter 11

Interfaces

None of the subsystems function independently; all rely on the outputs of other functions and, in turn, provide inputs to still others; in a word, they interface. Part of the preliminary design process is to identify all interfaces in the system and establish requirements for the interfaces. A main source of information about interfaces is FFBDs. For example, the FFBD in Figure 4.11 shows that function 5.5 receives input from functions 5.3, 5.4 and 4.6.6 and provides input to functions 8.6.3 and 9.3. Each arrow represents an interface and the “flow” of something between functions. The “thing” flowing can be:

• Physical—mechanical connections, physical joints and supports, pipes.

• Electronic—analog or digital signals. • Electrical—electric energy. • Hydraulic/pneumatic—liquid or gas. • Software—data. • Environment—temperature, pressure, humidity, radiation, magnetism. • Procedural—completion of a procedural step so another next step can

begin.

Identifying the interfaces is necessary for setting requirements on the inputs and outputs of every subsystem and element. For example, since the fuselage of the spacecraft contains the motor and also supports the wings, neither wings nor motor can be designed without also considering the design of the fuselage, and vice versa. The requirements for each interface (e.g. allowable maximum or minimum flow or physical strength) are set by a design team that includes representatives from the subsystems at both sides of the interface.

Synthesis and Evaluation

Designing each of the CIs and its subsystems and elements involves choosing among design alternatives and, again, deciding whether to buy or modify an OTS design or product, or to develop a new design from scratch. An OTS design or product that meets all or most of the requirements for a CI and is not too costly will be purchased; otherwise the CI must be designed from scratch.

The selection of alternatives in the preliminary design stage must consider the synthesis of components—the impacts of each design decision on other components and the overall system. Following is an example.

Example A4.7: Tradeoffs in Designing Cabin Size

The weight requirement for a spacecraft is a big deal because the greater the weight, the more thrust (power) required of the rocket motor to propel the vehicle into space and the greater the load-carrying capacity of the mothership to carry it aloft. At some point early in the conceptual design the

maximum weight will be set, and thereafter every effort will be made to find ways to reduce it. Consider below some tradeoff decisions that designers face.

How big should the cabin be? In general, the cabin should be roomy enough to hold three people, instruments and controls, and stowage; a bigger cabin would be more comfortable for the occupants but would also weigh more. Suppose a cabin of volume m is chosen, which will result in an estimated weight of w for the spaceship. Suppose also that to propel a vehicle of weight w into space will require a rocket motor with thrust of y (Figure 4.13, top diagrams). Note that if the cabin size is increased, then the thrust of the rocket motor must also be increased—unless weight somewhere else in the spaceship can be reduced.

Figure 4.13 Impact of cabin size on vehicle weight, rocket thrust, and landing gear.

Now consider the impact of vehicle weight on another decision: landing gear. The more the vehicle weighs, the stronger the required gear; but, all else being equal, the stronger the gear, the heavier the gear. If the weight of a typical wheeled landing gear, strong enough to support the vehicle, is deemed too high, then an alternative must be considered, such as a skid (Figure 4.13, bottom). The skid has no wheels and weighs less than a wheeled gear. If the skid meets other functional requirements, then it would be chosen over a wheeled landing gear.

Such tradeoff decisions will be necessary for all the CIs and other components. As decisions are made, a design evolves that meets the requirements. The form and configuration of the CIs is set, and the physical appearance of the system begins to take shape. By the end of the preliminary design stage the system architecture will have been established, and all system-level requirements allocated among the major subsystems (CIs). Combined, the architecture and allocated requirements form the “allocated baseline” design (see example, Figure 4.14).

Figure 4.14 Pictorial representation of major subsystems (CIs) and allocated baseline design. (The “funny-

looking” architecture derives from the spaceship having to meet many requirements. On re-entry, the wings

rotate upward, making the spacecraft one big airbrake that floats to Earth like a shuttlecock, thus avoiding

high speed and high temperature. Nearer to the ground the wings tilt back and the ship glides to a landing.)

Stage 3. Detailed Design and System Development

The detailed design stage involves further description of subsystems, assemblies, components, and parts of the main system and support items. It roughly corresponds to tasks performed in Phase B and early Phase C.

Everything up to this point has been analytical in nature. With detailed design, the development process moves from “concepts on paper or computer”—the SRD, system specifications, FFBDs—to a design that is ready to build. Decisions are made about whether subsystems and components will function manually or automatically; whether components will be electronic, mechanical, or hydraulic;

whether input-output will be manual, mechanical, electronic, and so on. Available OTS components are selected on the basis of surveys or laboratory tests, and newly developed components are tested experimentally using models that enable designs to be verified by trial and error. Models or mockups for components (“breadboards”) are used to develop pieces of equipment that will subsequently be mated and integrated into the overall system. A prototype (nearly complete system) is assembled for purposes of developmental testing and evaluating the overall system in terms of satisfying requirements. Different type models and mockups for testing are described in Chapter 9.

See Chapter 9

System development and design testing and evaluation includes:14

1. Checking the operation of subsystems when combined in the complete system.

2. Evaluating the validity of design assumptions. 3. Paying close attention to the interfaces:

a.feedback and “cross talk” among subsystems. b.adjustments and calibrations. c.serviceability and maintenance.

The system is checked under a variety of conditions and operational modes. Problems previously overlooked often come to light during these tests. Designs are modified to eliminate deficiencies, or to correct them, and improve the system.

Example A4.8: Testing SpaceShipOne

Numerous ground and flight tests of SpaceShipOne resulted in changes; for example:

• In one test flight the spacecraft began to pitch wildly and only with

great difficulty was the pilot able to regain control. Engineers diagnosed the cause as being a too-small tail, which they quickly redesigned. (Problem was, the small company did not have a wind tunnel in which to test it. Undeterred, they mounted the tail assembly on a Ford pickup truck and checked it by racing up and down the runway.)

• The nose skid showed excessive wear after tests and had to be replaced by one with a stronger material.

When there is not enough time or money to build test mockups, then the first few manufactured models are subjected to testing and design evaluation. Gradually, as modifications are made and the design is approved, full-scale production begins. Design and development testing is phased out and replaced with quality control to ensure the end-item system as produced will conform to design specifications.

At this time, the methods, resources, and capability to produce the system (process design) are also addressed. This involves the design of new (or redesign of old) facilities and manufacturing processes, selection of specific materials and pieces of equipment, and preparation for production control, quality testing, manufacturing tooling, product transportation, personnel hiring and training, and data collection and processing.

Stage 4. System Fabrication, Construction and/or Production

Analogous to the latter part of Phase C, in Stage 4 the system is (1) mass produced, (2) produced in limited quantities with different features, or (3) built as a single item. This stage begins as soon as the design is approved and “frozen.” The stage involves acquiring materials and controlling production/construction to uphold performance, quality, reliability, safety, and other requirements.

Stage 5. System Operation and Support

Stage 5 completes the systems engineering process. Analogous to Phase D, the customer maintains and operates the system until it wears out or becomes obsolete. The system developer might continue to support the system in any of several ways: assisting in deploying, installing, and checking out the system; assisting in day-to-day operation or field service and maintenance support; modifying or enhancing the system to ensure continued satisfaction; or providing support in closing, phasing out, and disposing of the system at the end of its life cycle. The last way, system closeout and disposal, is a major consideration in the design and operation of systems that have potential to degrade the surrounding environment. The design of nuclear reactors and mines for metals and coal, for example, must account for the way each will be shut down. Their closeout must include measures to restore the land, clean up wastes, and remove toxins from soil and water, which can be expensive, time-consuming, and extend the system life cycle by years or decades.

Example A4.9: Life Cycle of SpaceShipOne

Preliminary development of SS1 and its support systems began in 1999, and full development began in April 2001, albeit in total secrecy. Exactly 2 years later Dick Rutan announced intentions to capture the X-Prize and flight- testing began (Figure 4.15).

Figure 4.15 SS1 beneath mothership White Knight.

Photo courtesy of John Nicholas

In May 2004, Mike Melville piloted the craft on a test above 100 km, making him the world’s first civilian astronaut. On October 29 he again flew SS1 into space, and less than 2 weeks later so did pilot Brian Binney, winning the $10 million X-Prize for the SS1 team (Figure 4.16). Today SS1 hangs in display at the Smithsonian Air & Space Museum in Washington, D.C. A bigger spaceship, SS2, and a bigger mothership, WK2, have since been developed for use by Sir Richard Branson’s commercial “spaceline,” Virgin Galactic, which hopes eventually to operate a fleet of them.

Figure 4.16 Designer Burt Rutan (center) and pilots Mike Melville (left) and Brian Binney.

Photo courtesy of John Nicholas.

Appendix B: Quality Function Deployment15

QFD is a methodology for defining requirements and, specifically, for translating customer needs into system or product characteristics, and specifying the processes and tasks needed to produce the system or product. As demonstrated in numerous applications QFD not only yields end-item results that meet customer needs, but it does so in less time and at a lower cost than traditional development methodologies. QFD was developed by Mitsubishi’s Kobe Shipyards in 1972, adopted by Toyota in 1978, and has since been implemented by companies throughout the world.

House of Quality16

QFD mandates that the project team articulate the means by which the product or system being designed will achieve customer requirements. The process starts with market needs or customer requirements and then uses a planning matrix called the House of Quality to translate the needs or requirements into technical requirements. The structure of the house is shown in Figure 4.17.

• The left side of the matrix lists “what” the customer needs or requires. • The top of the matrix lists the design attributes or technical requirements

of the product; these are “how” the product can meet customer requirements.

• Additional sections on the top, right, and bottom sides show correlations among the requirements, comparisons to competitors, technical assessments, and target values.

Figure 4.17 Structure of the house of quality.

Features of the house of quality are illustrated in Example A4.10.

Example A4.10: House of Quality for a TV Remote- Control Switch

Figure 4.18 is a portion of the house of quality matrix for the design of a television remote-control (RC) switch. The house is interpreted as follows:

• Rows (Customer requirements): these are what customers think is important about the product. They are the product “whats.”

• Importance to customer: The requirements have been rank ordered 1–

6 by customer preference; “multifunction buttons” is rated the highest; “RC easy to see/find” the lowest.

• Columns (Technical requirements): These are the requirements or attributes of the product, the ways that the product meets customer requirements. They are the product “hows.”

• Central matrix: Contains symbols that show the strength of the relationship between the whats and the hows (strong positive, positive, negative, strong negative). For example, “buttons easy to see” has a strong positive relationship to the size and color of the buttons, and a positive relationship to the size of the remote-control chassis. Note that each relationship has a numerical weighting (small = 1, medium = 3, strong = 9).

• Importance weighting: The weights of the symbols in each column are summed to determine the relative importance of the technical attributes. Thus, the most important technical attribute is “dimensions of the RC” (weight = 9 + 3 + 1 + 9 = 22), followed by “size of buttons” and “color of RC chassis” (9 + 3 = 12 each).

Figure 4.18 House of quality for television remote-control switch.

• Gabled roof: This contains the correlations among the technical attributes. For example, “dimensions of the RC chassis” has a strong positive correlation with “size of buttons” and “number of buttons”; “size of buttons” has a strong negative correlation with “number of buttons” (smaller buttons allow more buttons; larger buttons allow fewer).

• Target values: The numerical or qualitative descriptions (in the “basement” of the house) are design targets set for the technical attributes. One target of the design, for example, is to keep the dimensions of the RC within “6 × 18 × 2 cm.”

• Technical evaluation: The graph (in the “sub-basement”) compares the

company (x = “us”) against two of its competitors, A and B, on the technical attributes. For example, the company’s current product does relatively poorly on the attributes of RC dimensions and button color, but fares well on chassis color and return mechanism. These evaluations are based on test results and opinions of engineers.

• Competitive evaluation: The graph on the right rates the company and its competitors in terms of customer requirements. These ratings are based on customer surveys. For example, customers think the company does best in terms of the RC being “attractive,” but worst in terms of it being “easy to hold.”

The house of quality suggests areas in which designers might focus to gain a market niche. For example, the rating on the right in Figure 4.18 indicates that no company does particularly well in terms of “buttons easy to see” despite the fact that customers rank that requirement second in importance. A requirement that customers rank high, yet on which all companies rank low suggests a feature that could be exploited to improve a company’s competitive standing. The company making the RC, for example, might try to improve the visibility of the buttons by increasing their size and/or using bright colors.

The house provides a systematic way of organizing, analyzing, and comparing the hows with the whats, and prevents things from being overlooked. It justifies where to devote time and money, and where to refrain from adding resources. Still, the results of QFD are only as good as the data that go into the house. At minimum, the competitive evaluations require two perspectives: the customers’ viewpoints regarding how the product compares to the competition, and the engineers’ and technicians’ views regarding how well the product objectively meets technical requirements. The data come from many sources, including focus groups, tests of competitors’ products, and published reports.

An important aspect of requirements definition is to determine priorities—to distinguish between the critical few and trivial many aspects of the end-item system so as to ensure that the critical ones are done correctly. As an example, a computer printer might have as many as 30 different design features that affect

print quality, but the most important feature is the fusion process of melting toner on the page, which is a function of the right combination of temperature, pressure, and time. Focusing on temperature, pressure, and time narrows the design emphasis to the relatively few technical parameters of greatest importance to performance. These parameters become the ones for which designers seek the “optimum” values. Once the optimum values have been set, the analysis moves on to identify important factors in the manufacturing process necessary to achieve the design requirements. The house of quality is just the first of several steps in the QFD process that leads to a project plan.

QFD Process17

The QFD process employs a series of matrices in a multi-phased approach to project planning. The process, shown in Figure 4.19, utilizes four matrices that correspond to four project phases: project planning, product design, process planning, and process control planning. The phases (circled numbers) are as follows.

1. Create the “house of quality” matrix (A). This matrix converts customer needs or requirements into technical requirements.

2. Develop an initial version of the project plan based upon the house of quality requirements. The house matrix does not have to be completed; start with a rudimentary plan using information available from the house matrix, then expand the plan as new requirements emerge in the updated matrix.

3. Create the design matrix (B). This matrix converts technical requirements from the house matrix into product design features and requirements.

4. Create the process matrix (C). This matrix converts design features and requirements from the design matrix into process steps or production requirements.

5. Create the control matrix (D). This matrix converts process steps or production requirements from the process matrix into process tracking and control procedures.

6. Refine the project plan to incorporate aspects of the design, process, and

control matrices.

The matrices highlight the information needed to make decisions about product definition, design, production, and delivery, and they link work requirements in the four phases so that customer needs and technical requirements, as defined early in the process, are translated undistorted into design features and production requirements. Shown in Figure 4.19, the link happens by taking the requirements or steps from the top of one matrix and putting them on the left side of the matrix in the next phase. This linking of matrices ensures traceability (that word again)—that any project activity can be traced to the customer need or requirement that it fulfills, and, conversely, that every customer need and requirement can be traced to the necessary project activities. Put another way, QFD ensures that every activity serves a requirement, and every requirement is served by at least one activity. The result is a plan where every task throughout the project is integrated with the technical requirements listed in the original house matrix. The next chapter describes further aspects of an integrated project plan.

Figure 4.19 QFD multiphase, multi-matrix approach.

The additional time required by the QFD process to produce a project plan and an initial product design is offset by the reduced time to produce the final design because less redesign and fewer engineering changes are needed after the product goes into production.

Example A4.11: Chrysler Development of the LH Car Line18

Chrysler first applied QFD in the design and development of its LH-platform cars (Chrysler Concorde and Dodge Intrepid). Early in the product concept stage a program team was formed to establish overall design guidelines. The program team allocated responsibility for the different major automobile

systems to different design groups (as did Boeing in its teams), and each group set up a QFD team to determine system-level requirements. Once requirements were set, smaller groups were formed to focus on designing the components within the system.

The QFD methodology was part of a broader concurrent engineering effort that yielded impressive results: The total LH design cycle took 36 months versus the historical 54 to 62 months; prototype cars were ready 95 weeks before production launch versus the traditional 60 weeks; and the program required 740 people compared to the usual 1,600 people. The cars received numerous awards and magazine citations for design excellence.

Review Questions

1. When does the project manager become involved in the project? 2. What is the purpose of the kickoff meeting? When is the meeting held

and who runs it? 3. How is the project team created? 4. Describe briefly the contents of a project execution plan. 5. Describe phased project planning. 6. What are user requirements, system requirements, and system

specifications? Give examples. How are they related? 7. What are functional requirements? What are performance requirements?

Give examples. 8. What are “non-functional requirements”? Give examples. 9. Describe the process of developing user requirements and system

specifications. 10. What problems are associated with requirements definition? What are

ways to minimize these problems? 11. What is the purpose of specifying priorities and margins in defining

requirements? 12. Describe concurrent engineering. 13. Describe the stages of systems engineering in Figure 4.8. Think of some

projects and describe the stages of systems engineering in these projects. 14. Distinguish the following: functional requirements, performance

requirements, and verification requirements. Give an example of a functional requirement and its associated performance and verification requirements.

15. What is meant by the term “traceability”? 16. Think of a simple system like a mousetrap, tape dispenser, or can opener.

Draw a simple high-level functional flow block diagram for it. If possible, decompose each of the functions into sub-functions.

17. Briefly define the purpose of quality function deployment (QFD). 18. What is the source of customer needs or requirements that appear in the

house of quality?

19. Think about the following or use whatever consumer research material available to you to define customer needs or requirements for the following:

a. A “good” college course. b. Toaster (or other home appliance of your choosing). c. Cellular telephone. d. Coffee mug for your car.

For each, define a corresponding set of physical or technical characteristics. Using the format of Figure 4.20 construct a house of quality matrix and show the relationship between the technical characteristics and customer requirements. Use the matrix in each case to “design” or suggest what the ideal product or service would be like or look like.

20. What is the purpose of the project charter? What is included in the charter?

21. To what situations does Agile project management apply? How does Agile differ from “waterfall”?

Figure 4.20 QFD matrix for Question 19.

Questions About the Study Project

1. Did the project have a kickoff meeting? What happened there? 2. How did the project manager become involved in the project? Was she

selected as project manager before or after the proposal was completed? 3. How was the project team formed? 4. Were there user requirements? How were they defined? Were they

“well-defined” requirements? 5. Were there any system requirements? Were they clear and utilized by

the project team? 6. Were there any system specifications and performance requirements? If

not, how did the project team know what was required of the end-item? 7. Did the project have a project execution plan? If so, describe the

contents. If not, how did the team know what they were supposed to do (tasks, schedules, responsibilities, etc.)?

8. Describe the process of creating the project plan. 9. Did different stakeholders participate in defining the requirements and

creating the project plan? 10. Was QFD or a similar process used to define requirements and/or create

the project plan? 11. What is your overall impression about how well the definition phase

was conducted in the project, and of the quality of the system requirements and project plan?

Case 4.1 Star-Board Construction and Santaro Associates: Requirements SNAFU

Star-Board Construction (SBC) is the prime contractor for a large skyscraper project in downtown Manhattan. SBC is working directly from drawings

received from the architect, Santaro Associates (SA). Robert Santaro, owner and chief architect of SA, viewed this building as similar to others he had designed. However, one difference between this building and the others he overlooked was the building’s facing, which was to consist of large granite slabs—slabs much larger than anything with which either he or SBC had prior experience.

Halfway into the project, Kent Star, project manager for SBC, started to receive reports from his site superintendent about recurring problems with window installation. The windows are pre-manufactured units made according to SA’s specifications. The granite facing on the building was to be installed according to specifications that allow for dimensional variations in the window units. The architect provided the specification that the tolerance for each window space should be 1/2-inch (that is, the window space between granite slabs could vary as much as 1/4 inch larger or smaller than the specified value). This created a problem for the construction crew, which found the granite slabs too big to install with such precision. As a result, the spacing between slabs is often too small, making it difficult or impossible to install window units. Most of the 2,000 window units for the building have already been manufactured so it is too late to change their specifications, and most of the granite slabs have been hung on the building. The only recourse for fitting window units into tight spaces is to grind away the granite. It is going to be very expensive and will certainly delay completion of the building.

Question

What steps or actions should the architect and contractor have taken before committing to the specifications on the window units and spacing between granite slabs that would have prevented this problem?

Case 4.2 Revcon Products and Welbar, Inc.: Client–Contractor Communication

Revcon Products manufactures valves for controlling the water level in industrial tanks. It had concentrated on products for the construction industry (valves for newly installed tanks), but now wants to move into the much larger and more lucrative replacement market. Whereas annual demand for new valves is about 100,000, it is about 1 million for replacement valves. The company envisioned a new valve, the Millennium Valve, as a way to gain a share in the tank-valve replacement market. Revcon’s objective was to design and produce the Millennium Valve to be of superior quality and lower cost than the competition. Revcon decided to outsource the development and design of the new valve. It prepared an RFP with the following objectives and requirements:

Product objectives:

• Innovative design to distinguish the Millennium Valve from competitors’ valves.

• Price-competitive but offer greater value.

Market (user) requirements:

• Ease of installation • Non-clogging • Quiet operation • Ease in setting water level • Adjustable height.

Revcon sent the RFP to four design companies and selected Welbar, Inc., primarily based on it being the lowest bidder. Welbar’s proposal was written by its sales and marketing departments and revised by senior management, but with no input from industrial designers, engineers, or anyone else who would work on the project. Welbar had no prior experience with industrial water valves, but its sales team saw Millennium as an opportunity to earn profits and align with a major equipment manufacturer. The marketing department prepared time and cost estimates using standard tasks and work packages from proposals for old projects.

The Welbar design team for the Millennium Valve project was headed by Karl Fitch, a seasoned engineer, and included two industrial designers and two engineers. His first task was to research the valve market and talk to contractors, plumbers, and retailers. Karl reviewed Welbar’s proposal and concluded that it had omitted several critical steps, and that its cost was substantially underestimated.

Karl divided the project into small work packages and prepared a Gantt chart. During the project the design concept, work tasks, and schedule had to be changed many times. Welbar engineers were frustrated at Revcon’s constant harping that the valve be low-priced and have functional superiority, and that the project be speedy and low-cost. During the project, Welbar engineers learned that to design such a valve required more resources than had been budgeted for. Because of all the changes, Welbar exceeded the budget and had to request additional funds from Revcon four times. A major problem occurred when Welbar delivered a prototype to Revcon. Because the prototype description in the proposal was vague, Revcon expected the prototype to be an almost-finished product, whereas Welbar understood it to be a simple working model to demonstrate functionality. Welbar had to spend extra time and money to bring the

prototype up to Revcon’s expectation. To compensate, Welbar crammed project stages together. When the design stage fell behind because of the prototype, it went ahead and prepared production-ready models. The finished prototype later demonstrated that the production models could not be produced.

Eventually Welbar did design a truly innovative valve; however, the design would require substantial retooling of the factory and cost 50 percent more to produce than expected. In the end, Revcon spent twice as much time and money on development as expected. Because of that the product could not be priced low enough to be competitive.

Question

What happened to this project? What are the factors that contributed to Revcon’s failure to get the product it wanted? For each factor, discuss what might have been done differently.

Case 4.3 Lavasoft.Com: Interpreting Customer Requirements

Lavasoft Company is developing new website software for a corporate client. The project starts out when a few Lavasoft staffers meet with the client to create a list of user needs and requirements, which they then turn over to the Lavasoft design team.

The project manager, Lakshmi Sihgh, feels that the kind of system best suited to the user’s needs is more or less obvious, and to address the needs she creates some bullet points and flow-charts. She then presents these to the design team and asks if anyone has questions. Some people are concerned that the approach as stated by the bullets and charts is too vague, but Lakshmi assures them that the vagueness will subside as details of the system are defined.

To reduce outside interference, the team works in relative isolation of other development teams in the company. Daily the team is forced to interpret the bullet points and high-level charts and to make design decisions. Whenever there is disagreement about interpretation, Lakshmi makes the decision. The team creates a list of detailed system specifications and the project is considered on schedule. Upon working to the specifications, however, issues arise concerning the system’s compatibility

with the client’s existing site. Further, some of the specifications call for technical expertise that the team lacks. Also, in a review of the original user needs, the team discovers that some specifications are unrelated to the needs, and that for some needs there are no specifications.

The team drops some specifications and adds new ones. This requires eliminating some of the existing code, writing new code, and retesting the system, which puts the project behind schedule. Resistance grows to changing the specifications further since that would require even more recoding and put the project further behind. Lakshmi adds people to get the project back on schedule. Eventually the system is ready for installation, although it is 2 months late. Because of the additional people added to staff the project, Lavasoft does not make a profit. Because the specifications were incorrect, the system is not fully compatible with the client’s website and Lavasoft must continue to work on it and introduce “fixes.”

Questions

1. What went wrong with the project? 2. Where were mistakes made in the project initially? 3. How were problems allowed to persist and go uncorrected for so

long?

Case 4.4 Proposed Gold Mine in Canada: Phased Project Planning

July 12, 2006: Peter’s firm acquires the rights to an ore body in the Canadian Shield region. The firm is considering developing a new mine there, and Peter is responsible for proposing a project plan to the board in September. The mine will take a few years to reach full production, and there is much uncertainty as to the price of gold when that happens. Peter includes in his proposal a history of the gold price (Figure 4.21).

August 2, 2006: Peter meets with Bruce, a mining engineer with 20 years of experience in Australian gold mines, and Sam, a geologist who a few years back did exploratory work on gold deposits in the Canadian Shield region. They discuss known facts about the ore body, the likelihood of unforeseen geological phenomena that could jeopardize mine development, production figures that might be achieved, and production costs and technical problems that might arise in extracting gold from the ore. A quick calculation shows that 300,000 ounces of gold per year at $700 per ounce would be very lucrative, but a figure of 150,000 ounces at $400 per ounce, 3 years from now, would lead to large losses that could ruin the company.

Current information about the ore body is inadequate, however, and it will be necessary to drill exploration holes to learn more about the general geology of the area.

Figure 4.21 Gold price.

Peter summarizes: “To the best of our knowledge, we could produce anywhere between 150,000 and 300,000 ounces a year. The capital cost for developing the shaft will be US $150 millionto $260 million, and annual operational costs could be $60 million to $100 million. Exploration to provide information on the ore body would require drilling 200 exploration holes at a cost of between $1.2 million and $1.6 million. Rock samples from these holes will be analyzed in a laboratory to determine the gold content.”

Peter instructs Sam to review the data from his previous exploration work and to prepare a report of his recommendations concerning the future exploration. He is authorized to spend no more than $25,000 on this “paper exercise.” They agree that, should the exploration holes yield good results, a “demonstration shaft” will be sunk to haul out a sample of 30,000 tons of ore

to be processed to extract gold. Results from this demo would increase confidence about the amount of gold present, reduce uncertainty about processing the ore, and provide a good indication of potential yields. They estimate that the demo shaft and analysis would cost $18 million to $25 million, some of which, however, could be deducted from the cost of the full-fledged mine—should it go ahead. Only if these results are positive—and the gold price is relatively high and stable as of that stage—would full- fledged shaft development be authorized.

Questions

1. List the phases of the project and indicate the minimum and maximum cost of each phase as foreseen in August 2006.

2. “While estimates for the distant future are very ‘broad brush’, it is always possible to make relatively accurate estimates for the imminent phase of a project.” Explain.

3. Describe how each of the proposed project phases will help reduce the risk of the project.

4. Comment on the problem that, once money has been allocated to the process, people might become “hooked” into the project and be tempted to go ahead regardless of high risks.

5. How would you determine the value of accurate estimates for the number of ounces that could be mined and for costs?

6. Would you trust any internal rate of return or net present value estimates at this time?

Refer to Case 2.4, Santa Clara County Traffic Operations System and Signal Coordination Project

See Chapter 2

Question

The INCOSE group determined that a requirements traceability matrix, which was not used in the project, could have—were it used—aided in technology-related decision making during construction and reduced the number of change requests. Based on the limited information provided in the case, discuss the applicability of the traceability matrix to this project.

Endnotes

1. For advice for naming projects see Gause D. and Weinberg G. Exploring Requirements: Quality Before

Design. New York, NY: Dorset House; 1989, pp. 128–134.

2. APMP Syllabus, 3.1 edn. Buckinghamshire, UK: Association for Project Management; 2012.

3. Kay R. An APMP Primer. Lul.Com Self Publishing; 2010.

4. This section is adapted from Merrow E. Industrial Megaprojects. Hoboken, NJ: John Wiley; 2011.

5. See Frame J.D. Managing Projects in Organizations. San Francisco, CA: Jossey-Bass; 1988, pp. 146–151.

6. Hajek V. Management of Engineering Projects, 3rd edn. New York, NY: McGraw-Hill; 1984, pp. 35–37;

Whitten N. Managing Software Development Projects, 2nd edn. New York, NY: John Wiley & Sons; 1995,

pp. 250–255.

7. Connell J. and Shafer L. Structured Rapid Prototyping. Upper Saddle River, NJ: Yourdan Press/Prentice

Hall; 1989.

8. Portions adapted from Sabbagh K. Twenty-First Century Jet: The Making and Marketing of the Boeing

777. New York, NY: Scribner; 1996.

9. Sources: (1) Falconbridge R.I. and Ryan M. Managing Complex Technical Projects: A Systems

Engineering Approach. Boston, MA: Artech House; 2003, pp. 9–93; (2) Blanchard B. and Fabrycky W.

Systems Engineering and Analysis. Upper Saddle River, NJ: Prentice Hall; 1981, pp. 18–52; (3) Chestnut H.

Systems Engineering Methods. New York, NY: John Wiley & Sons; 1967, pp. 1–41; (4) Jenkins G. The

Systems Approach. In Beishon J. and Peters G. (eds), Systems Behavior, 2nd edn. London, UK: Harper &

Row; 1976, pp. 78–101.

10. Falconbridge and Ryan, Managing Complex Technical Projects, pp. 29–65.

11. Jenkins, The Systems Approach, p. 88.

12. The SpaceShipOne (SS1) examples in this book illustrate concepts. While there is much factual

information about the project available from published sources, information about the actual design and

development of the spaceship is confidential. SS1, the X-Prize, and the stakeholders described are all true-

life, however for lack of information portions of this and subsequent examples are hypothetical.

Information for this and other examples of SS1 are drawn from news articles and the SS1 website at

Scaled Composites, www.scaled.com/projects/tierone/index.htm.

13. Adapted from Falconbridge and Ryan, Managing Complex Technical Projects, pp. 67–96.

14. Chestnut, Systems Engineering Methods, p. 33.

15. Sources for this section: Bounds G., Yorks L., Adams M. and Ranney G. Beyond Total Quality

Management. New York, NY: McGraw-Hill; 1994, pp. 275–282; Hauser J. and Clausing D. The house of

quality. Harvard Business Review; May–June 1988: 63–73.

16. Portions of this section adopted from Nicholas J. Competitive Manufacturing Management. Burr Ridge,

IL: Irwin/McGraw-Hill; 1998, pp. 428–434.

17. See Bicknell B. and Bicknell K. The Road Map to Repeatable Success: Using QFD to Implement Change.

Boca Raton, FL: CRC Press; 1995, pp. 97–110.

18. Lockamy A. and Khurana A. Quality function deployment: a case study. Production and Inventory

Management Journal 36(2); 1995: 56–59.

Part III Systems and Procedures for Planning and Control

5 Basic Project Planning Techniques

6 Project Schedule Planning and Networks

7 Advanced Project Network Analysis and Scheduling

8 Cost Estimating and Budgeting

9 Project Quality Management

10 Project Risk Management

11 Project Execution, Monitoring, and Control

12 Project Evaluation, Communication, Implementation, and Closeout

13 Agile Project Management and Lean

Project management extends beyond defining project objectives and

requirements; it involves forming a project organization, identifying the necessary tasks and the resources to do them, and providing leadership to get the tasks done. Overall project objectives and system requirements need to be articulated into detailed plans, schedules, and budgets to accomplish the objectives and requirements. Methods are then needed to make sure the plans and schedules are carried out as intended.

Over the years an impressive collection of methods has been developed to help project managers define, plan, and direct project work. The next nine chapters describe these methods, which include techniques and procedures for specifying, scheduling, and budgeting project activities, assessing risks, monitoring and controlling work, and organizing and keeping records to achieve project quality, time, and cost requirements.

Procedures should be conducted within a framework to ensure that everything to be done is accounted for, properly organized, and executed. These frameworks and the structures, activities, and systems that comprise them—work breakdown structures, cost accounting systems, information systems, and many others—are described in this section of the book.

Chapter 5 Basic Project Planning Techniques

Big fleas hath smaller fleas upon their backs to bite’em. And these fleas have smaller fleas And so ad infinitum.

—Jonathan Swift

Every project is somewhat unique because it is aimed toward an end-item or result that is in some way unique. Because of its uniqueness, basic questions about the project must be addressed and answered before work can begin. Satisfactorily answering these questions so that the project will achieve its goals is the function of project planning.

Project management can be broadly divided into two parts: (1) in the conception and definition phases, preparing a plan that specifies the project requirements, work tasks, responsibilities, schedules, and budgets; (2) during the execution phase, executing the work in the plan and tracking progress versus the plan. This chapter gives an overview of the first part and covers the topics of scope and work definition, elemental scheduling, and procurement management.

5.1 Planning Steps

After a business need, contract request, or RFP has been received, top management releases funds to prepare an initial plan, schedule, and cost estimate for the project proposal. Approval of the project and signing the contract authorize the project to begin, starting with the definition of system requirements and preparation of a project execution plan. For internal projects, a project charter is sent to stakeholders to announce and describe the project.

The project manager, if not already assigned or involved, is now identified to oversee the planning process and produce a plan that elaborates on any earlier plans as prepared for the proposal, business case study, or charter.

Because each project is unique, there is never an a priori, established way about how the project should be done. Each project poses new questions regarding what, how, by whom, in what order, for how much, and by when, and the purpose of planning is to answer them. The planning process answers the questions in the following steps:

1. What is the desired end result? Define the project objectives, scope, and system requirements. These specify the project deliverables, end-items, and other sought results, as well as the time, cost, and performance targets.

2. How will the result be achieved? Define the work activities, tasks, or jobs to be done to achieve the objectives and requirements. These activities include everything necessary to create and deliver the end-item or deliverables, including planning, control, and administration activities.

3. Who will do it? Specify the project organization—the individuals or departments, subcontractors, and managers that will perform and manage the work, and specify their responsibilities.

4. When and in what order? Create a schedule showing the timing of work activities, deadlines, and

milestone dates. 5. How much?

Create a budget and resource plan to fund and support the project. 6. How well?

Specify a method for tracking and controlling project work, which is necessary to keep the project conforming to the schedule, budget, and user and system requirements.

This chapter and the next seven chapters discuss these steps in detail.

5.2 The Project Execution Plan

Project planning begins early in the project life cycle—in most cases with preparation of the proposal. While preparing the proposal a rudimentary project team is organized, and the team prepares a brief summary plan for inclusion in the proposal. They prepare this plan using the same, albeit more abbreviated, procedures as used to develop more elaborate and detailed project execution plans. The difference between a proposal summary plan and a project execution plan is that the former is aimed at the customer, while the latter is aimed at the project team.1 The planning effort in preparing the proposal is directed at estimating the project duration, cost, and needed resources. The proposal summary plan includes just enough information about the project and the price to enable the customer to make a decision.

In contrast, the project execution plan lays out the specifics of the project that will serve as a roadmap to guide the project team throughout the project execution. As mentioned in Chapter 4, usually the plan contains details only for the immediate upcoming phase of the project, about which the most is known.

See Chapter 4

Details for later project phases are filled in later as more information becomes available.

Contents of Execution Plans

Contents of execution plans vary depending on the size, complexity, and nature of the project. Figure 5.1 shows a template for a typical plan as outlined in Chapter 4.2 Depending on the customer and type of project contract, the plan might require additional items not outlined here;3 in small or low-cost projects it is possible to bypass some of the items, being careful not to overlook the crucial ones. It is good practice to carefully review every item in the template even if

only to verify that some are “N/A” (not applicable). An example project execution plan for the LOGON project is at the end of the book in Appendix C.

See Appendix C

You might notice similarities between the sections of the plan and the contents of the proposal described in Figure 3.6. Although the format is different, there are similarities. Sometimes the proposal, after revision to reflect updates, agreements, and contract specifications, becomes the project execution plan. More often, however, the proposal serves as an outline for the execution plan, and the execution plan is more expansive than the proposal. Because the primary audience of the execution plan is the project team and not the customer, the sections on work definition, schedule, and budget in the plan are much more detailed than in the proposal.

Figure 5.1 Template for Project Execution Plan.

As illustrated in the following example, sometimes development of the project execution plan is an evolutionary, cross-functional process.

Example 5.1: Developing a Project Plan for LOGON Project at Iron Butterfly Company

Iron Butterfly Company (IBC) is a medium-sized engineering and manufacturing firm specializing in warehousing and materials handling systems. It purchases most of the subsystems and components for its product

systems from vendors and then combines them to meet customer requirements. The company was awarded a large contract for a system to place, store, retrieve, and route shipping containers by the MPD Company. The system, called the Logistical Online System, LOGON, is to be developed and installed at MPD’s Chicago distribution center. Iron Butterfly is responsible for design, assembly, and installation of the system. Two of its contractors, CRC and CreativeRobotics, will provide the computer and robotics systems plus assistance with their installation and checkout. Frank Wesley is the IBC project manager put in charge of preparing the proposal.

Most of the project execution plan for LOGON originated in IBC’s project proposal. In preparing the proposal, engineers from IBC, CRC, and CreativeRobotics worked together to design a system that covered all of MPD’s requirements. The design included schematics, operational specifications, and a bill of materials. The design managers at CRC and CreativeRobotics estimated the labor expertise needed and the costs for parts and labor. Frank Wesley and his engineers prepared a work breakdown structure and estimates for IBC’s time and costs. He then combined these with CRC’s and CreativeRobotics’ estimates to arrive at an overall plan, schedule, and price for the proposal.

After winning the contract, Frank met with his project engineer and managers from the fabrication, software, and purchasing departments to review the design, project plan, costs, and schedules, and prepare a detailed execution plan. This plan contained similar information to the proposal, but was updated and expanded to include schedules for procured materials and parts, plans for labor distribution across work tasks, a task responsibility matrix, a detailed WBS and associated budget, and a master schedule.

In the LOGON project the execution plan evolved in stages: it was initially created during proposal preparation but was then expanded and modified after contract signing. In many projects, however, particularly for large, complex systems, the proposal serves only as a reference and the bulk of project planning happens after the contract is signed (i.e., in the definition phase). Often, project planning is itself a significant effort that requires substantial time and labor.

Learning from Past Projects

Oftentimes organizations approach each project as being too unique and ignore the lessons of history—the mistakes, solutions, and lessons learned of the past.4

No project is ever totally unique, so in developing the project plan it makes sense to refer to earlier, similar projects, their plans, procedures, successes, and failures. Ideally the project manager is provided with planning assistance in the form of lessons learned, best practices, suggested methodologies and templates, and even consultation based upon experience from past projects. In some cases this assistance comes from the project management office (PMO), described in Chapter 17. Lessons learned and best practices are compiled from the post-project summary or project postmortems of past projects; these are formal retrospective reports created at project termination that describe what went well, what went wrong, and any lessons derived from the project experience (described in Chapter 12). They provide useful guidance in planning future projects and help managers avoid reinventing the wheel and repeating mistakes.

See Chapter 17

See Chapter 12

5.3 Scope and Statement of Work

Project planning starts with defining the objectives, deliverables, and major tasks of the project; in combination these determine the overall size of the project and the range or extent of work it encompasses, the concept of project scope. Determining the project scope happens during project conception, first when the project is initiated and during preparation of the RFP and the proposal, and again during project definition. In each case, user needs and requirements are compared to time, cost, resource, and technology constraints to determine what the project should and can encompass. The process of setting the project scope is called scope definition.

Scope Definition

Scope definition involves specifying the breadth of the project and the full span of its outputs, end-results, or deliverables. The defined end-items to be produced or delivered by the project are termed “inclusions,” meaning they are included in the project. To ensure clarity, the items, conditions, or results not to be included in the project, i.e., “exclusions,” are also defined; for example, a project to construct a building might exclude the building’s landscaping and interior decorating. Distinguishing between inclusions (contractor responsibilities) and exclusions (possible customer responsibilities) prevents misunderstanding and false expectations.

Scope definition focuses primarily on determining outputs and deliverables, not on time and cost. Of course, time and cost delimit or dictate the potential deliverables; as such, in the scope definition they must be accounted for as “constraints.”

The outcome of scope definition is a scope statement that describes the main deliverables of the project, criteria for acceptance of the deliverables, assumptions and constraints (to provide rationale as to why the project has these deliverables and not others), functions to be fulfilled by the deliverables, brief background

about the problem being addressed or the opportunity being exploited, project objectives, user requirements or high-level specifications, and high-level project tasks or major areas of work. The input information for scope definition includes a set of user needs and requirements, a business case or other expression of needs, and constraints and assumptions; ideally the principal subsystems and components of the end-item will have been identified and also serve as inputs. Everything to be included in the project or contract, including support and side- items, as well as work or deliverables not to be included in the project (exclusions) are stated. The scope statement sometimes also lists outcomes or consequences to be avoided, such as negative publicity, interference with other systems, pollution, or damage to the natural environment. Rather than repeat the detailed requirements and specifications, the scope statement normally refers to or incorporates other documents that contain them.

For a unique project, the preliminary scope statement defined during project initiation might be somewhat vague; it should however be expanded and clarified during project definition as detailed plans for the first phase of the project are developed. For programs, separate scope statements are developed for the overall program and the individual projects that comprise the program.

Once the scope statement has been approved, it becomes a controlled document that can be modified only through a formal change process (Chapters 9 and 11).

See Chapter 9 and Chapter 11

Example 5.2: Scope Statement for the LOGON Project

The RFP for the LOGON project (see Appendix A at the back of this book) sent by Midwest Parcel Distribution Company (MPD) specifies “The Contractor shall be responsible for furnishing expertise, labor, materials, tools, supervision, and services for the complete design, development, installation, check-out, and related services for full operational capability of the LOGON system.” It also specifies the technical performance

requirements for the system, as well as project exclusions, i.e., “Removal of existing storage, placement, and retrieval equipment will be performed under separate contract.”

Upon receiving the RFP, Iron Butterfly Company (IBC), one of the proposing contractors, decided that the best way to meet MPD’s needs was with a system that employs robotic transporter units for placing and retrieving containers as instructed by a neural-network system. IBC analyzed MPD’s technical and budget requirements, and after a preliminary system design effort created the following scope statement for its LOGON proposal:

1. Project background: a short description of MPD’s Chicago distribution facility, and of the purpose and objectives of the LOGON system.

2. Description of the work to be done: design, fabrication, installation, test, and checkout of a transport, storage, and database system for the automatic placement, storage, and retrieval of standardized shipping containers.

3. Deliverables and main areas of work:

a. Overall system: create basic design. Reference requirements A and B.

b. Racks and storage-bucket system (termed “Hardware A”): develop detailed design. Storage-bucket system is Model IBS05 adapted to requirements C.1 through E.14.

c. Robotic transporter units and track system (termed “Hardware B”): develop detailed design. RBU is Model IBR04 modified to meet requirements F.1 through G.13.

d. Neural-network, database, and robotic-controller system: develop software specifications. Reference requirements H.1 through H.9 and K.3.

e. Hardware A and Hardware B: procure software, subassemblies, and components. Reference requirements K.1 through L.9.

f. Hardware A and Hardware B: fabricate at IBC site. Reference

requirement M. g. Overall system: install and check-out at MPD site. Reference

requirement Y.

Items (a) through (g) above represent deliverables for different stages of the project; associated with each are specific requirements (i.e., “reference requirements”) listed in separate documents appended to the scope statement. For example, the detailed designs noted in points 3(b) and 3(c) include reference to requirements C.1 through E.14 and F.1 through G.13. The requirements must be sufficiently comprehensive to enable subcontractors to produce the specified systems and components. Elsewhere the scope statement lists any project exclusions as noted in the RFP or identified by IBC.

The scope statement is the reference document for all project stakeholders; it becomes the basis for making decisions about resources needed for the project, and, later, determining whether or not required or requested changes to work tasks and deliverables fall within the agreed-upon project scope. A common tendency in projects is scope creep, which means the project keeps growing due to changes in the number and/or size of deliverables. Scope creep, if not controlled, can lead to runaway project budgets and schedules.

The scope statement appears in many places—project proposals, charters, and plans. Often the scope statement is incorporated into the statement of work.

Statement of Work

The statement of work is a description of the project; it includes a scope statement, but often goes far beyond that. It describes, for example: deliverable specifications and requirements; deliverable schedules; management procedures for communication, planning, and handling risks and changes; project budget; and key personnel responsible for administrative and work tasks. As such, the SOW is effectively a high-level version of the project execution plan.

The term SOW and its usage are commonly associated with contracted

projects, and the SOW appears in documents associated with the contracting or procurement process. The RFP, proposal, contract, and project execution plan all contain SOWs, each an updated, expanded, or more refined version of the SOW in the previous document. The project charter described in Chapter 4 might also contain a SOW.

5.4 Work Definition

Once project objectives and deliverables have been set in the scope statement, the next step is to translate them into specific, well-defined work activities; that is, to specify the tasks and jobs that the project team must do. Particularly for large, unique projects it is easy to overlook or duplicate activities. To insure that every necessary activity is identified and clearly defined, and that no activities are missed, a procedure called the “work breakdown structure” is used.

Work Breakdown Structure

Complex projects consist of numerous smaller sub-projects, interrelated tasks, and work elements. As the rhyme at the beginning of the chapter alludes, the main end result or deliverable of a project can be thought of as a system that consists of subsystems, which themselves consist of components, and so on. The method for subdividing the overall project into smaller elements is called the work breakdown structure or WBS, and its purpose is to divide the total project into “pieces of work” called work packages. Dividing the project into work packages helps in preparing schedules and budgets and assigning management and task responsibilities.

Creating a WBS begins with dividing the total project into major categories. These categories then are divided into subcategories that, in turn, are each subdivided. With this level-by-level breakdown, the scope and complexity of work elements at each level of the breakdown gets smaller. The objective is to reduce the project into many small work elements, each so clearly defined that the project can be easily planned, budgeted, scheduled, and monitored.

A typical WBS consists of the following four levels:

Level Element Description 1 Project 2 Sub-project

3 Work Package 4 Activity

Level 1 is the total project. Level 2 is the project broken down into several (usually four to ten) major elements or sub-projects. These sub-projects must conform to the deliverables or work areas specified in the scope statement, and all of them when combined must comprise the total project scope. Each sub- project is broken down into activities at Level 3. If a further breakdown is necessary, that occurs at Level 4. When the project is part of a program, a fifth level is added at the top and the levels are renumbered: Level 1 is the program, Level 2 the project, and so on.

When the process is completed, tasks at the bottom levels, whatever the levels might be, are called work packages. In the table above, the term “work package” appears at Level 3, but that is for illustration only. Later in the planning process, larger work packages might be subdivided into more-detailed activities or tasks,

The actual number of levels in the WBS varies by project, as do the actual names of the element descriptions at each level. (The level and names are often prescribed by the project methodology in use.) Figure 5.2 shows a typical WBS. Note the different levels and descriptions for each work element.

Figure 5.2 Elements of a WBS.

The WBS process happens somewhat naturally, starting with the list of user and system requirements. These requirements suggest the main system, end-item, or deliverables of the project and the major subsystems and components; they also suggest which of these results will be met externally (by suppliers/subcontractors) and which internally. These major subsystems and components are boxes on the WBS. Those boxes are then logically subdivided into smaller components of the system and the work tasks to create or acquire them. For technical and engineering projects, the WBS should include all of the configuration items (CIs) and major components of the system, as well as the work tasks to design, develop, build, and test them.5

The WBS becomes the basis for assigning project responsibility and contracting. For contracted work, responsibility for each sub-project or activity is assigned to a subcontractor through a contract agreement between the subcontractor and the project manager. For internal projects, responsibility for each sub-project or activity is assigned to an in-house department, through a formal agreement between the department manager and the project manager.

To avoid unnecessary complexity, the number of levels in the WBS should be limited. A five-level WBS might be appropriate for large projects, but for most small projects a three-level WBS is adequate. To help organize and track project activities, each work element is coded with a unique identifier or number. Usually the number at each level is based on the number at the next higher level. In Figure 5.2 Project “01” has six categories numbered 01–01 through 01–06; then, for example, category, 01–06 has seven tasks numbered 01–06–100 through 01– 06–700. The project manager establishes the numbering scheme.

Figure 5.3 illustrates ways to create the WBS for constructing a house. The top part of the figure shows the main project end-item (Level 1) and the major categories of work (Level 2) necessary to build it. For the most part, the items at Level 2 are physical pieces or components of the house. In other words, they identify the deliverables or products to be produced. This is called a product- oriented WBS. By subdividing a project in this way—according to physical products or deliverables, it is easy to attach performance, cost, and time requirements to each item and to assign responsibility for meeting these. That is,

creating a WBS in this way assists in preparing other parts of the plan, including the project budget and schedule. The bottom part of Figure 5.3 shows how the product-oriented WBS would be subdivided into four levels.

Figure 5.3 Example of a WBS for building a house.

Sometimes the WBS or portions of it are function-oriented or task-oriented (rather than product-oriented). For example, the middle part of Figure 5.3 shows the project subdivided according to work functions (e.g. carpentry and plumbing), not deliverables. Functions or tasks such as management and overhead, design, engineering, training, and inspection that apply to multiple deliverables or to integrating multiple deliverables should be identified as separate work packages. Whether the WBS uses product-, functional-, geographical-, task-based, or other

breakdown is a matter of preference, or is stipulated by the organization’s project methodology or WBS templates.

During the WBS process the questions “What else is needed?” and “What’s next?” are constantly being asked. Supplementary or missed elements are identified and added to the WBS at appropriate levels. For example, the WBS in Figure 5.3 does not include blueprints, budgets, and work schedules, even though the house cannot be built without them. These are deliverables associated with planning the project and designing the house, which could be included in the WBS by expanding Level 2 and inserting categories for “Design” and “Project Management,” and then at Level 3 by inserting “blueprints” under Design and “budget and work schedules” under Project Management, respectively. Somewhere in the WBS, considerations such as site location, permits and licenses, environmental impacts, etc., must also be included. As described later, the WBS must also reflect any procured (contracted, outsourced) goods, materials, or services.

Figure 5.4 WBS for spaceship project.

The concept of traceability, mentioned in Chapter 4, also applies to the WBS. A test for completeness of the WBS is to compare the list of project objectives and high–level requirements with work packages in the WBS. Every objective and requirement should be traceable to at least one work package. If an objective or requirement cannot be traced to a work package, then it will likely not be met. The reverse also applies: every work package should be traceable to at least one objective or high-level requirement. If it can’t be, the question is, why is it there?

See Chapter 4

Figure 5.4 exemplifies the WBS for a large engineering project where the main

deliverable and many of its subsystems and components must be developed, built, integrated, and tested from scratch. Notice, some portions of it are product- oriented (vehicle, facilities), while others are function-oriented (test/evaluation, project management/systems engineering).

The larger and less standardized the project, the easier it is to overlook something, and the more valuable the WBS process is to avoid that. In large projects the initial WBS is usually rather coarse and shows only major products or work functions and aspects of each to be allocated to specific contractors. Before work commences, however, details of each product or function must be more fully developed in the WBS.

Example 5.3: Process of Developing the WBS for the LOGON Project

The project manager and staff meet several times in brainstorming sessions to create the WBS for LOGON, first during proposal preparation to sort out key deliverables and define the project scope, later during project definition to update the WBS and breakout the work packages into finer detail. In the first meeting they “rough out” the major categories of work and deliverables in the Level 2 breakdown from the SOW (described in Example 5.2) and requirements, and identify the responsible functional areas.

After contract signing the project manager meets with managers from the functional areas that will be contributing to deliverables in the Level 2 breakdown. These managers then meet with their supervisors and technical staff to prepare a Level 3 breakdown. Where necessary, supervisors prepare a Level 4 breakdown.

Figure 5.5 shows a WBS that is part function-oriented (basic design, procurement, etc.) and part product-oriented (Hardware Part A, Hardware Part B, software, etc.). Where necessary, Level 2 items have been subdivided into Level 3 items, and Level 3 items into Level 4 items. The boxes at the bottom of the branches are “work packages,” denoted by letters in parentheses. Notice that the work packages are at different levels of the WBS; this is because each branch of the WBS is developed separately.

Figure 5.5 Work breakdown structure for the LOGON project. Work packages are lettered H through

Z.

Work Packages

How far down does the breakdown go? Simply, for as far as needed to completely define all work necessary for the project. The work in each “box” or element of the WBS should be “well defined”; if it is not then the box must be subdivided into smaller boxes. For a box to be “well defined” it should include the following:

1. Comprehensive SOW: work task or activity to be done. 2. Resource requirements: labor, equipment, facilities, and materials needed

for the task. 3. Time: estimated time to perform the task. 4. Costs: estimated resource, management, and related expenses for the task. 5. Responsibility: parties, individuals, or job titles responsible for doing

and/or approving the task. 6. Outcomes: requirements, specifications, and associated deliverables, end-

items, or results for the task. 7. Inputs: preconditions or predecessors necessary to begin the task. 8. Quality Assurance: entry, process, and exit conditions to which the task

must conform; as specified in the quality plan. 9. Risk. uncertainties about time, cost, and resources associated with the

task. 10. Other: additional information as necessary.

These properties are summarized in Figure 5.6. If any of them cannot be defined for a given box, then the task or product in the box is too broad and must be broken down further. When all or most of the properties can be defined for a box or element, the element is considered “well-defined” and, by definition, a work package.

Figure 5.6 Properties of a work package.

But the level of work breakdown must not continue so far as to result in an unnecessarily large number of work packages. During the project each work package becomes the focal point for planning and control and, as such, involves paperwork, schedules, budgets, and so on. Thus, the more work packages, the more time and cost needed to manage them.

WBS Templates

A company that routinely performs similar kinds of projects might utilize a standardized WBS “template” at Level 2 or Level 3. The template is based upon experience from having done many of those kinds of projects. In some companies the template is created and maintained by the project management office (PMO). Even with a template, however, it is good to remember that every project is somewhat unique and that such uniqueness might not become apparent until Level 3 or 4. Hence, the WBS for a project should never be a mere template or complete copy of the WBS from another project, no matter how similar the projects might seem. Nowhere is the saying “the devil is in the details” more appropriate than in projects, and the WBS is the tool for identifying the details wherein the devil might be hiding. To reduce oversights, it is good practice to have two or more teams each create a WBS, and then to combine them into one.

Ideally work packages represent jobs of about the same magnitude of effort and of relatively small cost and short duration compared to the total project. For example, DOD/NASA guidelines specify that work packages should be a maximum of 3 months duration and not exceed $100,000 cost. These are simply guidelines. Work package cost and duration can depend on many factors such as project size (smaller projects have smaller work packages).

Each work package represents a contract or agreement with a subcontractor, supplier, or internal functional unit. Although several functional or subcontracting units might share responsibility for a work package, ideally a work package has only one party responsible for it.

Example 5.4: Work Package Definition for LOGON Project

The LOGON project was divided into 19 work packages—the boxes lettered H through Z in Figure 5.5. Below is an example of the properties for a typical work package, Work Package X: Test of Hardware. Note how the defined properties correspond to those listed in Figure 5.6.

1. Statement of work: perform checkout, operational test, and corrections as necessary for sign-off approval of four Batman

transporter units, Model IBR04.

2. Resource requirements: labor (FT commitment, 3 weeks): test manager, two test engineers, three technicians.

Procured materials: track for mockup; all other materials on hand.

Facility: test room number 2 at Iron Butterfly for 3 weeks. 3. Time: 3 weeks scheduled; (time critical) start December 2; finish

December 23. 4. Costs (Control account RX0522):

Labor: Manager, 75hrs + 25% OH = $9,750 Engineers, 1125 hrs + 25% OH = $135,000 Technicians, 1125 hrs + 25% OH = $112,500

Material: $70,000 Subtotal $327,250

10% G&A $32,725 Total $359,975

5. Responsibility: oversee tests: B.J., manager of robotic assembly. Approve test results: O.B., manager of Fabrication Department. Notify of test status and results: J.M., project engineer; F.W.N., site operations.

6. Deliverables: four tested and approved Batman robotic transporters, Model IBR04. Refer to specifications.

7. Inputs: predecessor: assembly of Batman robotic transporter (work package V). Preconditions: test room setup for robotic transporter.

8. Quality Assurance: refer to entry, process, and exit conditions for work package X in the LOGON quality plan.

9. Risk: RBU will fail test requirements because of assembly/integration problems/errors. Likelihood: low. Contingency reserve: additional week included in the schedule.

10. Specifications: refer to test document 2307 and LOGON contract

spec sheets 28 and 41. 11. Work orders: none, pending. 12. Subcontracts/purchase orders: no subcontracts; P.O. 8967–8987 for

track tests.

A work package that produces a tangible deliverable or physical product as in the example should include specific start and finish dates for the work package.

WBS Process and the Integrated Project Plan

In an integrated project plan the elements of the plan—requirements, work tasks, schedules, budgets, risk, quality, communications, procurement, and so on—are interconnected. Once created, such a plan provides managers with a variety of ways to track the project, and to assess the impact of actions or problems with some elements of the plan on the other elements.

To better describe what an integrated plan is, we can compare it to what it is not, which would be: a list of work packages or tasks generated without much regard for user requirements; a budget that does not account for the resources required of the project tasks; and a schedule where the tasks do not match up with the tasks on the WBS or budget. To the outsider, it would appear that four people who never talked to each other had each come up with, respectively, a list of work tasks, a list of needed resources, a schedule, and a budget. Amazingly, that is sometimes the way plans are created, with the result that requirements, tasks, resources, schedules, budgets, and so on are seemingly independent and unrelated.

One noticeable feature about an integrated project plan is that the same list of work packages or tasks reappears throughout different elements of the plan. The list of work tasks developed in the WBS appears in schedules, budgets, and most other elements of the plan.

The process of creating the WBS and the resulting list of work packages thus integrates various elements of the project plan and project control in several ways:6

1. Managers, subcontractors, and others responsible for the project are identified during the WBS process and involved in defining the work. Their involvement helps ensure completeness of work definition and gains their commitment to that work.

2. Work packages in each phase are logically related to those in earlier and later phases; this ensures that predecessor requirements are met and no steps overlooked.

3. Work packages identified in the WBS become the basis for budgets and schedules. The project budget is the sum of budgets for the work packages plus overhead and indirect expenses. The project schedule is a composite of the schedules for the work packages.

4. The project organization is formed around the work packages, with resources and management responsibility assigned to each work package.

5. The project is managed by managing people working on the individual work packages.

6. The project is controlled by controlling the work packages. During project execution, work completed and costs accrued are compared to schedules and budgets for the work packages, suggesting which work packages are in need of corrective action.

The integrated project plan is a systems approach to management—recognition that a project is a system of interrelated work elements that must be defined, budgeted, scheduled, and controlled.

5.5 Project Organization and Responsibilities

Integrating WBS and Project Organization

During the WBS process each work package is associated with the area of the project organization that will have functional or budgetary responsibility for it. An example is the LOGON project and its contractor, Iron Butterfly Company, represented in Figure 5.7: on the left is the company organization structure; across the top is the project WBS. For contracted project work (performed by external parties), the organization structure on the left would show contractors and suppliers instead of departments. The box at the intersection of each department and work package signifies a control account or cost account. Each account represents assignment of responsibility for a particular task or work package or portion of one to a department. Just like a work package, it includes a schedule and budget, resource needs, deliverables,

Figure 5.7 Integration of WBS and project organization.

requirements, and the manager or supervisor responsible for it. Each control account integrates the WBS with the project organization and represents an agreement or contract with departments or subcontractors to fulfill work package requirements. Control accounts are described further in Chapter 8.

See Chapter 8

Responsibility Matrix

The individuals responsible for work packages are shown in a chart called the responsibility matrix or assignment matrix. Figure 5.8 shows the responsibility matrix for the LOGON project. The rows represent the work packages or major project tasks and activities identified in the WBS. The columns represent the

persons, groups, departments, or contractors responsible for them, and can also include other stake-holders who need to be notified about project matters. Letters within the matrix symbolize the kind of responsibility: primary (ultimate accountability for the work package); secondary (assistance or help); notification (must be notified about the work package’s status); and approval (has authority to approve or reject work package deliverables). (For this reason the matrix is also called a RACI chart—Responsible, Accountable, Consulted, and Informed.) Note that for each task one and only one person is assigned primary responsibility. The matrix can also be used to signify who will do the work and any other conceivable kind of responsibility.

From the matrix, everyone associated with the project can easily see who is responsible for what. This helps avoid people shirking responsibility and “passing the buck.”

To ensure everyone knows what is expected of them and what they can expect from others, the people, groups, or companies identified in the matrix should review and consent to the responsibilities. The assignments in the matrix can be roughed in during project conception and then detailed and firmed up during a team-building session held after project kickoff. Team building is described in Chapter 16.

See Chapter 16

5.6 Scheduling

The next logical step after requirements definition and work definition is to schedule the project work tasks. A project schedule shows the timing for work tasks and when specific events and project milestones should occur.

Events and Milestones

Project plans are similar to roadmaps: they show not only how to get to where you want to go, but also progress you have made along the way. Work packages are what you must do; combined with the schedule they are the road to project goals. Along that road are signposts called events and milestones that show how far you have progressed. Passing the last event signifies having reached the final destination: project completion.

Events and milestones should not be confused with work packages, activities, or other kinds of tasks. A task or work package is the actual work planned or being done and represents the process of doing something (such as driving a car to get somewhere); it consumes resources and time. In contrast, an event signifies a moment in time, the instant when something happens. In a project, events represent the start or finish of something (equivalent to beginning a trip or arriving at an intermediate destination). In most project schedules, each task is depicted as a line segment; the two ends of the line segment represent the events of starting and completing the task. For example, in Figure 5.9 the line segment labeled “Task A” represents the time to do Task A; events 1 and 2 represent the moments when Task A is started and finished, respectively. In project schedules, each event is attached to a specific calendar date (day, month, and year).

Figure 5.8 Sample responsibility matrix for LOGON project (with initials of persons responsible).

Figure 5.9 Relationship between tasks and events.

Two kinds of events in projects are interface and milestone.7 An interface event denotes the completion of one task and simultaneous start of one or more subsequent tasks. Event 4 in Figure 5.9 is an interface event. An interface event often represents a change in responsibility: one individual or group completes a task and another individual or group starts the next task. It signifies approval of the task just completed and readiness to begin subsequent tasks.

A milestone event represents a major project occurrence such as completion of a phase or several critical or difficult tasks, an important approval, or availability of crucial resources. Milestone events signify progress and, as such, they are important measures. Often, approvals for system requirements, preliminary design, detailed design, or completion of major tests are considered milestones; they signify the project is ready to proceed to the next phase of the systems development cycle. Failure to pass a milestone is usually a bad omen followed by changes to the budget and schedule.

Kinds of Schedules

Two common kinds of schedules are the project schedule and the task schedule. Project managers and upper management use the project schedule (project master or execution schedule) to plan and review the entire project. This schedule shows all the major project activities, but not much detail about each. It is first developed during project initiation and refined thereafter. Managers develop the project schedule in a top-down fashion, first scheduling the tasks identified from the WBS or in the scope statement. Later, they refine the schedule in a bottom-up fashion, taking into account the more detailed task schedules developed by functional managers. When the project is performed in phases, the schedule for each phase must be sufficiently detailed to enable management to authorize work on that phase to begin.

An activity schedule shows the specific activities or tasks necessary to complete a work package. It is created for people working on the activities and enables lower-level managers and supervisors to focus on those activities, and not be distracted by others with which they have no interaction. Activity schedules are prepared by functional managers or subcontractors, but incorporate interface

and milestone events as specified on the project master schedule. Project and activity schedules are prepared and displayed in many ways including with Gantt charts.

5.7 Planning and Scheduling Charts

Gantt Charts

The simplest and most common scheduling technique is the Gantt chart or bar chart, named after the management consultant Henry L. Gantt (1861–1919). During World War I Gantt worked with the US Army to find a way to visually portray the status of the munitions program. He realized that time was a common denominator to most elements of a program plan and that it would be easy to assess progress by viewing each element’s status with respect to time. His approach, which came to bear his name, became widely adopted in industry.

Figure 5.10 Gantt chart for LOGON project.

The chart consists of a horizontal scale divided into time units—days, weeks, or months—and a vertical scale showing work elements—tasks, activities, or work

packages. Figure 5.10 shows the Gantt chart for work packages in the LOGON project. Listed on the left-hand side are work packages and along the bottom are work weeks. The starting and completion times of the packages are indicated by the beginning and ending of each bar.

Preparation of the Gantt chart comes after a WBS analysis has identified the work packages or other tasks. During WBS analysis, the functional manager, contractor, or others responsible for a work package estimate its time and any prerequisites. The work elements are then listed in sequence of time, taking into account which elements must be completed before others can be started.

As an example consider how the first nine work elements in Figure 5.9 (work packages H through P) are scheduled. In every project there is a precedence relationship between the tasks (some tasks must be completed before others can begin), and this relationship must be determined before the tasks can be scheduled. These are the “predecessor” inputs mentioned earlier in the discussion of work package definition. Suppose that during the WBS analysis for LOGON it was determined that before work tasks I and J could be started, task H had to be completed; that before tasks K, L, and M could be started, task J had to be completed; and that before task N, O, and P could begin, task I had to be completed.

Before these can be started… This must be completed I, J H

N, O, P 1 K, L, M J

Figure 5.11 Setting up a Gantt chart.

This sequencing logic is used to create the Gantt chart. Thus, as shown in Figure 5.11 (and given the times shown for the work packages), only after task H has been completed—i.e., after Week 10—can tasks I and J be started; only after task J has been completed—after Week 16—can tasks K, L, and M be started; and, only after task I has been completed—after Week 18, can task N, O, and P be started. As each new work task is added to the chart, care is taken to locate it following completion of all of its predecessor work tasks. This example uses work packages as the tasks being scheduled, but in fact any unit of work can be scheduled.

After the project is underway the Gantt chart becomes a tool for assessing the status of individual work elements and the project as a whole. Figure 5.12 shows progress as of the “status date,” Week 20. The heavy portion of the bars indicates the amount of work that has been completed. The thinner part of the bars represents work unfinished or yet to be started. This method is somewhat effective for showing which of the work tasks are behind or ahead of schedule.

For example, as of Week 20 task N is on schedule, task O is ahead of schedule, and tasks K, L, M, P, and Q are behind schedule; L is the furthest behind because it should have been completed but has yet to be started.

When the Gantt chart is used like this to monitor progress, the information it reflects must be the most current possible and the chart should be updated daily or at least weekly. Tracking progress is important for identifying and rectifying problems. Posting progress like this is a good way to keep the team motivated.

Hierarchy of Schedules

For large projects with many work elements a hierarchy of schedules is used, as illustrated by the three levels in Figure 5.13. The top or project-level schedule shows sub-projects within a project, the intermediate-level schedule shows major activities within a sub-project, and the bottom or task-level shows work packages or smaller tasks within an activity. Milestones and target dates can be displayed at any level.

Each level schedule expands on the details of the schedule at the level above it. Intermediate- and bottom-level schedules are used for project and functional managers to plan labor and resource allocations. Bottom-level schedules are the most-detailed, showing the daily (and even hourly) schedules of the tasks within work packages. These are used by work package leaders and correspond to the task schedules mentioned earlier. Figure 5.14 is a multilevel schedule, showing both the higher-level project

Figure 5.12 Gantt chart for LOGON project showing work progress as of Week 20.

Figure 5.13 A hierarchy of schedules.

Figure 5.14 Multilevel schedule.

activities (denoted by “summary” bars) as well as the detailed tasks within each activity (denoted by “activity” bars).

As a rule, lower-level, more-detailed schedules are created closer to when they are needed and when such details are better-known—the phased planning approach in Figure 4.2.

Disadvantages of Gantt Charts

A disadvantage of the Gantt chart is that it does not necessarily show the effects of one work element falling behind schedule on other work elements. As described, some work elements depend upon others before they can begin; if those others are delayed then so will others be and, possibly, the entire project. Gantt charts alone provide no way of determining how delays in some work

elements impact other elements and the project.

5.8 Line of Balance (Linear Scheduling Method)

While projects are by definition unique, one-time endeavors, they sometimes contain repetitive work activities. Examples include erecting numerous towers for a new transmission line, constructing multiple largely-identical housing units, and erecting a multi-story building. A method for planning and controlling these repetitive activities is the line of balance—LOB (also called the Linear Scheduling Method because it is often used on “linear projects” such as highways and pipelines where the physical location of the work can be represented in terms of miles or kilometers).

Example 5.5: Cranes for Construction

A supplier of construction cranes must deliver a total of 12 cranes according to the schedule in Table 5.1. Prior to delivery, a set of activities must be completed for each crane. These are shown as activities A–F in the Gantt chart in Figure 5.15.

Table 5.1 Delivery Schedule for Cranes

Week Date Delivery Quantity Cumulative Delivery Quantity 1 February 7 1 1 2 February 14 2 3 3 February 21 4 7 4 February 28 5 12

Suppose we look only at deliveries on February 14; according to Table 5.1, a total of three cranes must be delivered by then. The question is, how far along should all the other activities be by then? For example, how many power units (activity B) should be bought by then (assuming one power unit per crane), how many components procured, and so on?

According to Figure 5.15, a power unit must be bought 2 weeks prior to

the delivery of a crane. Now, look at the right-hand column of Table 5.1; moving down 2 weeks from February 14 shows the number 12: this means that 12 power units must be bought by February 14. Since activities A and C both must be completed 3 weeks prior to crane delivery (Figure 5.15), we see, referring to Table 5.1, that 12 sets of “other components” must be procured (activity C) and 12 sets of structural components must be fabricated (activity A) by February 14. In the same manner, since operators must be trained (activity E) 1 week before delivery, moving down 1 week from February 14 in Table 5.1 shows that seven operators must be trained by February 14. Likewise, we see that seven cranes (activity D) must be assembled by February 14. Also, since tests with operators (activity F) involves zero lead time, three tests should be completed by then.

Figure 5.15 Gantt chart of tasks for delivery of one crane.

Figure 5.16 summarizes the LOB—the number of deliverables (completed units) per activity as of February 14. For the cost center, function, or supplier responsible for each activity, the LOB provides information necessary to estimate needed resources and plan work.

An alternative to Figure 5.16 is a diagram that shows the number of units to be completed by a specific activity per time period. For example, Figure 5.17 shows dates and quantities for fabricated structural components (activity A) and assembled cranes (activity D). The same kind of figure can be used to monitor actual units completed and track progress versus planned units.

Figure 5.16 Number of deliverables required by February 14 per type of activity.

Figure 5.17 Alternative presentation of a Line of Balance schedule.

5.9 Procurement Management8

Most projects involve procurement of goods, materials, and subcontracted work. Indeed, in some projects everything is “procured” and virtually nothing is done or produced “internally.” Whether project work should be done internally or procured from outsiders is the result of a make-or-buy analysis of the project end-item, subsystems, components, services, or other project deliverables, and of work packages and tasks identified in the WBS.

Certainly, the management of procured materials and outsourced work is every bit as important to the project as work done internally: procured items that exceed budget or schedule, or fail to meet requirements, cause cost and schedule overruns for the entire project.

The role of procurement management is to help the planning and control of the following:9

1. Equipment, materials, or components designed and built by vendors specifically for the project. These procured items might involve parts of, or entire, work packages (e.g. design work, environmental study, soil analysis). Major portions of a project might be wholly outsourced in a “turnkey” arrangement (i.e., subcontractors fully design, build, and install major equipment or components for the project end-item).

2. Off-the-shelf (OTS) equipment and components supplied by vendors. These represent products that are readily available and not produced specifically for the project.

3. Bulk materials (cement, metal tubing or framing, wire, stone, piping, etc.) 4. Consumables (nails, bolts, rivets, fuel) or tools for construction or

fabrication. 5. Equipment for construction or fabrication not already owned by the

contractor; includes cranes, supports, scaffolding, and equipment for shops, welding, and testing.

6. Administrative equipment not already owned by contractor; includes computers and project office facilities and equipment.

To simplify, we lump these items together here and refer to them as procured goods, work, or services (GWS). Goods refers to raw materials or produced items; work means contracted labor; and services includes consulting.

The term “procurement” represents activities related to bought, or subcontracted items, although other terms are also used, but with the following distinctions: whereas “acquisition” refers to the purchase of an entire complex system that is not well-defined (including its design, development, ramp-up, and production), and “buying” refers to the purchase of a standardized (off-the-shelf) item or part, “procurement” refers to the purchase of a component or subsystem (less than entire system)—including its design and/or production—according to specifications provided by the customer. Hence it would be appropriate to say the “acquisition of a nuclear power plant,” the “procurement of an automatic shut- down safety device,” and “buying a batch of standard one inch nails.”

Procurement management includes most everything associated with contracting and contract administration: soliciting bids and selecting contractors, establishing legally binding contracts between parties, managing the execution of the contracts, and closing out of contracts. The first few of these topics will be covered here and the others in Chapters 11 and 12.

See Chapter 11 and Chapter 12

Soliciting and Evaluating Bids

Once the decision is made to procure GWS, potential vendors are solicited to offer bids or proposals. A customer who has a long-term relationship with a supplier or contractor, especially one with unique skills or capabilities, will usually approach the contractor and negotiate a contract. This is called sole- sourcing because only one contractor is considered for the contract. When the scope of the project is somewhat simple and the requirements are well defined, the customer can advertise for bids online and other media using an RFP or RFQ (Request for Quotation, a simple price quote). For a large and somewhat undefined system that requires design work or other intellectual input, an RFP or IFB (information for bid) is sent to a short list of qualified suppliers. The RFP or

IFB might be preceded by an RFI, a request for information to determine if the contractor is qualified and should be sent an RFP. Sometimes the RFP is accompanied with a bidder’s or contractor’s conference to explain the background and scope of the project, documentation required from contractors, and contractual requirements. Acceptance of a bid will result in a formal contract with content and conditions as described in Chapter 3. When the procured item is hardware, the contract should specify at what point the supplier is no longer responsible for damages and the buyer becomes responsible.

The basic types of contracts are described in Chapter 3, although certain industries require specific contract formats.10 Procurement management is a specialized function that requires legal and contract administration skills; in some organizations a specialized procurement division handles it.11

See Chapter 3

Procurement Planning and Scheduling

The first step in procurement planning is to estimate the procured items, labor, or services needed for the project. Associated with every work package are procured GWS requirements, some that will be shared with other work packages. Items to be procured are identified during the WBS process, either from planning the work and resources needed for particular work packages, or from knowing that entire work packages must be outsourced. In the former case, managers responsible for each work package identify the GWS within the package that must be procured (e.g. the work package “build wing” will require procuring fiberglass, aluminum, and other materials from suppliers); in the latter case, managers will recognize that certain (sometimes significant) portions of the project (entire work packages) will have to be outsourced (e.g. the work package “develop rocket motor” will require development, fabrication, and testing—all to be provided by contractors).

Associated with each procured item is a schedule specifying when the item is needed and when procurement activities must begin. Everything to be procured in the project must be scheduled in advance to allow enough time to conduct the

RFP/proposal/supplier-selection process (described in Chapter 3), and for suppliers to deliver (or design, build, and then deliver) the items at the times needed. Figure 5.18 shows the considerations in scheduling a procured GWS item. The schedule is prepared by working backwards, starting with event 10, the date when the item must be available for the project. This schedule is then integrated with the project schedule to assure that the procurement process happens far enough in advance so that the item will be available when needed. This procedure is repeated to schedule all procured GWS items.

Figure 5.18 Procurement activities schedule.

Source: Adapted from Joy P. Total Project Management. Delhi: Macmillan India Limited; 1993, p. 383.

Of course, preparing such a schedule requires knowing the lead times for each of the procurement activities—the time needed for, e.g. suppliers and subcontractors to prepare proposals, the project manager to evaluate the proposals and issue contracts and work orders, and suppliers/subcontractors to

fulfill the work orders (which could involve their designing, building, and testing of equipment or components). It’s not uncommon, especially in international projects, for these times to be grossly underestimated and, subsequently, the project delayed.

The schedule in Figure 5.18 starts at the point where GWS requirements have been identified. To get to that point, however, the system requirements and specifications must first have been defined—another reason for careful attention to system definition in the project life cycle.

Procured GWS require the same treatment in project planning as internal aspects of the project; hence matters such as the responsibility, budget, quality, and risk for procured items must also be addressed in the plan—topics to be discussed in later chapters.

Logistics Plan

Logistics relates to the transport and storage of materials. In projects that are materials-intensive, the loading, unloading, transportation, inspection, clearances and approvals, and storage of materials can be major issues. For example, consider a large construction project and the importance of timing the arrival of materials (steel, pipes, concrete slabs) to coincide with when those materials will be needed for the building. Obviously the materials cannot arrive late because that will delay the project. But equally serious is when the materials arrive early. Where do you put them? Where do you put the truck that brings them? In congested urban areas there simply is no space; when there is, materials delivered early are subject to damage, deterioration, and theft. Whenever GWS items cannot be scheduled to arrive just in time, provision must made to store and protect them, which on large projects can be very costly.

5.10 Summary

The purpose of project planning is to determine the way in which project goals will be achieved—what must be done, by whom, when, and for how much.

The project scope statement and WBS are ways that managers and planners answer the question “What must be done?” The scope statement outlines the main areas of work to be done and the deliverables or end-items. It appears commonly in two places, the SOW or the project charter. The SOW is a summary description of the project used for contracted work; it appears in the RFP, proposal, contract, and project execution plan. The charter is a document used for internal projects to describe, announce, and formally authorize the project.

The WBS process subdivides the project into work packages or other work elements, each small enough to be well understood, planned, and controlled. Most all elements and functions of project management—scheduling, budgeting, resource allocation, tracking, and control—are subsequently carried out with reference to the WBS and work packages.

The responsibility matrix integrates the project organization with the WBS; it prescribes which units and individuals, both internal and subcontractors, have project responsibility and the kind of responsibility for each. It is valuable for achieving consensus, ensuring accountability, and reducing conflict among project participants.

Project schedules show the timing of work and are the basis for resource allocation and performance tracking. Depending on the amount of detail required, different types of schedules are used: project-level schedules show only high-level tasks and work packages; task-level schedules show the tasks needed to complete individual work packages. The most common form of schedule is the Gantt chart. As a visual planning device it is effective for showing when work should be done and whether work elements are behind or ahead of schedule.

Project plans must account for all resources and work necessary for the project, including those procured (provided by suppliers and contractors). Procured items and the procurement process must be included in all elements of the project plan —the WBS, schedule, responsibility matrix, budget, and so on.

The concepts and techniques in this chapter are foundation tools for planning and scheduling. The next few chapters look at additional techniques for planning and scheduling. Later chapters address the role of the WBS, work packages, and schedules in cost estimating, budgeting, and project control.

Review Questions

1. What questions need to be answered every time when a new project is planned? What are the steps in the planning process that answer these questions?

2. What is the purpose of a project execution plan? At what stage of the project should this plan be prepared?

3. Can a project be undertaken without an execution plan? What are the possible consequences?

4. Which aspects of the execution plan might be eliminated for projects with small budgets? Which might be eliminated for short duration projects (a few weeks or months) with relatively few tasks?

5. A section for addressing “Risk and Uncertainty” is often left out of the project execution plan. What are the potential pitfalls of doing this?

6. What is the purpose of the project scope statement? What information is used to create the scope statement? How is the scope reflected on the WBS?

7. What is the statement of work? In what documents does the SOW appear?

8. What are differences and similarities between the SOW and the project charter?

9. Think of a somewhat complicated endeavor you are familiar with and develop a WBS for it. (Examples: wedding, high school reunion, questionnaire survey, movie or stage play, etc.). Now repeat for a complicated job you are not familiar with. At what point do you need assistance from “functional managers” or specialists to continue the breakdown?

10. How do you know in a WBS when you have reached a level where no further breakdown is necessary?

11. Could the WBS in Figure 5.5 have started with different Level-2 elements and still result in the same work packages? In general, can different WBS approaches give similar results?

12. In what ways is the WBS important to project managers? 13. What is the role of functional managers in developing a WBS? 14. What is the impact of altering the WBS after the project has started? 15. What should a “well-defined” work package include? 16. What is the relationship between the WBS and organization structure?

In this relationship, what is the meaning of a “control account”? 17. Figure 5.8 shows some possible types of responsibilities that could be

indicated on a responsibility matrix. What other kinds of responsibilities or duties could be indicated?

18. Construct a responsibility matrix using the WBS you developed in question 9. In doing this, consider the project organization and the managerial/technical staff to be assigned and their duties.

19. What function does the responsibility matrix serve in project control? 20. Could a responsibility matrix seem threatening to managers and others?

Why? 21. Distinguish an event from an activity. What problems can arise if people

on a project confuse these terms? 22. Distinguish an interface event from a milestone event. Give some

examples of each. When is an interface event also a milestone event? 23. How are project-level and task-level schedules prepared? What is the

relationship between them? Who prepares them? 24. Construct a Gantt chart similar to the one in Figure 5.10 using the

following data:

Task Start Time (wks) Duration (wks.) A 0 5 B 6 3 C 7 4 D 7 9 E 8 2 F 9 8 G 12 7

When will task G be completed?

25. How must the Gantt chart you drew in problem 24 be changed if you were told that C and D could not begin until B was completed, and that G could not begin until C was completed? What happens to the project completion time?

26. Is the Gantt chart adequate for planning and controlling small projects? 27. In a hierarchy of schedules, how does changing a schedule at one level

affect schedules at other levels? 28. How do you decide when more than one level of schedule is necessary? 29. If a hierarchy of schedules is used in project planning, explain whether

there should be a corresponding hierarchy of plans as well. 30. What aspects of the project fall under “procurement management”? Why

is managing procured items just as important to project success as managing internal items? What are the issues in scheduling procured items?

31. Consider this statement: The management of procured items can pose greater difficulties than managing internal items. Do you agree or disagree, and why?

Questions About the Study Project

1. Describe the project execution plan for your project (the plan developed at the start of the project). What is the content? Show a typical execution plan.

2. Who prepared the plan? 3. At what point in the project was the plan prepared? 4. What is the relationship between the execution plan and the project

proposal? Was the plan derived from the proposal? 5. Is there a project scope statement? Who prepared it? Do major areas of

work and deliverables of the project correspond to the scope statement? 6. Is there an SOW or project charter? Describe its purpose and contents. 7. How, when, and by whom was the work breakdown structure (WBS)

prepared? Describe the process used in preparing the WBS. 8. Where in the WBS is project management included? 9. Was the work package concept used? If so, describe what a work

package includes. How are work packages defined? 10. How were ongoing activities such as management, supervision,

inspection, and maintenance handled in the WBS? Was there a work package for each?

11. How were responsibilities in the WBS assigned to the project organization (i.e., how did the functional areas become involved in the project)?

12. How were individuals assigned to the project? Describe the process. 13. Was a responsibility matrix used? Show an example. 14. How were activities in the WBS transferred to a schedule? How were

times estimated? Who prepared the schedules? 15. Show examples of project-level and task-level schedules. Who prepared

each? How were they checked and integrated? 16. What are the procured GWS in the project? Were these items managed

differently than in-house aspects of the project? How were they first identified and then integrated into the project plan? Did procured items

pose any difficulties to the project?

Case 5.1 Barrage Construction Company: Sean’s WBS

Sean Shawn was recently appointed project planner at Barrage Construction, a company that specializes in custom-made garages. He had worked for 2 years in the HR department while completing his MBA and now has a desk in the newly created project office. Barrage is considering branching out to building standard two-car and three-car garages as well as its usual customized garages, and asked Sean to determine the feasibility of moving into this market. Skimming a book on project management he discovered the WBS concept and decided it would be helpful for developing cost estimates for the standard garages. He had never worked on a garage construction project but felt he knew the process well enough from having talked to company employees. He sat down and drew the WBS in Figure 5.19. To estimate costs for each work category in the WBS he reviewed company cost records from three recent two-car garage projects he thought similar to the standard garages, computed the average, and then apportioned the costs among the categories in the WBS. The company had no actual cost records for a three-car garage, so as an estimate he increased the estimate for the two-car garage by 50 percent. When he summed the costs for all the categories he arrived at a total of $43,000 for a two-car garage and $64,500 for a three-car garage. Compared to competitors, he discovered, these costs were 10 percent higher than their prices. However, because his estimates had been based on custom garages, he believed they might be at least 20 percent higher than for standard garages. He thus reduced his estimate by 20 percent and concluded that Barrage would be able to price its garages competitively and still make a 10 percent profit.

Figure 5.19 Sean’s garage project WBS.

Question

What is your opinion of Sean’s approach to creating a WBS and estimating project costs? Please elaborate.

Case 5.2 Startrek Enterprises, Inc.: Deva’s Project Plan

Deva Patel, project manager at Startrek Enterprises, Inc., is planning and coordinating the company’s move to a new building currently under construction. Deva wants the move to commence as soon as the building is ready for the estimated June 1 occupancy—still 2 months away. The entire move, which will affect four departments and 600 people, is to be completed within 1 week. Because timing is critical, Deva starts her planning by preparing a Gantt chart. At the project level she draws a bar 1 week (7 days) long, then subdivides it into three major categories: (1) pack office supplies, equipment, and furniture (3 days allotted); (2) move everything (2 days allotted); and (3) unpack and arrange it at new location (2 days). She then estimates the total number of boxes, equipment, and furniture that will have to be moved in 2 days, gives the estimate to a moving contractor, and receives a price quote. To assist in packing and unpacking boxes and equipment, Deva intends to hire temporary workers. She estimates the number of workers needed, gives it to a temp agency, and receives a price quote.

Deva shows the completed plan to her manager and asks him to review it. The plan consists of the Gantt chart and a budget that is largely based on the price quotes from the moving company and the temp agency.

Questions

1. What do you think about Deva’s approach to scheduling work and estimating the costs?

2. If you were Deva’s manager, would you consider her plan comprehensive?

3. How would you prepare a plan for the move and what would your plan include?

Case 5.3 Walter’s Project Plan

Walter has just been assigned to manage a project—his first experience as a project manager. The project involves developing an end-item that must meet a long list of requirements, but after reviewing the project SOW and requirements list, the first thing Walter wonders is who is going to be on his project team. He asks his manager, who gives him the names of three people in the department who are available to work on the project.

Next, Walter starts thinking about what each of the three people on the team will do. He feels that for a project to be successful, team members should each be assigned to tasks they are the most qualified or experienced to do. Since he has worked with the people before, he knows a little about their individual expertise. He sits down to prepare a list of tasks for each person; as he considers each person, he thinks about things that need to be done in the project and selects those things he thinks are best suited to the person. When he is finished creating the lists, he sees that person A has 11 tasks, while persons B and C have 4 tasks and 5 tasks, respectively. To

balance out the workload, he takes four of the tasks from person A and splits them between the other two. He is pleased because, he feels, with seven, six, and seven tasks, respectively, the team members will each have roughly the same amount of work.

On each list he then arranges the tasks in the approximate sequence they must be done.

The next day Walter meets with the team and gives them the lists of tasks. He asks that they estimate the time they will need to do each of the tasks and that they meet as a group to figure out how their tasks are interrelated and create a Gantt chart. He feels that by requiring team members to estimate task times and create their own schedule, the estimates and schedule will be realistic and accurately reflect the timing of the project.

Walter stops by his manager’s office and eagerly reports that his “project plan” is soon forthcoming, to consist of a Gantt chart and lists of responsibilities for project team members.

Questions

1. Discuss Walter’s approach to (a) defining work (creating task lists), (b) creating the schedule, and (c) assigning responsibility.

2. What do you think of Walter’s approach to “balancing the workload” among the team members?

3. Do you think the Gantt chart will realistically reflect work that must be done in the project? Do you think the project will be able to satisfy the SOW and requirements?

4. How else might Walter have gone about defining work tasks, creating the schedule, and assigning responsibility?

Case 5.4 Planning the Boca Implementation at Kulczyński Products

Tomasz Grabowski is newly hired as a project manager of IT at Kulczyński Products. His first project is to install the brand-new Boca Business System. This is his first management position, but with 4 years of IT experience he feels confident he can do a good job. He will be leading a team of up to 12 IT professionals, 9 from Kulczyński and 3 from Boca Systems, the software contractor. So far only 3 of the Kulczyński team have been assigned to the project.

To plan for the project he prepares a detailed list of the tasks he believes need to be performed, shown below. He is proud of the list and thinks it’s quite comprehensive.

Task List

1. Identify resources to be monitored. 2. Define users and workflow. 3. Identify event sources by resource type. 4. Define the relationship between resources and business systems. 5. Identify members of the implementation team. 6. Order the server hardware for production as well as test/quality

assurance. 7. Order console machines. 8. Order prerequisite software. 9. Install test and QA servers and prerequisite software.

10. Install console machines and prerequisite software. 11. Install Boca Business Systems Manager on console machines. 12. Install production servers and prerequisite software. 13. Install console machines and prerequisite software. 14. Configure Boca Console server and verify connectivity. 15. For each resource type, do the following tasks:

a. Extend the data model. b. Configure the instance placement. c. Configure the Boca Enterprise Console rule to send events. d. Associate tasks and URLs with object types. e. Configure filtering, if appropriate. f. Verify the event flow.

16. For each business system interface, do the following tasks:

a. Test the Automated Business Systems file and XML definitions to verify resource inclusion and placement.

b. Create databases on the history server. c. Set up and test jobs on the database server to produce the

database backup. d. Set up and test jobs to copy backup databases to the

history server.

e. Set up and test jobs to replicate events to the history server.

f. Install your request processor on the Boca Business Systems Manager database server for use by the problem and change request processing function.

g. Optional: Update the System Configuration table to reflect request processor names along with processing options for the request processors.

h. Optional: Update the TLAP table to specify resource options for problem ticket creation.

17. Consider training a key group and have them train their peers.

a. Evaluate the addition and deletion of user IDs. b. Establish a relationship between Boca Business Systems

Manager and change management. Monitor system performance and adjust hardware as required.

c. Boca Business Systems Manager SQL server jobs.

The project is to begin in March and finish by November 31. Tomasz is not accustomed to working according to schedules but the department manager says he ought to prepare one to make sure the project can be done on time. For the schedule Tomasz decides to create a “timeline” similar to one he saw in an earlier project. He takes that timeline and modifies to show 11 “work categories” that he believes represent the Boca project. He then estimates how long each work category will take to the nearest half-month. Arranging the categories and times on the timeline, Tomasz finds that the project will finish in January, which is too late. He reviews the estimates and reduces several of them enough to shorten the timeline by 2 months. Figure 5.20 is the finished timeline.

Figure 5.20 Boca Implementation Project timeline.

Tomasz intends to assign responsibility as follows:

• The Boca Team is responsible for everything on the task list with the word “Boca.”

• The Kulczyn’ski Team is responsible for everything else on the list.

Just before the project begins Tomasz gives the Boca Team and Kulczyn’ski Team each a copy of the task list and the timeline. He explains to them, “Here’s the list of what we need to do. If you are able to do everything within the timeline, we should be able to meet the project deadline.” Comment on Tomasz’s “plan.”

Endnotes

1. Some organizations use the term “project charter” to refer to an “execution plan.” Our preference is for

the more common usage, i.e., the charter is a somewhat brief document to announce and authorize the

decision to undertake a project while the execution plan is a comprehensive document that will guide the

project team though project execution.

2. Contents of execution plans are listed in Cleland D.I. and King W.R. Systems Analysis and Project

Management, 3rd edn. New York, NY: McGraw-Hill; 1983, pp. 461–469; Allen J. and Lientz B.P. Systems

in Action. Santa Monica, CA: Goodyear; 1978, p. 95; Kerzner H. Project Management, 10th edn. New

York, NY: Wiley; 2009, pp. 459–463.

3. See, for example, Cleland and King, Systems Analysis and Project Management, pp. 461–469.

4. Seymour Sarason in The Creation of Settings and The Future Societies (San Francisco: Jossey-Bass; 1972)

argues the importance of knowing the beginnings, origins, and history of any new “setting” before

initiating work; especially important is to anticipate and prepare for possible struggles, obstacles, and

conflicts to be encountered.

5. In technical projects, the subsystems and components—the “configuration items” (CIs)—are identified

during preliminary design studies in systems engineering, described in Chapter 2.

6. Cleland and King, Systems Analysis and Project Management, p. 258.

7. Archibald R. Managing High-Technology Programs and Projects. New York, NY: John Wiley & Sons;

1976, pp. 65, 156.

8. Portions of this section adopted from Joy P.K. Total Project Management. Delhi: Macmillan India

Limited; 1998, pp. 378–400.

9. Ibid., pp. 378–380.

10. Examples: NEC or New Engineering Contract, The Institution of Civil Engineers, The Engineering and

Construction Contract. London: Thomas Telford; 1995; and FIDIC, International Federation of

Consulting Engineers, Lausanne, Switzerland, http://www1.fidic.org.

11. See Whittaker R. Project Management in the Process Industries. New York, NY: John Wiley & Sons; 1995.

Chapter 6 Project Schedule Planning and Networks

You can’t always get what you want.

—Rolling Stones

Project scheduling is more than just displaying tasks on a Gantt chart. It is an integral part of project planning, a sometimes trial-and-error process of adjusting work tasks to satisfy resource constraints while trying to meet project deadlines. A Gantt chart is good for communicating the project schedule, however as a planning tool it is limited because it does not explicitly show the impact of delaying activities or shifting resources on the overall project. The network methods described in this chapter do not have this limitation; they clearly show what happens to the project when resources are altered or activities delayed. This chapter and the next discuss the most widely used network-based approaches to project scheduling and planning.

6.1 Network Diagrams

A network diagram shows project activities or tasks and their logical relationships—i.e., the precedence relationships or dependencies among the tasks. Figure 6.1 is a network diagram for “getting up in the morning and getting dressed” (for a male). The boxes represent activities or tasks, and the arrows between them show the order in which they should occur, e.g. put on shirt before tie, put on pants and socks before shoes, etc. (The diagram in Figure 6.1 is of course for illustration purposes only; any real-life attempt to plan work in such detail would be micro management and a real time-waster!) Ordinarily the boxes in the network would be the activities or work packages as defined in the work breakdown structure (WBS). Depending on the desired detail, however, they can represent any level of work, including projects in a program, sub-projects belonging to a project, or work packages in a project, subproject, or specific facility.

See Chapter 5

Networks also show events. As described in Chapter 5, an event represents an instant in time, an “announcement” that something has happened or will happen. Typically it signifies the start of an activity or the end of an activity. An activity with a very short duration may also be regarded as an event. An important event such as completion of a project phase is a milestone.

See Appendix A to this chapter

Two methods for constructing network diagrams are activity-on-node (AON)— also called the precedence diagramming method (PDM), and activity-on-arrow (AOA). Our discussion will center on the more-commonly used AON method. The AOA method is addressed in Appendix A to this chapter.

Figure 6.1 Network diagram for getting up and getting dressed.

Activity on Node (AON) (or PDM) Diagrams

Figure 6.2 shows an activity as represented in the AON method. Each node (box) in the network is an activity; shown inside the node is information about the activity such as its duration, start time, and finish time.

To construct an AON network, start by drawing the first activity in the project (e.g. “wake up”). From this activity draw arrows to the activities that happen next. As shown in Figure 6.1, activities are added one after another, in sequence or parallel.

But before you can actually create a network, you must first know the dependency relationships among the activities. For each activity you need to know, for example:

• What activities are its predecessors? • What activities are its successors? • What activities can be done at the same time as it?

In a network, every activity except the first one has predecessors, or activities that must be completed ahead of it; in Figure 6.1, for example, “put on shirt” is a predecessor for “put on tie.” Similarly, every activity except the last one has successors, which are activities that cannot begin until the current activity is

completed; for example, “put on tie” is a successor of “put on shirt.”

Figure 6.2 AON presentation for an activity and its start and finish events.

It is important to distinguish mandatory and discretionary dependency relationships:

• Mandatory: the sequence of two activities (which activity should precede the other) cannot be reversed. The relationship between “put on socks” and “put on shoes” in Figure 6.1 is an example.

• Discretionary: the sequence is a matter of choice. For example, “dry, brush hair” and “put on jacket” can be done in either order. Sometimes a discretionary dependency can be eliminated and activities overlapped to speed up the project. This is called fast-tracking.

In another kind of dependency, called external dependency, an activity depends on some event or activity that is not in the network. For instance, in Figure 6.1 the activity “take umbrella” might be included at the end of the network; it would depend on an external factor, the “forecast for rain.”

Sometimes only the immediate predecessors are used to construct the network. An immediate predecessor is an activity that immediately precedes another activity. For example, “wake up” and “get undressed” are both predecessors for “take shower” but only “get undressed” is an immediate predecessor. (The logic is, to “get undressed” you have to first “wake up.”) Given information on immediate predecessors, it is easy to construct a network. For example, the network in Figure 6.1 can be constructed from the information in Table 6.1. Start with the first activity in the project (the one in Table 6.1 with no immediate predecessor) —“get undressed,” then connect it to the activity that has “get undressed” as its

immediate predecessor, which is “take shower.” Next come “put on underwear” and “dry, brush hair” since “take shower” is their immediate predecessor. Continuing in this fashion, the result is the diagram in Figure 6.1.

Once the network is constructed it is easy to see which activities are sequential and which are parallel. Activities that have a predecessor-successor relationship (one follows the other) are called sequential activities; “take shower,” “put on underwear,” and “put on shirt” are examples. Two or more independent activities that can be performed at the same time are called parallel activities. “Put on shirt,” “put on pants,” “dry, brush hair,” and “put on socks” are parallel activities because they can be done all at the same time or in any order. Once the network has been completed, check the relationships among activities for completeness and logical consistency.

Another example is given in Table 6.2. The network diagram for this project, shown in Figure 6.3, begins at Activity A (no immediate predecessors). Since Activities B and C both have A as their common immediate predecessor, both are connected directly to A. Then, because D has two immediate predecessors, B and C, it is connected to both of them; similarly, so is Activity E. Each node is labeled to identify the activity and its duration.

Table 6.1 Activities and Immediate Predecessors

Activity Immediate Predecessors Duration (Seconds) Get undressed – 60 Take shower Get undressed 600

Put on underwear Take shower 40 Dry, brush hair Take shower 350 Put on shirt Put on underwear 150 Put on pants Put on underwear 60 Put on socks Put on underwear 45 Put on tie Put on shirt 150

Put on shoes { Put on pants 100 { Put on socks

Put on jacket { Put on tie 10

{ Put on shoes { Dry, brush hair

In general, good practice dictates that a network should always have only one “start” and one “end” node, each a single place on the network to represent the start and end of the project. Whenever a project has multiple nodes at the start or end of the network, then a single node should be inserted before or after them, respectively. In Figure 6.3, for example, a single end node (with implied zero duration) has been inserted after Activities D and E. Without this node the mistaken understanding might be that the project ends upon completion of either Activity D or Activity E. The “end” node means that the project ends when both D and E are completed.

Table 6.2 Activities and Immediate Predecessors

Activity Immediate Predecessor A – B A C A D B, C E B, C

Figure 6.3 AON diagram corresponding to project in Table 6.2.

As a final example, Table 6.3 shows the immediate predecessors for the LOGON project using work packages from the WBS in Chapter 5. Figure 6.4

shows the corresponding network.

See Chapter 5

Tables 6.1, 6.2 and 6.3 for the examples show only the immediate predecessors for each activity. While it would have been okay to show all the predecessors for each activity in these tables, it would have been unnecessary. For example, had Table 6.2 shown all the predecessors for Activity D (A, B, and C), it would have been correct but also unnecessary because A is the predecessor for B and C, and, hence, listing A would have been redundant. The point: once dependencies have been thoroughly checked, only the immediate predecessors for each activity need be known to construct a network.

Creating a Project Network

A project network is created using a list of activities from the WBS and their predecessors. If done by hand the process is trial and error and the network might have to be redrawn a few times before it is correct. Even if done by computer, good practice is to first sketch out the network by hand to create an initial (“coarse grain”) network and then enter the data into a computer. This affords the project manager an intuitive “feel” for the project. The activities can be clustered into higher-level sub- networks that represent, for example, sub-projects, work packages, or project phases. Project phases are normally conducted in series, although, as mentioned, discretionary dependencies can be eliminated so phases can be overlapped and fast-tracked. Even when phases overlap, however, it is still necessary to define their start and end points so that the phases can be authorized and milestone payments approved.

Table 6.3 Activities and Immediate Predecessors for LOGON Project

Description Immediate Predecessors Duration (Weeks) Basic design – 10

Hardware design for A H 8

Hardware design for B H 6 Drawings for B J 4

Software specifications J 2 Parts purchase for B J 4 Parts purchase for A I 4

Drawings for A I 5 Installation drawings I, J 5 Software purchases L 5

Delivery of parts for B M 5 Delivery of parts for A N 3

Software delivery Q 3 Assembly of A O, S 1 Assembly of B K, R 5

Test A U 2 Test B V 3

Final installation P, W, X 8 Final system test Y, T 6

* Work packages from WBS, Figure 5.5.

Figure 6.4 Network diagram for LOGON project.

In lengthy projects the network might show detailed activities only for the early phases, and rough clusters of activities for later phases. As a phase moves toward completion, details for activities in the next phase are added. This phased approach (called rolling wave planning or progressive elaboration) reduces the complexity of the network for a large project.

Computer software for creating networks is a convenience in small projects but a necessity in large projects. The resulting network should be reviewed for accuracy, omissions, and mistakes. As a rule, the network should be created only after a suitable scope statement and WBS have been developed (i.e., the list of work tasks should be created before—not while—the network is created). Afterward a Gantt chart can be developed, as explained later.

6.2 The Critical Path

Project networks are important tools for project planning and control. They are useful for determining how long the project will take (the expected project duration), when each activity should be scheduled to start and finish, and the likelihood of completing a project on time.

In general, the expected project duration, Te, is determined by finding the longest path through the network. A “path” is any route comprised of one or more activities connected in sequence. The longest path in the network from the start node to the end node is called the critical path, and its length is the expected project duration. Should any activity that forms part of the critical path (called a critical activity) take longer than planned (due to delays, interruptions, lack of resources, etc.), the entire project will take longer than planned.

Figure 6.5 Network for ROSEBUD project.

This concept is illustrated in the following example. The firm of Kelly, Applebaum, Nuzzo, and Earl, Assoc. (KANE) is working on the Robotics Self- Budgeting (ROSEBUD) project. Figure 6.5 shows the network. (Parts (a) and (b) of Figure 6.5 are very similar; for now look only at (a).) The first phase inthe project is systems design (Activity J), followed by the simultaneous phases of (1) purchase, assembly, and installation (Activities M–V–Y), and (2) software specification and purchase (L–Q). These two phases are followed by the last phase of the project, system test and user test (W–X).

How long will this project take? The first activity, J, takes 6 weeks; after J has been completed, activities on the paths M–V–Y and L–Q can begin. The activities on path M–V–Y will take 4 + 6 + 8 = 18 weeks, and the activities on path L–Q will take 2 + 8 = 10 weeks. Because Activity J takes 6 weeks, path M–V–Y will be completed 6 + 18 = 24 weeks, and path L–Q will be completed in 6 + 10 = 16 weeks. The diagram implies that for Activity W to begin, both Activity Y and Activity Q must be finished. Thus, the earliest Activity W can begin is after 24 weeks. Activity W will be completed 1 week later, and Activity X will be completed 1 week after that. Thus, the ROSEBUD project duration (denoted as Te) is Te = 24 + 1 + 1 = 26 weeks.

Notice again from Figure 6.5(a) that there are two paths from the start node (J) to the end node (X). The shorter path J–L–Q–W–X is 18 weeks; the longer path, J–M–V–Y–W–X, is 26 weeks. In general, the longest path—called the critical path —gives the project duration. The critical path is highlighted on the figure; activities with the darker “framed” boxes are critical.

If it becomes necessary to reduce the project duration, any reduction effort (e.g. reducing the time for an activity) must happen on the critical path. Shortening any critical activity by, say, 1 week would have the effect of shortening the project duration by 1 week. In contrast, shortening activities not on the critical path would have no effect on project duration. For example, had either L or Q been reduced by 1 week, then the Activity Q would be completed in Week 15 instead of Week 16; but since Activity W must still wait on completion of Activity Y—which won’t happen until after Week 24, there would be no change in project duration.

As mentioned, the critical path is important for another reason: any delay among the activities on the critical path will result in a delay in the project

completion. Should any critical activity be delayed by, say, 1 week, the project completion will be delayed by 1 week. Note, however, that noncritical activities can be delayed somewhat from their earliest possible dates without delaying the project. In fact, in the example, noncritical activities L and Q can be delayed by up to 8 weeks. This is because normally they will be completed in 16 weeks, which is 8 weeks earlier than the activities on path M–V–Y will be completed, at 24 weeks. In other words, although activities on path L–Q can be completed as early as 16 weeks, it is okay if they are completed as late as 24 weeks. Thus, the critical path shows the project manager which activities are most critical to completing the project on time. To prevent delays, the project manager should focus on the critical activities.

Although the critical path is important, that doesn’t mean the project manager can ignore noncritical activities. Whenever a noncritical activity is delayed, the path to which it belongs gets longer. When the length of a noncritical path grows to exceed the critical path, the former noncritical path becomes critical and the (former) critical path noncritical! In other words, the critical path changes.1 This change can happen without warning and leave the project manager focused on the wrong activities. One solution is to provide warning signals when noncritical activities are at risk of becoming critical; this is done in the critical chain method, discussed in Chapter 7.

See Chapter 7

Figure 6.5(b) illustrates an activity that “spans” multiple other activities, called a hammock. The activity “Monitor progress” is a hammock because it covers every activity in the project except “User test,” implying that the project manager is responsible for monitoring progress on every activity except “User test.” The duration of a hammock is determined by the duration of the longest path of activities over which it spans; in Figure 6.5(b) this is 6 + 4 + 6 + 8 +1 = 25 weeks. Note, however, that although a hammock spans a portion of the longest path, it is not considered a critical activity. (The term “hammock” is also used to describe a summary activity; e.g., a set of activities aggregated into one work package.)

A final example is Figure 6.6. This network has four paths leading from start node H to end node Z:

a. H–J–P–Y–Z 35 weeks b. H–J–K–V–X–Y–Z 42 weeks c. H–J–M–R–V–X–Y–Z 47 weeks d. H–J–L–Q–T–Z 32 weeks

Figure 6.6 Example network showing the critical path (created with Project Scheduler 8.5).

The longest of the four paths is Path c (indicated by the “shadowed” boxes); hence c is the critical path and Te = 47. (In Figure 6.6, notice the arrow between X and Z is unnecessary: if Z follows Y and Y follows X, it goes without saying that Z must follow X!)

Multiple Critical Paths

Can a project have more than one critical path? In a word: yes. Suppose the duration of Activity L in Figure 6.6 were 17 weeks instead of 2 weeks. In that case the durations of path M–R–V–X–Y and path L–Q–T would both be 25 weeks. The project would have two critical paths, both with duration 47 weeks, and the project would be delayed if a delay were to occur on either critical path. If, however, the project duration had to be shortened to less than 47 weeks, it would then be necessary to shorten both critical paths.

Early Times: Early Start (ES) and Early Finish (EF)

Scheduling each activity in a project involves, at the minimum, specifying when the activity must be started and finished. The scheduling procedure depends on whether the project is assumed to start “at Time 0” or “on Day 1.” It makes a difference. The procedure described below is based on the more common “Time 0” assumption; Appendix B to this chapter describes scheduling under the “Day 1” assumption.

The formula for computing finish time given start time and duration is:

Finish time = Start time + Duration

These start and finish times for an activity are represented on the network as “early times”: (1) the early start time (ES), and (2) the early finish time (EF). These times represent the earliest possible times that the activity can be started and completed.

Figure 6.7 Example network showing ESs and EFs.

But the ES of an activity depends on the EFs of its immediate predecessor, which is found by summing the durations of all the predecessor activities along

the path leading to the activity in question. When an activity has more than one immediate predecessor, the ES for the activity will be determined by the immediate predecessor that has the latest EF.

All this is shown in Figure 6.7. Suppose the ES for the first activity, H, is 0 (meaning the project starts at time 0). Since Activity H’s duration is 10 weeks, its early finish, EF, must be Week 10. This was determined from the formula

EF = ES + Duration

In Figure 6.7, ES is shown in the upper left of each node and EF on the upper right.

Given that Activity H’s EF is Week 10, Activity J’s ES will be Week 10 and its EF will be Week 16. Activity J is the only immediate predecessor for activities K, M, and L, so the ES for activities K, M, and L will be Week 16. Activity V has two immediate predecessor activities, K and R, meaning it cannot start until both have been completed. The EF for Activity K is the length of the path H–J–K, or 10 + 6 + 4 = 20; the EF for Activity R is the length of the path H–J–M–R or 10 + 6 + 4 + 5 = 25. The ES for Activity V will depend on the later EF of its two immediate predecessor activities, which is R. Thus, ES for Activity V is Week 25.

The same happens at Activity P: it has two immediate predecessor activities, I and J. Since Activity I’s EF is 18 and Activity J’s ES is 16, Activity P’s ES must be Week 18. Activity Y has three immediate predecessor activities, W, P and X; Activity X has the latest EF, 33, thus the ES for Activity Y is Week 33. Finally, the ES for Activity Z is 41, the latest EF of its immediate predecessor activities and Y and T. Activity Z’s EF is Week 47, which gives the expected project duration, Te, 47 weeks.

In summary, ESs and EFs are computed by taking a “forward pass” through the network. When an activity has only one immediate predecessor, its ES is simply the EF of the predecessor. When an activity has several immediate predecessors, its ES is based on the latest EF of all the immediate predecessors.

Late Times: Late Start (LS) and Late Finish (LF)

As earlier discussed, a noncritical activity can be delayed without delaying the

project; the question is, How much can it be delayed? To answer that we must determine the “late times,” that is, the latest allowable times an activity can be started and finished without delaying project completion. Just like the ES and the EF, every activity has a late start time, LS, and a late finish time, LF.

Refer to Figure 6.8. LS is shown on the lower left of each node, LF on the lower right.

To determine the late times, begin by assigning a target completion date, Ts, to the last node in the network. For projects that have to be completed as soon as possible, the date for Ts is the same as the Te calculated in a forward pass—the EF of the last activity. For projects with a due date set by the customer or the sponsor, Ts is the due date, not the calculated Te value.

To determine the late times, start at the last activity in the network and make a “backward pass” through the network using the formula:

LS = LF – Duration

In Figure 6.8, start with Activity Z. If Ts is 47 weeks, then LF for Activity Z is 47 and LS is 47 – 6 = 41; i.e., Activity Z must start in Week 41 for the project to end in Week 47. Continuing backward, for Activity Y and Activity T the LF is 41 weeks, and LS for Y is 41 – 8 = 33. Continue moving backward like this through each path, computing LF and LS for each activity.

Figure 6.8 Example network showing LFs and LSs.

Whenever we encounter an activity that has multiple paths leading back to it (i.e., it has multiple immediate successors), it is the earliest (or smallest) EF of the immediate successors that determines the activity’s LF. For example, Activity J has four paths leading back to it (four immediate successor activities):

• LF for Activity P = 33 weeks (because LS for Activity Y is Week 33); thus LS for P is 33 – 5 = 28

• LF for Activity K = 25 weeks (because LS for Activity V is Week 25); thus LS for K is 25 – 4 = 21 weeks

• Similarly, LF for Activity M = 20, so LS = 20 – 4 = 16 weeks • LF for Activity L = 33, LS = 33 – 2 = 31 weeks.

Since the smallest (earliest) LS is 16 for Activity M, the LF for Activity J is16; this is the latest time Activity J can be finished to enable all of its successors to meet their late start times and, thus, complete the project by its target date of 47

weeks. In summary, calculations for LFs and LSs start at the last node of the project

network and work backward. When an activity has more than one path leading back to it, the smallest (earliest) value of LS among the immediate successors is the basis for determining the activity’s LF. Having completed both forward and backward passes through the network, we now have the earliest possible and latest allowable scheduled times for every activity in the network. Once the forward and backward pass calculations have been completed the durations of hammock activities become evident.

Total Slack

Notice that for most activities in Figure 6.8, the ESs and LSs are not the same. The difference between LS and ES (or LF and EF) is referred to as total slack (also called “total float” or simply “slack” or “float”) of an activity. Slack is the amount of allowable deviation between when an activity must take place at the latest and when it can take place at the earliest. It is the amount of time an activity can be delayed without delaying the project:

Total slack = LS – ES = LF – EF

In Figure 6.8 the total slack for Activity H using start times is 0 – 0 = 0 weeks; for Activity I it is 15 – 10 = 5 weeks, and so on. Notice that activities on the previously identified critical path H –J–M–R–V–X–Y–Z have zero slack; hence, these activities cannot be delayed by any amount without delaying the project. (The case where critical activities do have some slack is discussed later.) The activities that do have slack (which, as it turns out, are the noncritical activities) can be delayed from their earliest possible dates by their slack time without delaying project completion. Total slack is shown in Table 6.4.

When activities lie in sequence on a path, a delay in earlier activities will result in a delay to later ones; this is the equivalent of reducing slack for the remaining activities. In Figure 6.8, for example, activities L, Q, and T all lie on the same path and all have the same slack of 15 weeks. But if Activity L is delayed 5 weeks, then activities Q and T will also be delayed 5 weeks and, thus, will have only 10 weeks

of slack remaining, not 15. If, in addition, Activity Q is delayed 10 weeks, then Activity T will have no remaining slack and must be started immediately upon completion of Q. Having used up all their slack, Activities L, Q and T would then all become critical activities. Once slack is used up, noncritical activities become critical activities, which means any further delays for these activities will delay project completion.

The practical implication of slack is that it gives the project manager flexibility regarding exactly when noncritical activities can be scheduled: they can be scheduled any time as long as it lies somewhere within the available slack— between the ES and LF times. Knowing the slack is important for managing resource workload. By starting some activities as early as possible and delaying others, the workload can be smoothed; this concept is discussed later. In general, when there are sufficient resources, noncritical activities are usually scheduled as early as possible (their ESs); this preserves slack and minimizes the risk of noncritical activities delaying the project. (Another method, called the critical chain and discussed in Chapter 7, schedules activities as late as possible.)

Notice that decisions about when exactly to schedule an activity require knowing both the late and early times for the activity. The implication is that a network analysis should be done before the Gantt chart is created. Most project management software develops networks and Gantt charts simultaneously, although they create Gantt charts using the early times. As discussed, however, activities should not necessarily be scheduled according to the early times.

Table 6.4 LOGON Project Time Analysis (from Figure 6.8)

Free Slack

While total slack refers to the amount of time an activity can be delayed without delaying the project, the term free slack refers to the time an activity can be delayed without delaying the start of any successor activity. Free slack of an activity is determined by the formula:

Free slack for activity = ES (earliest successor) – EF (activity)

For example, in Figure 6.8 Activity I has a total slack of 5 weeks but free slack of 0 weeks because any delay in it will delay the start of activities N, O, and P. Activity O, on the other hand, has free slack of 2 weeks because its EF of 23 can

be delayed to 25 without delaying the ES of its successor, Activity U, which is 25. Knowing the free slack, managers can readily identify activities where

slippages immediately impact other activities. When an activity has zero free slack, any slippage will cause at least one other activity to slip also. If, for example, Activity L slips, then so will Q and T, and teams working on Q and T (specified in the responsibility matrix) must be notified of the delay.

As with total slack, the amount of free slack available to an activity assumes the activity starts at its ES time. Thus, the free slack for Activity O is 2 weeks, as long as Activity I, its immediate predecessor, is completed at EF = 18. If Activity I is delayed by any amount, then Activity O’s free slack will be reduced by that same amount.

Free slack is important because many activities are scheduled to start as soon as possible and resources are booked to be available on these dates. If an activity is delayed, it can delay other activities and disrupt the schedules of everyone who planned to work on those activities. Moreover, such delays extend the period over which resources (e.g. equipment contracted at a daily or hourly rate) are needed and can lead to cost overruns.

Table 6.4 summarizes these concepts, showing ES, LS, EF, and LF, and total and free slack for the LOGON project in Figure 6.8. Notice that for activities on the critical path the total slack and free slack times are zero.

The Effect of Project Due Date

In discussing total slack we assumed that the target completion date, Ts, was the same as the earliest expected completion date, Te. But in fact the target completion date can be set to be either later or earlier than Te to reflect a customer’s or supporter’s wishes.

Setting the target date to later than Te has the effect of increasing total slack for every activity in the project by the amount Ts – Te. Although no longer zero, the slack on the critical path will still be the smallest slack anywhere in the network. For example, if the target completion date for the project in Figure 6.8 were increased to Ts = 50 weeks, then the total slack in Table 6.4 would be 50 – 47 = 3 weeks for all critical activities and 3 additional weeks for all noncritical

activities. If Ts is set earlier than Te, then the total slack times everywhere in the project

will be reduced by the amount Ts – Te and activities along the critical path will have negative slack times. The size of this negative slack is the amount of time by which the project duration must be reduced to meet the customer target date. (Note that altering Ts has no influence on free slack times: these depend on early start and early finish times, both of which are affected by the same amount when changing Ts.)

In general, projects must be completed either as soon as possible or by a predetermined due date. For projects that have to be completed as soon as possible, the project manager does a forward-pass calculation through the network, then commits to the resultant Te. For projects that must meet a predetermined due date, the project manager substitutes Ts at the last event, then works backwards through the network, noting the feasibility of speeding up activities in the project to eliminate negative slack times on the critical path.

6.3 Converting to Gantt Calendar Schedules

Using information from tables such as Tables 6.2 or 6.3 to create a network with activity start and finish times is a simple procedure that requires no management decisions and can readily be performed by computer software. To be usable, however, the times in the network must be converted into dates (day, month, and year) on either a Gantt chart or an actual calendar. But converting network times to a Gantt or calendar schedule is not a simple procedure and does require management decisions.

Figure 6.9 LOGON project schedule adjusted for holidays and weekends.

For starters, the Gantt or calendar schedule must account for non-working time such as weekends, holidays, and vacations. Figure 6.9 shows the LOGON project schedule as produced by Microsoft Project software and incorporating time off for weekends and holidays.

In addition, a calendar schedule must account for issues that require analysis and management decisions; examples include:

• Resource constraints: a work package is delayed because the necessary resources are unavailable or must be shared with other, parallel activities.

• Cash flow: procurement of an expensive piece of equipment must be

delayed in order to defer cash outlay, improve cash flow, or await an exchange rate improvement.

• Risk of changes: a design activity is postponed due to changes in project scope, developing technologies, other design activities.

• Logistics: the acquisition of a bulky item for construction is delayed until space becomes available at the construction site.

Computer software can readily generate the project network, Gantt chart, and calendar schedule but unless issues like those listed above are accounted for, the project schedule will be infeasible, unworkable, or too risky. The point is, project scheduling involves more than merely creating a computer-generated version of the project network; it requires analysis and management judgment. Thus, the Gantt chart should be created only after a network analysis has determined the early and late dates, and issues and constraints surrounding the project have been addressed.

6.4 Management Schedule Reserve

In common practice, the contractual or committed target completion time Ts is not simply the estimated completion time Te (plus allowance for non-working time) but rather is some time after that and includes a management schedule reserve. This chapter has treated activity times and project durations as if they are fixed. Of course, each project is unique, and until it is actually completed its duration is no more than an estimate (a best guess). All estimates (of projects and of the activities that compose them) are subject to uncertainty; the more unique the project, the larger the uncertainty. To account for that uncertainty a management schedule reserve is added to the estimated duration. This reserve constitutes a “safety buffer” or “time buffer” to accommodate any project delays. Time buffers are discussed in Chapter 7.

See Chapter 7

6.5 Alternative Relationships2

The network scheduling procedures discussed earlier assume a sequential relationship wherein the start of an activity is predicated upon the completion of its immediate predecessors. Such is the case illustrated in the diagram in Figure 6.10 where Activity B starts upon completion of Activity A. This strict start-only- when-predecessors-finish relationship is called finish-to-start, FS. The limitation of this assumption is that it precludes those kinds of tasks that can be started when their predecessors are only partially (but not fully) completed. For example, when a company relocates to a new facility, the activity “move-in employees” should be able to start after some of the activity “move-in furniture” has been done; i.e., “move-in employees” can begin before its immediate predecessor “move-in furniture” has been completed. The precedence diagramming method (PDM) allows for this and similar such situations. Besides the usual FS relationship, PDM also permits other relationships such as start-to-start (SS), finish-to-finish (FF), and start-tofinish (SF). It also allows for lags between the times when activities must be started or finished. These relationships are described next.

Figure 6.10 Example of FS relationship.

Start-to-Start (SS)

In an SS relationship between two activities A and B, the start of B can occur at the earliest n days after the start of its immediate predecessor, A. This is diagrammed in Figure 6.11. The n days delay is called lag. In the case of acceleration instead of a delay, lead is used instead of lag (lead is the

mathematical negative of lag).

Figure 6.11 PDM representation of SS relationship with n day lag.

Using the example from Figure 6.10, suppose that “move-in employees” can begin 5 days after the start of “move-in furniture”; the network diagram and associated Gantt chart for the two activities would appear as in Figure 6.12.

Figure 6.12 Example of SS relationship.

Finish-to-Finish (FF)

In an FF relationship between two activities A and B, B will finish n days at the latest after A finishes. An illustration is in Figure 6.13 where the finish of “paint parking lines” (B) must occur within 5 days of the finish of “lay asphalt”(A). Two or more activities that must finish at the same time is an FF relationship with zero lag.

Figure 6.13 Example of FF relationship.

Start-to-Finish (SF)

In an SF relationship, the finish of Activity B must occur at the latest n days after the start of Activity A. For example, “phase-out old system” (B) cannot finish until 25 days after “test new system” (A) begins. This is shown in Figure 6.14.

Figure 6.14 Example of SF relationship.

Finish-to-Start (FS)

In an FS relationship, Activity B can start at the earliest n days after Activity A is finished. For example, “tear down scaffolding” (B) can start no sooner than 5 days after “plaster walls” (A) is finished. This is shown in Figure 6.15. Note that when n = 0, the FS relationship becomes the same as traditional AON network method

wherein the start of a successor coincides with the completion of its latest predecessor.

Figure 6.15 Example of FS relationship.

Multiple PDM Relationships

Two PDM relationships can be used in combination. Having both SS and FF is a rather common case. Notice in the example shown in Figure 6.16 that because B must finish no later than 10 days after A finishes, the start of B must occur at day 10. But suppose B is an interruptible activity (i.e., the work in B can be stopped and then resumed). In that case, B could instead be started 5 days after the start of A and finish 10 days after A finishes. This is represented in Figure 6.17. The assumption is that the 15 days of work for B will be performed sometime within the 20 days allotted between days 5 and 25.

Figure 6.16 Schedule for non-interruptible activity B.

Figure 6.17 Schedule for interruptible activity B.

Notice that the 20 days allotted for Activity B gives that activity two possible slack values, LS – ES = 5 or LF – EF = 0. PDM usually observes the smallest slack value, here 0.

Example 6.1: PDM in ROSEBUD Project

Figure 6.18 shows the AON diagram for the ROSEBUD project and Figure 6.19 shows the corresponding “time-scaled network,” which is a form of Gantt chart explicitly showing dependencies among the activities.

Figure 6.18 AON diagram for ROSEBUD project.

Figure 6.19 Time-scaled network for ROSEBUD project.

The network will now be altered to permit the following special relationships:

1. Activity L can begin 3 days after Activity G begins, but it cannot be finished until G is also finished.

2. Activity Y can begin 2 days after Activity V begins, but it cannot be finished until at least 6 days after V is finished.

3. Activity W can begin 5 days after Activity Y begins, but it cannot be finished until Y is also finished.

4. Activity X cannot be started until at least 1 day after Activity W is finished.

The PDM network in Figure 6.20 shows these relationships. Figure 6.21 shows the corresponding time-scaled network assuming earliest start dates and allowing for interruptible activities.

Figure 6.20 PDM network for ROSEBUD project.

Figure 6.21 Time-scaled network for ROSEBUD project revised for PDM.

A traditional FS network can handle relationships where FS > 0 by creating artificial activities, but it has no way of incorporating SS, FF, or SF; thus, the obvious advantage of PDM is that it permits greater scheduling flexibility. The tradeoff is that PDM networks are more complex and require greater care both in their creation and interpretation. Because activities do not follow a neat FS sequence, finding the critical path and slack times is not so simple either. Complex precedence relationships also cause counterintuitive results. For

example, in a simple network the way to reduce the project completion time is to reduce the duration of activities on the critical path; doing the same thing in a PDM network, however, does not necessarily shorten the project. In the previous example, the critical path is G–M–V–Y–W–X. Suppose we decide to reduce the time on Activity Y. Because of the precedence requirement that Y cannot finish sooner than 6 days before V finishes, the completion date of Y cannot be changed. Thus, any shortening of the duration of Y serves to move back the start date of Y. Because of the precedence requirement, moving back the start date of Y results in moving back the start date of W and, as a result, the start date of X. In other words, shortening critical Activity Y actually causes an increase in the project duration.

In general, interpreting a PDM network requires more care than ordinary AON networks. However, such care is relatively inconsequential when the PDM network is created with project management software.

6.6 Scheduling with Resource Constraints

While people think project scheduling means scheduling work tasks or activities, it is more important to think of it as scheduling resources. That’s because every activity requires resources—people, equipment, material, working capital, etc., and whenever an activity is scheduled, that means resources are scheduled too. So far we have assumed that such resources would always be available when needed. But of course resources are not always available, and when they are not the schedule must be changed to whenever they will be available. We now consider project scheduling when resources are constrained and the effect it has on workload and project duration.

Resource Availability and Project Duration

Many times the availability of skilled workers, equipment, and working capital dictate whether activities can be scheduled at their early times or must be delayed. This is especially true when multiple activities requiring the same resource are scheduled for the same time. When resources are not sufficient to satisfy the needs of all of them, some activities must be delayed. Figure 6.22 illustrates this: (a) shows the network; (b) shows the project schedule, not accounting for the resources. Suppose Activities B and C both require the same resource, but the resource can be used by only one of them at a time. In that case, the schedule must be revised; (c) shows two alternatives.

Figure 6.22 The effect of a constrained resource on schedule.

In general, projects tend to be either resource-constrained or time-constrained. In a resource-constrained project, the resources are limited in some way and the project completion date is determined by the availability of those resources. Figure 6.22 is an example. In a time-constrained project, the projectcompletion date is fixed and sufficient resources must be found to meet that date. A project that is both resource-constrained and time-constrained might not be able to meet the target completion date.

Resource Allocation, Workload, and Resource Loading

The terms resource allocation, workload, and resource loading convey related but different concepts. Resource allocation refers to assigning one or more resources

to an activity or project. Workload refers to the amount of work imposed on a resource. Resource loading refers to the amount of a particular resource needed to conduct all the activities in a project to which the resource is allocated. For an individual resource (such as a person), the workload can be specified either as a percentage of the resource’s full workload potential or, more commonly, in units such as labor hours. For a facility or labor category (such as a department of workers with specific skills), the workload is specified in terms of number of workers. Since people in a labor category (such as “computer programmer”) seldom have exactly the same skills, ordinarily it is better to allocate a specific person (a specific programmer) rather than a labor category to an activity. The usual assumption when allocating people from a labor category is that everyone in the category is equally capable; often, though, after the work begins it becomes evident that not everyone is equal.

The workload that an individual can handle in a year is computed as the number of working days (excluding holidays and all types of leave) times the number of productive (working) hours per day. Many companies have guidelines restricting the number of hours an individual should work on projects per week, month, or year. In a matrix organization, functional managers are responsible for ensuring that each worker’s time is well utilized and her workload does not exceed a recommended maximum.

Workload is always from the perspective of the particular resource; loading, in contrast, is from the perspective of the project. It is the number of hours, people, or other units of a particular resource needed at a given time in a project (or in multiple concurrent projects). Resource loading is important since virtually all resources are finite and many are scarce. Thus, the resource loading (total amount of the resource needed for a project or projects at a given time) cannot exceed the amount available. When resources are scarce, their allocation is constrained, and sometimes activities in a project must be rescheduled to accommodate the scarcity. The example in Figure 6.22 was such a case: Activities B and C require the same resource, but the resource cannot be used in both at the same time. Resources available in sufficient quantity do not pose an issue and can be ignored for scheduling purposes (air is an example—unless the project is conducted under water or in outer space where air is limited!).

The following sections consider two cases where the project schedule must be

altered to accommodate resources. The first is called resource leveling in a time- constrained project. In this case, there is enough of the resource to complete the project on time; however, the quantity of the resource needed fluctuates throughout the project, making it difficult to manage the resource. The objective of resource leveling is to level the amount of the resource needed throughout the project. The second case is the situation mentioned before, the resource- constrained project—not having enough of a resource to do multiple activities at the same time.

Leveling a Time-Constrained Project

Because the loading for a particular resource depends on the amount of the resource needed by project activities and the start and finish dates of those activities, the loading for a particular resource tends to vary throughout a project. A common resource-loading pattern in a project is a steady buildup in the amount of the resource needed, a peak, and then a gradual decline. Thus, relatively little of the resource is needed early and late in the project, but much is needed in the middle. This pattern is problematic for functional managers who are responsible for a stable, uniform pool of workers and equipment because it results in the pool being either underworked or overworked. Certainly better would be a relatively uniform workload on the resource pool. This is the purpose of resource leveling: to alter the schedule of individual project activities such that the resultant workload for a required resource is somewhat uniform throughout the project.

Figure 6.23 Schedule and corresponding worker loading for the LOGON project.

Figure 6.23 shows the loading of a resource for the LOGON project—the resource being a particular skill or trade (programmer, steel worker, etc.). The loading, bottom of Figure 6.23, is created from the schedule, top of Figure 6.23, and the weekly labor requirements in Table 6.5; it shows week by week the number of workers needed in the project. For example, for the first 10 weeks only activity H is scheduled, so the loading for those weeks stays at five workers (the weekly requirement for H). Over the next 6 weeks, activities I and J are scheduled, so the loading becomes 4 + 8 = 12, and so on.

Table 6.5 LOGON Project Weekly Labor Requirements

Figure 6.24 Smoothed worker loading for the LOGON project.

From Figure 6.23, you can see that the loading for the LOGON project might pose a problem because it fluctuates so much, varying from a maximum of 23 workers in Week 26 to zero workers in Weeks 24 and 25 (since activities R, S, and T are outsourced and do not require any workers). The problem facing the manager allocating these workers to LOGON is what to do with excess workers in slow periods and where to get additional workers in peak periods.

A way to handle the problem is to adjust the worker loading so it is more “level.” This is done by “juggling” activities—by taking advantage of slack times and delaying noncritical activities after their early times so as to reduce workload peaks and fill in workload valleys. For example, the somewhat smoothed workload in Figure 6.24 is achieved by delaying activities P (and hence Q) by 2 weeks and U (and hence W) by 5 weeks.

Although resource leveling is often necessary to reduce workload fluctuations, it potentially increases the risk of project delays because it reduces slack time. Less slack time means greater risk that an activity will not be completed by its scheduled finish date. In Figure 6.24 delaying activities U and W makes them critical (no slack remaining), so any delay in either will delay the project.

Splitting Activities, Multi-tasking, and Hand-Over Points

In the previous example an even more uniform loading could have been achieved if activities were split and the pieces scheduled at different times. Whether this is feasible depends on whether a job, once started, can be interrupted and then restarted later. As discussed earlier, project activities and work packages are defined during the WBS process, and these activities become the basis for establishing schedules, budgets, and so on. Once an “activity” has been defined in the WBS, it cannot be arbitrarily “split” later on.

Figure 6.25 The effect of splitting of an activity upon duration.

Although activity splitting can lead to a more uniform loading, the downside is that it can lead to wasted time and longer activity durations. Figure 6.25 illustrates how this happens. Uninterrupted, the activity starts slowly but then builds momentum as it moves ahead. Split into pieces, each piece starts slowly and never gathers momentum. The sum of the durations of the pieces in (b) exceeds the duration in (a). The effect, known as multi-tasking, leads to slower- paced work on average and extends the activity duration. The moral is, once an activity has been started, it is usually better to finish it uninterrupted.

Multi-tasking, wherein the work is stopped and then resumed, should not be confused with work that continues uninterrupted but has multiple hand-over points. The hand-over concept is illustrated in Figure 6.26 where the design and build activities each proceed uninterrupted, although multiple hand-over points (called “laddering”) enable the build activity to start and continue well before the entire design activity (encompassing Design A + Design B + Design C) is completed. Although the activities appear to be split (Design A, Design B, Design C), in fact they are not since there is no time lag between them. The method shortens the project duration and facilitates interaction between designers and builders.

Figure 6.26 Multiple hand-over points of an uninterrupted activity.

Leveling Multiple Resources

Leveling is easy for a single resource but can be difficult for several simultaneous resources. Because work packages usually require resources from more than one functional unit or subcontractor, a schedule that provides a level loading for one unit may cause overloading or difficult-to-manage situations for others. For example, based on the weekly equipment requirements for LOGON shown in Table 6.5, the schedule that provides the somewhat-level worker loading in Figure 6.24 yields the erratic equipment loading shown in Figure 6.27. An attempt to level the equipment loading by adjusting or delaying activities will disrupt the worker loading. As you can verify, the schedule in Figure 6.23 that produces the erratic loading for workers yields a relatively level loading for equipment.

It is impossible to completely level the load for all resources at once. The best results arise from applying the scheduling equivalent of the “Pareto optimum”; that is, schedule activities in the best interests of the project while trying to minimize the number of conflicts and problems in the departments and contractors that supply the resources. When considering multiple resources simultaneously, focus on leveling the “priority” resources—those where irregular loadings are the most costly to the organization or demoralizing to workers. The financial and social costs associated with hiring, overtime, and layoffs often dictate that “human resources”—the workers—be given the highest priority. Many project software packages perform scheduling analysis that permit simultaneous leveling of multiple resources.

Delaying activities is one method to level resources; others are to:

• Eliminate some work segments or activities (reduce project scope). • Substitute resources. • Substitute activities with less resource-consuming activities.

For example, when the most qualified workers are not available, either eliminate the work that requires their expertise or use less qualified workers. These options, however, might compromise the scope or quality of the work and increase the

risk of the project not meeting requirements.

Figure 6.27 Equipment loading for the LOGON project.

Leveling a Resource-Constrained Project

What happens when the number of personnel, pieces of equipment, or available working capital restricts the schedule? This is a resource-constrained project. Activities in the project must be scheduled so that the loading of a particular resource to the project does not exceed the available maximum. The focus differs from time-constrained resource leveling because the issue is the resource’s maximum requirement, not its loading variability. As each activity is scheduled, the sum of its required resources plus the resources required for activities already scheduled at the same time must be checked against the maximum. The problem is more than just leveling of resources; it involves rescheduling jobs or delaying them until the resources become available.

In the LOGON project, for example, suppose only 14 workers are available in any given week. The “leveled” schedule in Figure 6.24 results in a maximum

loading of 15 workers. In this case it is not possible to reduce the maximum loading to less than 15 and still complete the project in 47 weeks. To reduce the loading to the 14-worker maximum, some activities will have to be delayed beyond their late start dates, which will delay the project. With a problem like this something has to give, since it is not feasible to both satisfy the resource restriction and the project deadline of 47 weeks. Figure 6.28 shows a schedule that satisfies the 14-worker constraint. It was determined by trial and error, making certain not to violate either the precedence requirements or the 14- worker limit. Notice that the project now requires 50 weeks to complete because Activity X had to be delayed 3 weeks beyond its late start date.

Figure 6.28 Schedule and corresponding worker loading for the LOGON project with 14-worker constraint.

As the example shows, a resource needed by multiple activities can dictate the project duration and override the critical path time. Consider another example from the LOGON project. Suppose one important project resource is a technical

inspector who has the skills to inspect and approve a variety of activities. Her work is exacting, however, which prevents her from working on more than one activity at a time. Suppose the activities in which she will be working are H, J, P, K, L, V, and X. These activities are highlighted in Figure 6.29. Because she can work on them only one at a time, the activities must be scheduled sequentially. Summing the durations of these activities gives the time required for her to inspect all of them, 35 weeks. Add to this the times for the last two activities, Y and Z, and the total is 49 weeks. Thus the project duration will be 49 weeks, not 47 weeks as determined by the critical path.

Figure 6.29 Activities in the LOGON project involving the resource of technical inspector.

Goldratt calls the path connecting activities that require the same constrained resource the critical chain (here, H–J–P–K–L–V–X plus Y and Z) and distinguishes it from the critical path (H–J–M–R–V–X–Y–Z).3 Back in Figure 6.22, the critical path is A–C–D but the critical chain is A–C–B–D or A–B–C–D. The significance of this is that when activities must be performed sequentially due to a constrained resource, and when the sum of the durations of those activities, the critical chain, exceeds the length of critical path, it is the critical chain—not the critical path—that sets the project duration. This is further

discussed in Chapter 7.

See Chapter 7

Scheduling with constrained resources involves decisions about which activities can be scheduled immediately and receive resources, and which should be delayed until resources are available. Project management software uses procedures based on simple rules (called heuristics) for scheduling with constrained resources; some of these are discussed in the next chapter.

The constrained-resource problem also occurs in multi-project organizations that draw resources from a common pool. To schedule activities for any one project, managers must account for the resources required by other, concurrent projects. The result is that schedules for some projects are determined in part by when resources will be freed-up from other, higher priority projects.

6.7 Criticisms of Network Methods

Network methods have been criticized because they incorporate assumptions and yield results that are sometimes unrealistic. For example, they assume that a project can be completely defined upfront in terms of identifiable activities with known precedence relationships. In many projects, however, not all work tasks can be anticipated or clearly defined at the start. Rather, the project “evolves” as it progresses. But this is a problem with scope planning and activity definition, which plagues every scheduling method, not just networks.

A related problem is that activities and durations in a schedule sometimes require periodic modification; this happens when there are too many activities in the network and not all are well defined. This problem can be addressed by initially creating a “rough” schedule and then developing more-detailed schedules in a phased approach (discussed in Chapter 4) and by avoiding “proliferation” of activities, i.e., keeping the number of activities in the schedule to a minimum as prescribed in the work definition guidelines in Chapter 5.

See Chapter 4 and 5

Another criticism relates to the fact that because it is sometimes difficult to demarcate one activity from the next, the boundary separating activities more or less arbitrary. This means that successors can sometimes be started before predecessors are finished, and the two “overlap” in the sequence. But again, this is not really a problem since PDM allows for overlap of activities, and hand-over points to treat activities as if they did overlap.

In summary, the shortcomings of networks are actually shortcomings in project definition. It can be argued (and innumerable project managers will attest) that network methods, though not perfect, offer a good approach for analyzing and creating project schedules.

6.8 Summary

The advantage of networks is that they clearly display the interdependencies of project activities and show the scheduling impact that activities have on each other. This feature enables planners to determine critical activities and slack times, which is important for project planning and control. Knowledge of critical activities tells managers where to focus; knowledge of slack enables them to address the problems of non-uniform resource requirements and limited resources. The PDM method accounts for a variety of relationships between project activities to better reflect the realities of project work.

The next chapter describes other well-known and more advanced network scheduling methods: PERT, simulation, time-cost tradeoff analysis (CPM), and critical chain project management (CCPM).

Summary List of Symbols

T e Expected Project Duration: the expected length of the project.

T s Target Project Completion Date: the contracted or committed date forproject completion.

ES Early Start for an Activity: the earliest feasible time an activity can be started.

EF Early Finish for an Activity: the earliest feasible time an activity can be completed.

LS Late Start: the latest allowable time an activity can be started to complete the project on target.

LF Late Finish: the latest allowable time an activity can be completed to complete the project on target.

t Activity Duration: the most likely or best guess of the time to complete an activity.

FS = n

Finish-to-Start: an activity can start no sooner than n days after its immediate predecessor has finished.

SS = n

Start-to-Start: an activity can start no sooner than n days after the start of its immediate predecessor.

SF = n

Start-to-Finish: an activity can finish no later than n days after its immediate predecessor has started.

FF = n

Finish-to-Finish: an activity can finish no later than n days after its immediate predecessor has finished.

Summary Illustration Problem

Appendix A: AOA Diagrams

The chapter described the AON method of network diagramming. Another diagramming method is the activity-on-arrow (AOA) or arrow diagramming technique. The major feature that distinguishes AOA from AON is the way activities and events are denoted on the network. Figure 6.30 shows the AOA representation for one activity and its events.

The AOA method represents each activity as a directed line segment (an arrow) between two nodes (or circles). As shown in Figure 6.30, the nodes represent the start and finish events for the activity, and the arrow in between represents the activity itself. The number inside each node merely identifies the event. Each event must have its own unique number. In the example, the numbers 14 and 15 were chosen arbitrarily. Node 14 means “start Activity Y” and node 15 means “finish Activity Y.”

The length of the arrowed line has no significance in AOA. As in AON networks, an AOA network should have only one origin event and one terminal event. All arrows must point generally toward the right end of the network; the arrows cannot double back.4

Figure 6.30 AOA representation for an activity and its start and finish events.

As in the AON method, the activities follow a sequential order as defined by their immediate predecessors. When an activity has more than one immediate predecessor, the network must show that it can be started only after all of its immediate predecessors have been completed. This is the purpose of a special kind of activity called a “dummy.”

Dummy Activities

A dummy activity is used to illustrate precedence relationships in AOA networks. It serves only as a “connector”—it is not a “real” activity and represents neither work nor time. The following example demonstrates the need for dummy activities in an AOA network.5

An engineer decides to write a new computer program and to buy a new computer to run it on. The activities and their dependencies are illustrated in the AON network in Figure 6.31. The dependencies are:

1. Pay for the computer after buying the computer. 2. Install the computer program after writing the program and after buying

the computer.

Figure 6.31 AON diagram.

Figure 6.32Figure 6.31 converted to AOA diagram.

The AOA network for this project is shown in Figure 6.32. Note that to show the dependencies “install program” after both “buy computer” and “write

computer program” requires a dummy activity (the dashed arrow) between node V and node Y. This dummy links “install program” to its two immediate predecessors, “buy computer” and “write computer program.” Notice that the overall network has only one “Start” node and one “End” node.

AON versus AOA

Since AON networks do not require the use of dummies, they are easier to construct and interpret than AOA networks; as a consequence, they are more popular. But because AOA diagrams use line segments (the arrows) to represent the flow of work and time, they can easily be converted into time-scaled networks that look like Gantt charts. Some project software packages create time- scaled networks, and some create both AOA and AON network diagrams. For a particular project, only one network method should be used.

Appendix B: Alternate Scheduling Method: Project Starts at Day 1

The scheduling technique illustrated in this chapter is the usual approach to introduce network scheduling. It assumes that the project begins at time zero and that a successor activity begins immediately upon completing all its predecessors. The method is simple and is mathematically correct.

Some managers, however, argue that for practical purposes the method is incorrect. Project managers speak of the “first day” of the project, not the “zeroth day.” Thus, they say, the project start time should be indicated as Day 1, not Day 0. Further, whenever activities are in series, each successor activity starts on the period following the completion of its predecessors, not at the same time. Thus, the network would show the early start time of an activity as being the day (or week) later after the early finish day (or week) of its latest predecessor. Realistically this approach makes sense.

As an example, refer to Figure 6.33, which is Figure 6.8 revised for “Day 1” assumptions. Activity H is the first activity in the project and lasts 10 days. Using the Day 1 scheme, for Activity H ES = 1. In making the forward pass through the network, computationally EF = ES + Duration – 1. This, EF = 1 + 10 –1 = 10. The ES for Activity H’s successors, Activity I and Activity J, is on the next day, i.e., ES = 11.

Figure 6.33 Figure 6.8 adjusted for “Day 1” assumption.

Using the assumptions of course affects the late times too. Making the backward pass through the network, LS = LF – Duration + 1. Thus, for Activity I with duration 8, if LF = 18 then LS = 18 – 8 + 1 = 11. The immediate predecessor of Activity I, Activity H, must finish the day before this, so LF = 10 for Activity H.

The Day 1 scheme does not impact the computation of total slack, which remains the simple difference between early and late start times or early and late finish times. It does however change the computation of free slack:

Free slack for an activity = ES (earliest successor) – EF (activity) – 1

Project management scheduling software uses actual dates, not elapsed times, and the project start will be indicated by the date of the first day (or week) of the project. Throughout the network, the start dates of successor activities will be shown as the next period (day or week) after the finish dates of their successors.

Review Questions and Problems

1. What are the advantages of networks over Gantt charts? 2. Draw a network diagram of your college studies, starting with

enrolment and finishing with graduation. Indicate the courses, projects, and exams as well as precedence relationships where applicable.

3. How is a WBS used to create a network and what role does a scope statement play?

4. Can a Gantt chart be created from a network? Can a network be created from a Gantt chart? Which is the preferred way? Explain.

5. Why is it vital to know the critical path? Explain the different ways the critical path is used in network analysis and project planning.

6. Explain the difference between total and free slack. 7. Explain the difference between ES, EF, LS, and LF. 8. Consider each of the following projects:

a. Composing and mailing a letter to an old friend. b. Preparing a five-course meal (you specify the course and dishes

served). c. Planning a wedding for 500 people. d. Building a sundeck for your home. e. Planning, promoting, and conducting a rock concert. f. Moving to another house or apartment. g. Developing, promoting, manufacturing, and distributing a new

packaged food item. h. Developing and installing a computerized information system,

both hardware and software. i. Remodeling a bathroom. j. Adding a bedroom to a house.

Now, answer the following questions for each project:

1. Using your experience or imagination, create a WBS.

2. List the activities or work packages. 3. Show the immediate predecessors for each activity. 4. Draw the network diagram (using the AON scheme).

9. Draw the AON network diagrams for the following four projects:

1. Activity Immediate Predecessor

A – B A C A D B E D F D G D H E, F, G

2. Activity Immediate Predecessor

A – B A C A D B E B F C G D H D I G J E, F, H, I

3. Activity Immediate Predecessor

A –

B A C – D – E D F B, C, E

4. Activity Immediate Predecessor

A – B – C – D C E A F B G E H F, G,J I A J D, I

10. Refer to Figure 6.1 in the text.

a. If the person wants to get more sleep by waking up later, which of the following steps would be useful?

i. Put socks on faster. ii. Put tie in pocket to put on later. iii. Put shoes on faster. iv. Buy a hair dryer that works faster.

b. Calculate the total float and free float of the activity “Put on socks.”

11. Eliminate redundant predecessors from the following lists so only immediate predecessors remain.

a. Activity Predecessor A – B – C – D B E C F A G B, D, C, E H A, B, C, D, E, F, G

b. Activity Predecessor A – B A C A D A, B E A, B F A, C G A, B, C, D, E, F H A, B, C, D, E, G

c. Activity Predecessor A – B – C A D A E B F B G A, C H A, B, D, E 1 B, F J C, D, E, F, G, H, I

12. Use Figure 6.5 (a) and (b) to draw Gantt charts for the ROSEBUD project.

13. Some projects have a fixed due date while others have to be finished as early as possible and the project manager only makes commitments on the completion date once she and her project management team have scheduled the project. Explain how the backward pass differs for these two project types.

14. Explain how it is possible that there can be slack on the critical path. What is the implication of negative slack on the critical path?

15. In the development of a new (first of its kind) complex system, the design of a certain subsystem has large slack. Sufficient resources are available for either an early start or a late start. Discuss the pros and cons of early and late starts. Consider the risk of delaying the project, the risk of changes in the design, management focus, cash flow, and any other factor that you can think of.6

16. What limitations of simple AON networks does PDM overcome? What limitations does it not overcome?

17. Give examples of applications of PDM. Take a project you are familiar with (or invent one) and create a PDM network.

18. For the PDM network in Figure 6.20, calculate ES, EF, LS, and LF for all activities.

19. To produce a manual, John has to write the text, after which Ann has to draw sketches and typeset the document. John can start with any section of the book (i.e., he does not have to start with Section 1). The work has to be done within 95 days. The network diagram below shows the precedence relationships and duration of each activity.

Draw a Gantt chart to show how the work can be done within 95 days. Take into account that both John and Ann are able to attend to only one task at a time.7

20. Why is leveling of resources preferred to large fluctuation of workload? What negative result could resource leveling cause?

21. Describe how resource leveling of a resource-constrained project differs from resource leveling in a time-constrained project.

22. The requirements for systems analysts and programmers for the GUMBY project are as follows:

a. Compute ESs, LSs, and total slack times. b. Then show the separate resource loadings for systems analysts

and programmers, assuming early start times. c. Suppose the maximum weekly availability is eight systems

analysts and five programmers. Can activities be scheduled to satisfy these constraints without delaying the project?

23. Level the resources for a project with the workload diagram below. In

the time-phased diagram at the top of the figure, dotted lines indicate slack.8 Discuss pros and cons of the alternatives available.

24. Discuss the implications of resource allocation for organizations involved in multiple projects.

25. Show that the schedule in Figure 6.23 (that produced an erratic loading for workers) yields a more balanced loading for equipment than the one shown in Figure 6.27.

26. Suppose in Figure 6.20 everything is the same except Activity Y can start 4 days after Activity V starts, but cannot be finished until 6 days after Activity V is finished. Show how this changes the values for ES, EF, LS, and LF.

27. For each of the following predecessor tables:

• Draw a corresponding AON network.

• Compute ES and EF for each activity. • Compute LS and LF for each activity. Find the critical path. • Determine the total slack and free slack.

a. Activity Predecessor Duration A 6 B 3 C A 9 D B 5 E B 4 F D 2 G E 8

b. Activity Predecessor Duration A 3 B A 8 C B 9 D C 3 E B 2 F E, H 4 G A 6 H G 5 J D, F 1

c. Activity Predecessor Duration A 9 B A 2 C 8 D C 8 E B, D 7 F E 4 G C 4 H B, D, G 3

J 6 K J 10 M G, K 3 N H, M 6

d. Activity Predecessor Duration A 10 B A, E 9 C B, N 15 D C 7 E 5 F A, E 6 G K, F 7 H G 12 J 12 K E, J 4 L K, F 11 M L 8 N E, J 7

Questions About the Study Project

1. Were networks used for scheduling? If so, describe the networks. Show examples. What kind of computer software system was used to create and maintain them? Who was responsible for system inputs and system operations? Describe the capabilities of the software system.

2. At what point in the project were networks created? When were they updated?

3. Was scheduling software used? 4. What was used first to develop the schedule: (a) a table such as Table 6.3,

(b) a network diagram, or was (c) the Gantt chart drawn first? Comment on the method used.

5. Was all detail planning done upfront or was a phased approach followed?

6. How was the schedule reserve determined and included in the schedule? 7. Was the workload on resources made visible? 8. If the project was done within a matrix structure, how did

communication between the functional and project managers take place? 9. Did the functional manger(s) take responsibility for workload on

resources? 10. Was resource leveling done? 11. Were there any complaints about unrealistic workloads?

Case 6.19 Network Diagram for a Large Construction Project

The table below lists activities for constructing a bridge over an operational railway line, similar to the bridge described in Case 10.3.

Activity Duration

No. Activity Description (Months) Predecessors

A Detailed site investigation and survey 2 - B Detailed planning 6 A C Detailed design 6 B D Preparation of site 4 C E Relocate services 3 C F Re-align overhead track electrification 4 C, E G Access road and ramp construction 1 D H Piling 2 G J Construct foundations and abutments 3 H

K Construct temporary supports to support bridge deck during construction

2 F, G

L Fabrication planning of structural steel components

2 C

M Manufacture structural steel components (off-site)

2 L

N Transport structural steel components and erect on-site

1 M

P Erect pylons and fill with concrete 2 J

Q Construct main span deck on pre-cast concrete beams

3 H, K, N, P

R Install stay-cables and lift the bridge

deck off temporary supports 3 Q

S Remove temporary supports 1 R T Electrical system installation 1 S U Roadway surfacing (paving) 2 S V Finishing and ancillaries 2 T, U W Commissioning – cut-over 1 V X Formal hand-over and ceremony 1 W Y Project sign-off 1 X Z Administrative closure 1 W

AA Project End 0 (milestone)

Y, Z

(milestone)

1. Construct a network diagram for the project. 2. Do forward and backward pass calculations to indicate early and late

start and finish times. 3. Indicate the critical path. 4. Indicate the total and free slack of each activity. 5. The following resources are required to perform the activities.

Allocate the resources to the activities and indicate the workload on the resources. If needed, adjust the schedule.

Activity No. Activity Description Resources

A Detailed site investigation and survey

Surveyors, Engineering, Project Manager

B Detailed planning Project Manager,

Engineering, Construction, Contractors

C Detailed design Engineering D Preparation of site Construction E Relocate services Engineering

F Re-align overhead track electrification

Engineering, Contractors

G Access road and ramp construction Construction H Piling Construction, Contractors

J Construct foundations and abutments

Engineering, Construction

K Construct temporary supports to

support bridge deck during construction

Engineering, Construction

L Fabrication planning of structural steel components

Engineering, Manufacturer

M Manufacture structural steel components (off-site)

Engineering, Manufacturer

N Transport structural steel components and erect on-site

Transporter, Engineering

P Erect pylons and fill with concrete Construction, Engineering

Q Construct main span deck on pre- cast concrete beams

Construction, Engineering

R Install stay-cables and lift the bridge deck off temporary supports

Construction, Engineering

S Remove temporary supports Construction, Engineering T Electrical system installation Construction, Engineering U Roadway surfacing (paving) Contractor, Engineering V Finishing and ancillaries Contractors, Engineering

w Commissioning - cut-over Project Manager,

Engineering, Construction, Contractors

X Formal hand-over and ceremony Project Manager,

Engineering, Construction, Contractors

Y Project sign-off Project Manager, Engineering

Z Administrative closure Engineering AA Project End Project Manager

Case 6.2 Melbourne Construction Company, A

Bill Asher, scheduler for Melbourne Construction Company, has created a network of activities for a hotel project the company is planning. Figure 6.34 shows part of the network and the number of days Bill estimated for each activity. What are the early and late start and finish times for all the activities? What is the earliest this portion of the project will be completed?

Figure 6.34 Partial network for hotel construction project.

Project schedulers are often faced with incorporating constraints that originate outside the project. For example, materials might not arrive or a contractor might not be ready until a particular date, which imposes a constraint on when the work can start—a Start No Earlier Than (SNET) date. At other times a customer, inspector, or someone else will require the work to be completed by a particular date—a Finish No Later Than (FNLT) date. Bill faces such a situation. He has been informed that drywall boards will not arrive at the site until Day 15, i.e., Drywall has a SNET date of 15. What effect will this delay have on the project?

Additionally, the owner of Melbourne Construction, Naomi Watts, wants to give the hotel owner a tour of the building, but not before all the walls have been primed. She has scheduled the tour on Day 29, which imposes a FNLT of Day 28 on Primer. Bill is now faced with this requirement plus the drywall delivery constraint. Is it possible to finish this portion of the project

on Day 28? If not, what adjustments must be made to the work so they can be? Bill is meeting with Naomi to discuss the situation.

Case 6.3 Melbourne Construction Company, B

One way to speed up a project is to speed up activities on the critical path (discussed in Chapter 7); another is to overlap activities. Refer to Case 6.2, Melbourne Construction Company, A: the network diagram in Figure 6.34 assumes finish-to-start relationships (or FS, meaning successors start only upon completion of predecessors) for the activities for one floor of the hotel. But each floor is large enough so that the crew for an activity can begin when the crew for its predecessor activities are only partially completed (this is called a start-to-start or SS relationship, meaning the start of an activity lags the start of its predecessors by some specified amount). In other words, activities in sequence can be overlapped. Ordinarily, an SS lag is used when successor activities are slower than immediate predecessor activities (so successors won’t “catch up” with predecessors and have to wait on them). This is the case for the Plumbing and Wiring activities that succeed Frame in, so Bill assigns an SS lag of 3 days between Frame in and Plumbing and Wiring (meaning Plumbing and Wiring can start 3 days after Frame in starts); he does the same for Cable, Phone, and Sound. It is also the case for Drywall installation, which is slower than its immediate predecessors, so Bill assigns an SS lag of 4 days between Drywall installation and its predecessors. This is shown in Figure 6.35.

See Chapter 7

Figure 6.35 Network with lags inserted.

When activities are to be overlapped but successors are faster than predecessor activities, a finish-to-finish (FF) lag can be used. Primer is faster than Drywall, so Bill inserts an FF lag of 3 days between them (i.e., Primer should finish no earlier than 3 days before Drywall finishes). This is also shown in Figure 6.35.

1. Compare the Gantt chart using the original FS relationship with the Gantt chart using the SS and FF lags. By how much do the lags speed up the project? Cable, Phone, and Sound take less time than Frame in; what potential problem might occur in overlapping them with Frame in?

2. Refer to Case 6.2, Melbourne Construction Company, A. Given that drywall board delivery will not happen until Day 15 and Naomi has scheduled a tour for Day 29, what is the effect of the SS and FF lags? Can Naomi conduct her tour as planned?

Case 6.4 Melbourne Construction Company, C

Bill Asher, scheduler for Melbourne Construction Company, has created a network of the activities for a three-story boutique hotel the company is planning to build on the Mornington Peninsula. Bill identified seven major activities for each floor. Figure 6.36 shows the network of activities for the three floors and the number of days he estimated for each activity. Each activity will be done by a different subcontractor; as shown in the network, upon completing work on one floor, the subcon-tractor moves to the next floor.

1. What is the critical path? Based on Bill’s estimates, how long will it take to complete the three floors?

2. The activity times shown in Figure 6.36 are based on Bill’s estimates of total labor hours per activity and an 8-hour work day. For example, Bill estimated that Frame in will require 40 labor hours; given an 8-hour day, he came up with 5 days. Thus, all the times in Figure 6.36 assume that subcontractors assign a “crew” of one worker to each activity. According to these time estimates, it should take 54 days to complete each floor. His boss, Naomi Watts, says that 54 days per floor is too long, and that to complete the project on time each floor should take no more than 35 days.

Figure 6.36 Network for three floors.

Looking at the seven activities per floor, Bill sees that the 35 days per floor could be achieved if each activity took no more than 5 days. He intends to point this out to his subcontractors.

a. Bill’s estimates assume one worker per activity. How many workers (what crew size) should the contractors assign to each activity such that each will take at most 5 days?

b. Given the increased crew sizes, how long will it take to complete the project? Assume that a computed fractional day’s duration is always rounded up.

Endnotes

1. Duncan W.R. (ed.). A Guide to the Project Management Body of Knowledge. Newton Square, PA: Project

Management Institute Standards Committee; 1996. The definition of the critical path in later editions of

this document does not say that the critical path can change; that does not alter the fact that it does.

2. For more about PDM scheduling, see Dreger J.B. Project Management: Effective Scheduling. New York,

NY: Van Nostrand Reinhold; 1992.

3. Goldratt E.M. Critical Chain. Great Barrington, MA: North River Press; 1997.

4. Loops are permitted in a special form of network analysis called GERT.

5. Adapted from Gordon G.D. and Villoria R.L. Network-based Management Systems (PERT/CPM). New

York, NY: John Wiley & Sons; 1967.

6. Steyn H. (ed.). Project Management: A Multi-disciplinary Approach. Pretoria: FPM Publishing; 2003.

Reproduced with permission.

7. Ibid.

8. Ibid.

9. Ibid.

Chapter 7 Advanced Project Network Analysis and Scheduling

Look beneath the surface: never let a thing’s intrinsic qualities or worth escape you

—Marcus Aurelius, Meditations

The scheduling methods discussed in Chapter 6 assume that activity times are known and fixed, even though in reality they are estimated and variable. This chapter discusses the implications of variable activity times on project schedules and the methods for handling uncertainty in project completion dates, namely PERT and Critical Chain. It also covers methods for reducing the project duration, starting with CPM.

7.1 CPM and Time–Cost Tradeoff

The critical path method (CPM) is a way to reduce project duration by allocating resources among activities for the least cost. Developed in 1957 by DuPont Company, Remington Rand, and Mauchy Associates for DuPont plant construction, it is a mathematical procedure for estimating the tradeoff between project duration and project cost.1

Example 7.1: The House Built in Less Than 4 Hours2

With virtually unlimited resources and meticulous planning and control, a project can be done very fast. On March 13, 1999 the Manukau, New Zealand Chapter of Habitat for Humanity (a nonprofit organization dedicated to eliminating poverty housing) set a record for building a house: 3 hours and 45 minutes.

The project specifications included construction of a four-bedroom house on an established foundation (Figure 7.1). It incorporated prefabricated wall panels, wooden floor, roofing iron, ceilings, decks, and steps. Doors, windows, bath, toilet, plumbing, and the electrical system had to be installed and ready for use; walls, ceilings and window frames had to be painted; and carpets and curtains had to be installed. The specifications also included a path to the front door, letter box, installed clothes line, wooden fence around the yard, three trees planted, and a leveled lawn with grass. The new owners, Mr. and Mrs. Suafoa, watched the construction with their four children while CNN filmed the event. The house was inspected, passed all local building codes, and the keys were handed over to the family.

Figure 7.1 The house built in less than 4 hours.

Photo courtesy of Habitat for Humanity.

What made the speedy completion possible? First were abundant resources: 150 people, mostly volunteers. Second was comprehensive and meticulous preparation: 14 months of planning, including many iterations of network analysis. The detailed plan was recorded on special task sheets so team leaders could hand over tasks from one to another without deliberation. With so many people and construction items at the site, workspace was at a premium. A crane was provided to lift the wooden roof frame onto the wall structure. Third was a systematic computerized method for planning, monitoring, and controlling the project that included the critical chain method and time buffers (explained later). The bathroom- fitting task was estimated to take 30 minutes, but took 1 hour; the 30-minute overrun was absorbed in the project buffer. Finally, the project made use of suitable technology, including prefabricated walls and components.

Time–Cost Relationship

CPM assumes that the time to perform a project activity varies depending on the amount of resources applied; as more resources (labor, equipment, etc.) are applied to particular activities, the project duration is shortened. Adding resources speeds up the project, but it also increases the project cost. A major element of project cost is labor: a project can be sped up by adding more labor or working overtime, but either way the cost goes up.

Ordinarily, work on any given activity in a project is performed at a normal (usual and customary) work pace. This is the “normal” point shown in Figure 7.2. Associated with this pace is the normal time, Tn, which is the time the activity will take under normal work conditions, and the normal cost, Cn, which is the cost of doing the activity in the normal time. (The normal pace is assumed to be the most efficient and thus least costly pace. Extending the time beyond the normal pace will not produce additional savings.)

Figure 7.2 Time–cost relationship for an activity.

To reduce the time to complete the activity, more resources are applied in the form of additional personnel or overtime. As more resources are applied, the duration shortens but the cost increases. When the maximum effort is applied so that the activity can be completed in the shortest possible time, the activity is said to be crashed. The crash condition (see Figure 7.2) represents not only the shortest duration, but the most costly as well. (For some activities, called process limited, there is no time–cost tradeoff since they require a specific time that remains constant regardless of resources. Fermenting wine or curing concrete are examples.)

As illustrated in Figure 7.2, the points for completing an activity under normal conditions and crash conditions define two theoretical extremes. The line connecting the points, called the cost slope, represents the time–cost relationship or marginal time–cost tradeoff for the activity. The time–cost line for every activity is unique and can be linear, curvilinear (concave or convex), or a step function. The nature of the actual time–cost relationship is usually unknown; thus often it is assumed to be linear,3 in which case the formula for the cost slope is

where Cc and Cn are the crash and normal costs, respectively, and Tc and Tn are the crash and normal times for the activity. The cost slope is how much it would cost to speed up or slow down the activity.

Using the formula, the cost slope for the activity in Figure 7.2 is $3K per week. Thus, for each week the activity duration is reduced from the normal time of 8 weeks, the cost will increase by $3K. Completing the activity 1 week earlier (from 8 weeks to 7 weeks) would alter the cost from the normal cost of $9K to the “sped up” cost of $9K + $3K = $12K; completing it another week sooner (in 6 weeks) would increase the cost to $12K + $3K = $15K; completing it yet another week sooner (in 5 weeks) would increase the cost to $18K. According to Figure 7.2, this last step puts the activity at the crash point, the shortest duration for the activity.

Reducing Project Duration: Shorten the Critical Path

The cost-slope concept can be used to determine the least costly way to shorten a project. Figure 7.3 illustrates this with an example. Start with the preliminary project schedule by assuming a normal pace for all activities; therefore, the project in the figure can be completed in 22 weeks at an expense of $55K. Suppose we want to shorten the project duration. Recall from Chapter 6 that the project duration is the length of the critical path. In general, to shorten the project, the critical path must be shortened. Because the critical path A–D–G is the longest path (22 weeks), to shorten the project it is necessary to shorten a critical activity —either A, D, or G. Reducing an activity increases its cost, but because the reduction can be made anywhere on the critical path, the increase is minimized by selecting the activity with the smallest cost slope, which is Activity A. Reducing A by 1 week shortens the project duration to 21 weeks and adds $2K (the cost slope of A) to the project cost, bringing it to $55K + $2K = $57K. This step does not change the critical path so, if need be, an additional week can be cut from A to reduce the project duration to 20 weeks for a cost of $57K + $2K = $59K.

See Chapter 6

In general, each time an activity is shortened, it is necessary to check for any changes in the critical path. For example, as the top network in Figure 7.4 shows, shortening A uses up all of the slack on Path B–E and the project now has two critical paths: A–D–G and B–E–G. Any further reduction in project duration must be made by shortening both paths because shortening just one would leave the other at 20 weeks. The least costly way to reduce the project to 19 weeks is to reduce both A and E by 1 week, as shown in Figure 7.4(b). The additional cost is $2K for A and $2K for E, so the resulting project cost would increase to $59K + $2K + $2K = $63K. This last step reduces A to 6 weeks, its crash time, so no further reductions can be made to A.

If a further reduction in project duration is desired, the least costly way to shorten both paths is to reduce G. In fact, because the slack on the noncritical path C–F is 3 weeks, and because the crash duration for G is 2 weeks (which

means, if desired, 3 weeks can be taken out of G), the project can be reduced to 16 weeks by shortening G by 3 weeks as indicated in Figure 7.4(c). This adds $5K per week, or 3 × $5K = $15K, to the project cost. With this last step, all slack is used up on Path C–F, and all the paths in the network (A–C–F, A–D–G, and B–E–G) become critical.

Any further reductions desired in the project must shorten all three critical paths (A–C–F, A–D–G, and B–E–G). As you may wish to verify, the most economical way to reduce the project to 15 weeks is to cut 1 week each from E, D, and C, bringing the project cost up to $86K. This step reduces the time of C to its crash time, the shortest possible project duration. The sequence of steps is summarized in Table 7.1.

Figure 7.3 Time–cost tradeoff for example network.

Figure 7.4 Reducing project duration.

Table 7.1 Duration Reduction and Associated Cost Increase

Step Duration (Te,weeks) Activities on CP with Least Cost

Slope Cost of Project

(K$)

1* 22 $55

2 21 A ($2) $55 + $2 = $57 3 20 A ($2) $57 + $2 = $59 4 19 A ($2), E ($2) $59 + $2 + $2 = $63

5, 6, 7

18, 17, 16 G ($5) $63 + $5 + $5 + $5 = $78

$78 + $2 + $5 + $1 =

8 15 E ($2), D ($5), C ($1) $86

* duration and cost using normal conditions

Crashing the Project: Shortest Project Duration

The time–cost procedure described determines which activities to speed up, step- by-step, so as to reduce the project duration. This stepwise procedure will eventually lead to the shortest project duration and its associated cost. However, if we want to directly find the shortest project duration and avoid the intermediate steps, a simpler procedure is to simultaneously crash all activities at once. This, as Figure 7.5 shows, also yields the project duration of 15 weeks. However, the expense of crashing all activities, $104K (table in Figure 7.3) is artificially high because, as will be shown, not all activities need to be crashed to finish the project in the shortest time.

The project duration of 15 weeks is the time along the critical path. Because the critical path is the longest path, other (noncritical) paths are of shorter duration and, consequently, have no influence on project duration. Thus, it is possible to “stretch” or increase any noncritical activity by a certain amount without lengthening the project. In fact, the noncritical activities can be stretched until all the slack in the network is used up.

Figure 7.5 Example network using crash times.

Just as reducing an activity’s time from the normal time increases its cost, so extending its time from the crash time reduces its cost. As a result, by extending noncritical activities the $104K project crash cost can be reduced. To do so, start with those noncritical activities that will yield the greatest savings—those with the greatest cost slope. Notice in Figure 7.5(a) that because Path B–E–G has a slack of 5 weeks, activities along this path can be stretched by up to 5 weeks without extending the project. Three weeks can be added to Activity B (bringing it to the normal duration of 8 weeks) without lengthening the project. Also, 2 weeks can be added to E and 1 week to D, both without changing the project duration.The final project cost is computed by subtracting the savings obtained in extending B by 3 weeks, E by 2 weeks, and D by 1 week from the initial crash

cost.

$104K—3($3K)—2($2K)—1($5K) = $86K

In general, to obtain the shortest project duration (called “crashing the project”), first crash all activities, then extend the noncritical activities with the greatest cost slopes to use up available slack and obtain the greatest cost savings. An activity can be extended up to its normal duration, which is assumed to be its least-costly time (Figure 7.2).

Total Project Cost

The previous analysis dealt only with direct costs—costs immediately associated with individual activities that increase directly as resources are added to them. But beyond direct costs, the cost of conducting a project also includes indirect costs such as administrative and overhead charges. (The distinction between direct and indirect cost is elaborated in the next chapter.) Usually indirect costs are a function of, and are proportionate to, the duration of the project. In other words, indirect costs, in contrast to direct costs, decrease as the project duration decreases.

The mathematical function for indirect cost can be derived by estimation. As an illustration, suppose indirect costs in the previous example are approximated by the formula

Indirect cost = $10K + $3K(Te)

where Te is the expected project duration in weeks. Figure 7.6 shows this on the indirect cost line. It also shows the total project cost, which is the sum of direct and indirect costs. Notice from the figure that by combining direct costs and indirect costs it is possible to determine the project duration that gives the lowest total project cost. As Figure 7.6 shows, from a cost standpoint, 20 weeks is the “optimum” project duration.

In addition to direct and indirect costs, other costs that influence total project cost (and hence the optimum Te) are contractual incentives such as penalty charges or bonus payments. As described in the Appendix to

Chapter 3, a penalty charge is a fee imposed on the contractor for not completing a project deliverable on time, and a bonus payment is a reward or cash inducement for completing it early.

See Appendix, Chapter 3

Suppose in the previous example the contract specified a target completetion by Week 18, with a bonus of $2K per week for finishing before 18 weeks and a penalty of $1K per week for finishing after 18 weeks. Figure 7.7 shows the influence of these incentives on total project cost. Notice that even with incentives, the optimum duration (for the contractor) is at 19 or 20 weeks, not the contractual 18 weeks. This example reveals that a formal incentive agreement alone is not necessarily enough to influence performance. For the incentive to motivate the contractor it must have “teeth”; i.e., it must be of sufficient magnitude with respect to other project costs to affect contractor performance. Had the penalty been raised to $3K (instead of $1K) per week for finishing after 18 weeks, the contractor’s optimum duration would have shifted to 16 weeks.

7.2 Variability of Activity Duration

Suppose you are driving to somewhere, and Figure 7.8 shows the the estimated time duration it will take you to get there. If everything goes well (no traffic or mechanical problems) you will get there in the shortest time—the “Optimistic Duration.” Most likely, however, it will take you longer than that—the “Most Likely Duration” of 30 minutes. Of course, it could take longer than this—say, when traffic is

Figure 7.6 Total time–cost tradeoff for the project.

Figure 7.7 Time–cost tradeoff for the project with incentives.

congested or, worse, you get in an accident. Note in the figure that the area below the curve to the left of the Most Likely Duration is much less than to the right of it. This indicates that the chances of arriving later than the Most Likely time are greater than the chances of arriving earlier.

Figure 7.8 Variability of activity duration.

Like your travel time, the activity durations in a project are variable. The question is, since you cannot say for sure how long each activity will take, how can you possibly say when the project will be completed?

The scheduling approaches discussed in Chapter 6 and the preceding section on time–cost tradeoff ignore variability and assume that activity durations are constant; this is called the deterministic approach. In the following sections we consider what happens when the activity durations are assumed variable; this is called the stochastic approach.

See Chapter 6

Variability Effects on a Project Network

Figure 7.8 relates to a single activity. In a project some activities will be completed earlier than expected, others later. When activities are combined in a network, however, the early activities and late activities do not average out: in

general, it is only the late activities that impact the project completion. This is one reason why projects tend to take longer than estimated.

Consider for example Activity A in Figure 7.9. If Activity A takes longer than planned, it would delay Activity B, which in turn would delay Activities C and D and, thus, the completion of the project. Suppose however that Activity A is finished earlier than planned. In that case will Activity B start earlier? Not necessarily. Resources needed for Activity B (people and equipment) will likely have other commitments, which would preclude Activity B starting before the scheduled start date.

Consider a second example. Most project networks consist of several paths that merge together into a critical path. Figure 7.10(a) illustrates a project with two critical paths, each with a 50 percent chance of finishing on time. The probability that the project will finish on time is the probability that both paths will finish on time, or 0.5 × 0.5 = 0.25 or 25 percent. Figure 7.10(b) shows five paths merging (which is typical of what happens near the end of project networks), each with a 50 percent probability of finishing on time. The probability of finishing the project on time is now (0.5)5 or about 3 percent. This effect is called merge bias or merge-point bias.

Figure 7.9 Activities delayed if Activity A is delayed.

Figure 7.10 Activities delayed where paths merge. (a) Two paths merging, each with 50 percent chance of

being on time; (b) Five paths merging, each with 50 percent chance of being on time.

Chapter 6 addressed the fact that the critical path is not necessarily stable but can change if noncritical activities take longer than planned or if critical activities take less time than planned. Either case can result in the project being delayed.

See Chapter 6

Several methods have been developed to help grapple with the uncertainty about when a project will be completed. These are addressed in the following sections, starting with PERT.

7.3 Pert

The PERT method was developed for application in projects with uncertain activity durations. It originated during the US Navy’s Polaris Missile System program, an example of a complex research and development program with much uncertainty regarding the kind of research to be done, the stages of development needed, and how fast they can be completed. Projects like this are defined at the same time while technological developments are unfolding and before many of the problems in technology, materials, and processes have been identified. The project duration is uncertain and there is great risk that it will overrun the target completion time.

To provide greater certainty in estimating the duration of the Polaris program, an operations research team was formed in 1958 with representatives from the Navy’s Special Projects Office, the consulting firm of Booz, Allen, and Hamilton, and the prime contractor Lockheed Missile Systems. They devised a method called PERT (Program Evaluation and Review Technique) that would provide insight into the likelihood of finishing a project by a certain time.4 PERT is a tool not for scheduling, per se, but for analyzing the project network (and the schedules resulting from the network).

Three Time Estimates

The network methods discussed in Chapter 6 determine the critical path and slack times using best estimates for activity duration. PERT, however, addresses uncertainty in the durations by using three time estimates for activity duration —optimistic, most likely, and pessimistic. Presumably the estimates are obtained from the people most knowledgeable about difficulties likely to be encountered and the potential variability in time; usually they are expert estimators or the people who will perform or manage the activity.

See Chapter 6

The three estimates are used to calculate the expected time for an activity. The range between the optimistic and pessimistic estimates is a measure of variability that permits making statistical inferences about the likelihood that project events will happen by a particular time.

As seen in Figure 7.11 the optimistic time, a, is the minimum time for an activity—the situation where everything goes well and there is little hope of finishing earlier. A normal level of effort is assumed with no extra personnel. The most likely time, m, is the time that would occur most often if the activity were repeated. Finally, the pessimistic time, b, is the longest time for the activity—the situation where bad luck is encountered at every step; it includes only likely problems in work and not highly unlikely events such as natural disasters.

The three estimates in Figure 7.11 are related in the form of a Beta probability distribution with parameters a and b as the end points and m, the most frequent value. The Beta distribution is used because it is unimodal (has a single peak value) and is not necessarily symmetrical—properties that seem desirable for a distribution of activity durations. Note that whereas the distribution in Figure 7.8 had no end point on the right-hand side, the curve in Figure 7.11 precludes very unlikely events and has end point b.

Figure 7.11 Estimating activity duration.

Based on this distribution and the three time estimates, the mean or expected time, te, and the variance, V, of each activity are computed with the following formulas:

Since V = σ2, where σ = standard deviation,

σ = (b – a) /6

The expected time, te, represents the point on the distribution in Figure 7.11 with a 50-50 chance that the activity will be completed earlier or later than te. In the figure

The variance, V, is a measure of variability in the activity duration:

The larger V, the less reliable te, and the higher the likelihood the activity will be completed much earlier or much later than te. This simply reflects that the farther apart a and b, the more dispersed the distribution and the greater the chance that the actual time will significantly differ from the expected time. In a routine (repetitive) job, estimates of a and b are close to each other, V is small, and teis more likely.

Probability of Finishing by a Target Completion Date

The expected time, te, is used in the same way as the estimated activity duration was used in the deterministic networks in Chapter 6. Because statistically the expected time of a sequence of independent activities is the sum of their individual expected times, the expected duration of the project, Te, is the sum of the expected activity durations along the critical path; that is

where each te is the expected time of an activity on the critical path. PERT is a stochastic approach; hence the project duration is not considered a

point but rather an estimate subject to uncertainty owing to the uncertainties of

the activity durations along the critical path. Because the project duration Te is computed as the sum of expected activity durations, it follows that Te is also an expected time. The project duration can be thought of as a probability distribution with an average of Te. Thus the probability of completing the project before Te is 50 percent, and so is the probability of completing it after Te.

The variation in the project duration distribution is computed as the sum of the variances of the activity durations along the critical path:

where V is the variance of an activity on the critical path. These concepts are illustrated in the AOA network in Figure 7.12.

Figure 7.12 PERT network with expected activity durations and activity variances.

The distribution of project durations is assumed to be the normal, familiar bell- shaped curve. Given this assumption, it is easy to determine the probability of

meeting any specified project target completion date Ts. As examples, consider two questions about the project shown in Figure 7.12:

(1) What is the probability of completing the project in 27 days? (2) If we want to be 95 percent sure about committing to project duration, what duration should we quote? To answer these questions, we invoke the assumption that the distribution of project duration is a standard normal distribution, and we begin by determining the number of standard deviations, z, that separate Ts from the expected project duration, Te. The formula for the calculation is:

To answer question 1, use Ts = 27 days. From the network, the expected project duration, Te, is computed as 29 days. Therefore

The probability of completing the project within 27 days is equal to the area under the normal curve to the left of z = –0.82. Referring to Table 7.2(a), the probability is about 21 percent.

To answer question 2 (duration with a 95 percent certainty): using Table 7.2(b), for a probability of 0.95 the z value is 1.6. As before, we calculate

Table 7.2 Normal Distribution Function for Completing a Project by Time Ts

[a] Probability that project will be completed sooner than the expected duration (project will probably finish

late if committed to the Ts date) duration.

Z Value Probability Z Value Probability 0 .50 −1.2 .12

−0.1 .46 −1.3 .10 −0.2 .42 −1.4 .08 −0.3 .38 −1.5 .07 −0.4 .34 −1.6 .05 −0.5 .31 −1.7 .04 −0.6 .27 −1.8 .04 −0.7 .24 −1.9 .03 −0.8 .21 −2.0 .02 −0.9 .18 −2.1 .02 −1.0 .16 −2.2 .01 −1.1 .14 −2.3 .01

[b] Probability that project will be completed later than the expected duration (project will probably finish early if committed to the Ts date).

Z Value Probability Z Value Probability 0.0 .50 1.2 .88 0.1 .54 1.3 .90 0.2 .58 1.4 .92 0.3 .61 1.5 .93 0.4 .66 1.6 .95 0.5 .69 1.7 .96 0.6 .72 1.8 .96 0.7 .76 1.9 .97 0.8 .79 2.0 .98

0.9 .82 2.1 .98 1.0 .83 2.2 .99 1.1 .86 2.3 .99

In other words, it is “highly likely” (95 percent probable) that the project will be completed within 33 days. Note that since we are working with values that are merely estimates, it does not make sense to compute figures of great precision.

Near-Critical Paths

The PERT procedure has been criticized for providing overly optimistic results, a justifiable criticism since it does not account for the effect of merge-point bias. For example, Figure 7.12 has two paths that are “near critical” in length. The variance of these paths is large enough that either could easily become critical by exceeding the 29 days of the original critical path. In fact, as you may wish to verify using the statistical procedure described previously, the probability of not completing Path (a) (A–F–J) and Path (e) (D–E–H–I–K) within 29 days is 34 percent and 29 percent, respectively. So there is more than a slight chance that these paths could become critical. The warning is: don’t overemphasize the critical path and ignore the near-critical paths—paths that could themselves become critical and jeopardize the project completion date.

Furthermore, the 50 percent probability of completing the project within 29 days, as presumed with the normal distribution, is overly optimistic. Because all activities in the network must be completed before the project is completed, the probability of completing the project within 29 days is the same as the probability of completing all five paths within 29 days. Although the probability of completing Paths (b) and (d) within 29 days is close to 100 percent, the probabilities of completing Paths (a) and (e) within that time is 66 percent and 71 percent, respectively, and the probability of completing (c), the critical path, is 50 percent. So the chance of completing all paths within 29 days is the product of the probabilities 1.0 × 1.0 × 0.66 × 0.71 × 0.5, or less than 25 percent.

Meeting the Target Date

Clearly, one way to increase confidence in meeting a target date is to delay it, but when the target date cannot be delayed the alternative is to revise the project network and shorten the critical and near-critical paths. Possible ways to do this include:5

1. Look for opportunities to fast-track (overlap) activities on the critical path, which implies scheduling an activity to start before its predecessors are completed. An alternative is to split the predecessors into sub-activities, and start the successor when only some of the predecessor sub-activities have been completed.

2. Add resources to critical and near-critical activities by transferring resources from activities with large slack times.

3. Substitute time-consuming activities with ones that are less so, or delete activities that are not absolutely necessary.

Each of these has drawbacks. Fast-tracking increases the risks of making mistakes and having to repeat activities. Adding resources to speed up activities increases the cost, and transferring them between activities requires changing plans and schedules, increases administrative costs, and aggravates the functional managers who supply the resources. The final alternative, substitution or elimination of activities, jeopardizes project performance, especially when it equates to making “cuts” or using poorer quality materials or less-skilled labor.

Criticisms of PERT6

The PERT method has been criticized for its shortcomings. For example, it ignores human behavior and presumes that an activity will start as soon as its predecessor activities are completed—ignoring that resources might not be available or that people procrastinate. Also, it assumes that activity durations are independent, though often they are not. Whenever resources are transferred from one activity to another, then the durations of both activities are changed.

PERT also assumes that three activity estimates are better than one. Unless based upon good historical data, however, the three estimates are still guesses, which might not improve over a single “best” guess. An advantage of the

pessimistic estimate, however, is that it allows for the possibility of setbacks, which a single estimate cannot.

Accuracy of estimates often depends on experience. Whenever a database can be formed based upon experience from similar activities from previous projects, a “history” can be developed for each kind of activity that can be used to estimate the durations for future similar activities. In fact, reliance on good historical data for estimating times makes the PERT method more appropriate for projects that are somewhat “repeatable” and less so for the first-of-a-kind projects. Because of this the PERT method tends to be used in construction and standardized engineering projects, but seldom elsewhere.

Some of PERT’s shortcomings are addressed by simulation.

Monte Carlo Simulation of a PERT Network

Monte Carlo computer simulation is a procedure that takes into account the effects of near-critical paths and merge-point bias. The critical path is computed from activity durations that are randomly selected from probability distributions. The procedure is repeated thousands of times to generate a distribution of project durations. It gives an “expected time” and standard deviation for the project duration that is more reliable and accurate than simple PERT computations; it also gives the probabilities of other paths becoming critical.7

Simulation allows the use of a variety of probability distributions besides Beta, including distributions based upon empirical data. As a result, the generated project durations more accurately represent the range of expected durations than the single-network PERT method.

Simulation can also avoid some limitations of PERT assumptions, such as independence of activity durations and normality of the project duration distribution. The following example from Evans and Olson illustrates usage of simulation to assess the likelihood of project completion time.8

Example 7.2: Simulation to Determine Project Duration

Refer to the project activities and time estimates in Table 7.3 and the project network in Figure 7.13.

The critical path is B–F–G–H–I–K–M–O–P–Q; summing te and V on this path gives a project duration of 147.5 days with a variance of 56.63.

Suppose the customer wants the project to be completed within 140 days. Using the PERT method, the probability of completing the project within 140 days is found from

Referring to Table 7.2, the probability is about 16 percent.

Table 7.3 Activities and Time Estimates

Figure 7.13 Project network.

Using the simulation program Crystal Ball to generate the completion times for 1,000 replications of the project yields the distribution in Figure

7.14. (Various other programs such as Risksim, @Risk, Arena, and Simul-8 can also be used.)9

Figure 7.14 Crystal Ball simulation results for project completion times.

The simulation distribution has a mean of 155 days and gives a probability of completing the project in 140 days of about 6.9 percent (the sum of the probabilities to the left of 140 on Figure 7.14). It is thus unlikely that the project will be finished in less than 140 days, and only 50 percent likely that it will be completed within 155 days, which is 7.5 days longer than the PERT estimate of 147.5 days.

Simulation provides more realistic results than PERT because it compensates for noncritical paths that can become critical. But like PERT, it is merely a method for analyzing schedules, not for creating them. It is a “better” analysis tool than PERT but, like PERT, does not eliminate the uncertainty associated with scheduling or specify what to do to reduce project risk; other tools are needed for that, as discussed in Chapter 10.

See Chapter 10

Why Projects are Often Late

The project manager might face considerable risk when committing to a due date based solely on the duration of the critical path. For example, a Monte Carlo simulation was used to calculate the probability of finishing a project given the critical-path activity durations shown in Figure 7.15. The most-likely critical path length is 130 days, but the simulation reveals the chance of finishing the project in that time is only 15 percent. Further, this simulation was applied to the critical path only and did not take into account noncritical paths that might become critical—which would reduce the probability even more. While individual m values might be considered “realistic,” the sum of the m values is not realistic at all! The project manager faces a similar risk when committing to a project cost that is the sum of the most likely activity cost estimates. Many project managers estimate project duration and cost by simply adding up most likely estimates of activity durations and costs—one reason why projects overrun due dates and budgets.

Another reason for overruns is human behavior. During the feasibility or proposal (tendering) stage of the project, champions and supporters work hard to “sell” the project. Everyone is optimistic, which is necessary to gain buy in from stakeholders, but it also leads to underestimating project duration and cost. The Channel Tunnel (“Chunnel”) is an example. Originally it was stated that 30 million people and 100 million tons of freight would be transported through the Chunnel per year, a claim that proved slightly exaggerated since in the first 5 years the actual numbers were 28 million people and 12 million tons of freight. The cost, initially estimated at £7.5 billion, ultimately reached £15 billion. Plus, the project took nearly 18 months longer to complete than originally estimated.

Figure 7.15 Simulation results show low probability of finishing within critical-path time. Generated by

means of Crystal Ball software, assuming triangular distributions.

7.4 Allocating Resources and Multiple Project Scheduling

Organizations in construction, consulting, systems development, and maintenance commonly use a pool of shared equipment and skilled workers from which all projects draw. This also happens in matrix organizations (Chapter 14) where projects share resources from the same functional departments. This section addresses the matter of scheduling multiple projects that share constrained resources.

See Chapter 14

Multiple projects that share resources must be planned and scheduled such that in combination they do not exceed the resources available in the shared pools. Although these projects might in all other ways be considered independent, with regard to their shared resources they are interdependent.

As might be expected, the problem of scheduling multiple concurrent projects is analogous to scheduling multiple concurrent activities within a single project, but with modification to account for the economic, technical, and organizational issues that arise when dealing with multiple projects (see Chapter 18).

See Chapter 18

First, each project has its own target completion date, and all the projects must be scheduled to finish as close to those dates as possible to avoid deferred payments, penalty costs, or lost sales and revenues. Further, when projects are interdependent, delays in one project can have a ripple effect on others; the delay of a satellite development and launch project will cause the subsequent delay of a telecommunications project. In any case, scheduling of multiple projects requires first determining the relative priority among the projects to determine which project should get first dibs on scarce resources.

Because most organizations prefer to maintain a uniform level of personnel

and other resources, the combined schedules for multiple projects ideally results in a uniform loading of those resources. In other words, the resource loading for the combined projects is ideally flat. In theory, projects are scheduled such that as resources are released from one project they are assigned to others. This minimizes costs associated with hiring, layoffs, and idle workers and facilities, and helps maintain worker morale and efficient use of resources.

When many activities or projects are ready to start and all require the same resource, the question is, to which activities or projects should the resource be allocated? When 10 activities are ready to start, the number of possible sequences in performing them is 10, or more than 3.6 million. If n activities are ready to start and all of them require m resources, the number of possible schedules would be (n!)m. Optimization using normal polynomials is usually not feasible (the problem is “NP hard”). Heuristic methods, on the other hand, provide simple and acceptable solutions.

Heuristic Methods for Allocating Resources

A heuristic method is a procedure based upon a simple rule. Heuristic methods for allocating resources to projects often employ priority rules or dispatching rules. While these methods do not produce optimal schedules, they do produce “good enough” schedules for most situations.

Heuristics methods start with early and late times as determined by traditional network methods, and then analyze the schedule for the required resources (i.e., the resource loading). Whenever a resource requirement exceeds the constraint, the heuristic determines which activity gets high priority and receives the resource. The most common heuristic rules for determining scheduling priority are:

a. As soon as possible: activities that can be started sooner are given priority over (or scheduled ahead of) those that can be started later.

b. As late as possible: activities that can be finished later are given lower priority than those that must be finished earlier.

c. Most resources: activities requiring more resources are given priority over those requiring fewer resources.

d. Shortest task time: activities of shorter duration are given priority over those of longer duration (sometimes referred to as shortest activity duration, shortest processing time, or shortest operating time).

e. Least slack: activities with less slack are given priority over those with more slack; critical path activities thus have highest priority. (This rule is also referred to as slack time remaining.)

f. First come first served: activities that arrive earlier or require the resource earlier are given priority.

g. Earliest due date: when a resource is to be allocated to more than one project, the project with the earliest target completion date is given priority. Alternatively, the activity with the earliest next operation is given priority.

All of the priority rules are subordinate to precedence requirements; i.e., no matter the rule, the resulting schedule must not violate predecessor–successor relationships. Most project management software employs some combination of these rules (e.g. using “shortest task time,” then using “as soon as possible” as a tie breaker). Figure 7.16 shows examples of applying the above rules a through e in assigning workers to activities and their impacts on the project schedule given a constraint of ten workers per week maximum.

As Figure 7.16 shows, the rules yield different results, some better than others. In general, with the as late as possible rule, everything occurs at its latest date; the drawback of this is that a delay in any activity will delay the project. In contrast, the least slack rule is good since it reduces the risk of noncritical activities delaying critical ones.

The shortest task time rule is good when multiple projects must be executed at once, since it allows people responsible for succeeding activities to perform them sooner. Figure 7.17 shows what happens when activities are scheduled (a) longest- task first versus (b) shortest-task first. As represented by the area under the bars, the total waiting time in (b) is much less than in (a). The rule says: when you have several things to do, do the shortest ones first.

The typical scheduling goal is to complete the project by the target completion date; sometimes that is not possible, regardless of the priority rule. For example, suppose the target completion date for the project in Figure 7.16 is 9 weeks, the

critical path length. Given the constrained-resource level of ten workers, none of the heuristics in the example meets this target, although one of them (“as late as possible”) results in 10-week completion.

7.5 Theory of Constraints and Critical Chain Method10

The theory of constraints (TOC) is a systems approach to improving the performance of business systems.11 A premise of TOC is that every system has a goal and that often only one element of the system, called the system constraint, limits achieving that goal.

The application of TOC to project scheduling and control is called critical chain project management (CCPM) or the critical chain method (CCM). The constraint for an individual project is its duration or due date, and CCPM aims to reduce that duration and provide a more predictable project completion date.12

CCPM accounts for both the stochastic nature of activity durations and the human behavioral impact on project scheduling and execution. It can be applied to single projects or to multiple concurrent projects.13

Commitment to Due Dates

With traditional methods, people working in each project activity must commit to completing the activity by a target date even though the activity duration is uncertain. There might be penalties for finishing late or rewards for finishing early, but out of fear of finishing late, people responsible for an activity often provide a pessimistic or “padded” time estimate. Although this behavior is quite normal, it results

Figure 7.16 Results of several priority rules on project schedule and completion times.

Figure 7.17 The shortest task time rule reduces waiting time. (a) Longest task first. (b) Shortest task first.

everywhere in inflated estimated activity durations and, hence, longer-duration projects. The CCPM approach to avoiding time padding is simply this: while the project manager obviously needs to commit to a project due date, people responsible for individual project activities are not required to commit to due dates. They are encouraged to work in earnest, but are not held to a target date. In requesting time estimates, everyone is asked to provide the most “realistic” time, meaning the time with a 90 percent chance of it being achieved. This time is then cut in half to obtain an “aggressive” estimate, which eliminates any padding for contingency. (It should be noted, however, that whenever project members provide “aggressive” (not padded) estimates, the manager does not cut them in half.) The realistic and aggressive estimates provide the basis for estimating the amount of “buffer” required to protect the project as a whole against delays.

Project Buffer and Feeding Buffers

To protect against delay, a project buffer (time contingency) is placed at the end of the project. The date at the end of the buffer is the date to which the project manager commits to completing the project. (As mentioned, the project manager commits to a date for the project, but people responsible for individual project activities do not commit to dates; they just try to complete their activities speedily.) But, you might ask, won’t adding a time buffer lengthen the project duration? The answer is no, because the aggressive time estimates used for project activities are 50 percent shorter than the “realistic” but padded estimates. Dividing the realistic estimate by two results in two estimates: one, an aggressive estimate for the duration, the other an estimate of the “padding” that was included in the original, realistic estimate. Summing the padding estimates for all the activities to form the project buffer and putting the buffer at the end of the project will account for any activity delays.

To illustrate, consider the project shown in Table 7.4 and Figure 7.18. The critical path, P–Q–R–Z, is 32 weeks long. Now look at Figure 7.19 where the activity durations have been cut in half. The 16 weeks (4+6+4+2) cut from the critical path P–Q–R–Z becomes the project buffer. Note also in Figure 7.19 the presence of a feeding buffer, which is the number of weeks removed from the

noncritical path S–T, 12 weeks (2+10). In general, CCPM calls for a single project buffer at the end of the critical path as well as a feeding buffer located wherever a noncritical path feeds into the critical path. The feeding buffer protects against delays in noncritical activities.

While project buffers and feeding buffers bear a resemblance to slack, they are not slack. Whereas with traditional methods activities are scheduled as early as possible and slack may be used to delay activities when necessary, in CCPM all activities are planned to start as late as possible, but with buffers. (As discussed later, however, during execution, critical activities are started as soon as possible to take advantage of gains from activities completed early.) The buffers “belong” to the project manager, and only she can allocate time from them; this will happen whenever an activity exceeds its planned duration.

Table 7.4 Activities for Small System Development Project

Activity Description (from WBS)

Activity Code

Duration (Days) Resources

Design Subsystem A P 8 Design Team A

Manufacture Subsystem A Q 12 Technician Test Subsystem A R 8 Test team

Design Subsystem B S 4 Design Team B

Build Subsystem B T 20 Technician Assemble Subsystems A and B Z 4 Technician

Figure 7.18 (a) Networks for activities in Table 7.4; (b) Time-scaled network for activities in Table 7.4.

Figure 7.19 Schedule with contingency reserves allocated to the project manager.

But the size of the project buffer can be substantially less than the sum of the activity paddings that were removed. There are two reasons. First is the mathematical effect—well known in risk management—called aggregation, which says that the uncertainty of finishing a project on time is much less than the sum of the uncertainties of finishing individual tasks within that project on time. Because of the aggregation effect, the paddings removed from individual activity durations can be replaced by one project buffer that is much smaller than the sum of all the removed paddings.

The second reason why the project buffer size can be reduced stems from the

obverse of Parkinson’s Law, which states “work expands to fill the time available.” Removing padding from each activity creates a sense of urgency; people have less time to do the work, hence tend to work faster than when they have more time. For these reasons, the project buffer size can be reduced by 50 percent. This is shown in Figure 7.20.

The project manager commits to completing the project on or before the date at the end of the project buffer, Week 28, although the project team works to complete the project on or before the date at the start of the project buffer, Week 20. Thus, there is a high likelihood that this project will be completed in less than 28 weeks. With the critical path method, there is a high likelihood that the project will be completed after the critical-path duration of 32 weeks.

Figure 7.20 Schedule with buffer sizes reduced.

Critical Chain

Figure 7.20 reveals a potential problem, though: activities Q and T both use the same resource (the “technician”). Assume the technician can work on only one activity at a time. To allow for that, the schedule is adjusted as shown in Figure 7.21 (Putting Activity Q before T is another possible schedule). In the adjusted schedule, path S–T–Q–R–Z is called the critical chain, defined as the path connecting activities that require the same resource. The critical chain is not necessarily the longest path through the network, although whenever the length of the critical chain plus buffers exceeds the length of the critical path, the critical chain, not the critical path, determines the project duration.

Traditional network methods address resource-conflict problems by means of

resource leveling, although the result will not necessarily be the same as with CCPM since they resolve these conflicts starting with an initial schedule and use available slack. In CCPM, resource conflicts are resolved during the initial scheduling process and resource dependencies are treated as a priori.

Note that the feeding buffer, F.B., is 4 weeks, not 2. The reason is because it follows only one activity, P, and hence the aggregation effect does not apply. Ultimately, the size of the buffer is at the manager’s discretion and is whatever she decides.

If the schedule does not meet a predetermined due date or upper management wants the project completed sooner, additional resources must be added. But adding people and other resources is costly and often disruptive; hence CCPM attempts first to make full use of whatever resources are currently available.

Resource Buffers: Capitalizing on Finishing Work Earlier than Planned

Figure 7.21 Schedule adjusted so that every resource performs only one task at a time.

Mentioned earlier was the fact that whenever activities finish late, their successors start late, but whenever they finish early, their successors don’t necessarily start early. Resources (people and equipment) that have been prescheduled often are not available to start earlier because they are busy with something else. As a consequence, whenever delays occur, the project is delayed; whenever gains (predecessors finishing earlier than scheduled) occur, it makes no difference!

Figure 7.22 Resource buffers providing countdown on when to start critical activities.

In CCPM, the project team is able to capitalize on predecessors finishing early through the use of resource buffers. Unlike project and feeding buffers, resource buffers do not add time to the schedule. A resource buffer is a countdown signal or warning to alert resources that an activity on the critical chain will possibly finish earlier than planned and to be prepared to start early. In a marathon relay race, each runner is prepared to accept the baton from the previous runner, regardless when the latter arrives; likewise, resources on the critical chain are prepared to start work as soon as predecessors finish their work, regardless of the schedule. In practice, a resource buffer can take the form of a series of email or other messages to resources, counting down the time remaining before they must be ready to start an activity. The locations of resource buffers are illustrated in Figure 7.22.

Note that resource buffers are inserted only on the critical chain since feeding buffers are able to adequately deal with the uncertainty on noncritical paths. Note also there is no resource buffer between Activity T and Activity Q since the same resource (technician) does both and, obviously, needs no notification as to when she will finish Activity Q and must start Activity T.

Milestone Buffers

Sometimes milestone deadlines are set at intermediate times in the project, such as at the scheduled completion dates for project phases. In that case a milestone buffer is inserted before each milestone. When milestone buffers are used, the size

of the project buffer is reduced; in effect, the project buffer is divided up among the milestone buffers. The different types of buffers are summarized in Table 7.5.

Sizing of Buffers

CCPM relies heavily on project and feeding buffers, so making them the right size is important. Goldratt suggests that activity durations be cut by 50 percent and that the project buffer be half the duration of the resulting longest path.14

This method, which reduces project duration by 25 percent, was illustrated in Figure 7.19 and is referred to as the “50 percent of chain” and “cut and paste” method.

When a path consists of many activities, even a buffer of 50 percent of the path length is too large.15 Newbold proposes the square root of sum of squares (SSQ) method, where the buffer size is set to the square root of the sum of squares of the differences between the low-risk duration and the mean duration for each task along the longest path leading to the buffer.16 Others have suggested additional methods.17

Table 7.5 Summary of Buffer Types for a Single Project

Buffer Type Function of the Buffer

Project buffer

Comprised of aggregated contingency reserves taken from activities on the critical chain; provides a contingency reserve between the earliest

completion date possible and the committed date. Milestone buffer

Similar to a project buffer but used when a project phase or milestone has a fixed due date.

Feeding buffer

Comprised of aggregated contingencies taken from noncritical paths; stabilizes the critical chain by preventing noncritical activities from

delaying critical activities.

Resource buffer

An early warning or “count down” to the start of a critical activity that ensures that resources are ready to do work on the critical chain as

soon as all preceding activities have been completed.

Padding, Multi-tasking, and Procrastination

Projects take longer than necessary for many reasons. First, as already stated, people pad their time estimates, and the effect of this gets worse as each manager in the WBS adds to the padding. If the person responsible for an activity pads the time by 10 percent and each person higher in the WBS also pads it by 10 percent, the padding at the project level for an n-level WBS would be (1.1)n. For a five- level WBS, this yields a total contingency of 60 percent; if each pads 15 percent, the total contingency would be 101 percent.

Figure 7.23 Effect of multi-tasking on elapsed and completion times.

Second, people multi-task. For example, a contractor has three independent projects, X, Y, and Z, each of expected duration 10 weeks. The contractor is anxious to finish all of them as soon as possible so he divides each into small pieces so that, in a sense, he can work on all of them at once. But in doing so, he actually delays the completion of two of the projects. If he had scheduled the projects sequentially X first, Y second, and Z last, without interruption, then, as shown in Figure 7.21(a), he would finish X at Week 10, Y at Week 20, and Z at Week 30. But when he breaks up the projects into segments of, say, 5-week periods, and alternates working among them, he increases the elapsed time for each project from 10 weeks to 20 weeks. As illustrated in Figure 7.23(b), the result

is that two of the projects are delayed: X finishes in Week 20 and Y finishes in Week 25. In general, the more the activities or projects are broken up and intermixed with other projects, the greater the elapsed time to finish any of them.

Figure 7.24 Students’ syndrome (a) in a production and (b) in a project.

Compounding the effect is that multi-tasking precludes people from gaining the momentum they would have by focusing uninterrupted on only one task, as was illustrated in Figure 6.25. Multi-tasking should be avoided. By focusing on just one activity at a time, each activity is completed sooner, successor activities start earlier, and the project finishes sooner.

A third reason projects take longer than necessary is people procrastinate and waste available slack.18 Given a choice between two scheduled times, one early and one late, many people choose the late one; this automatically eliminates slack, puts activities on the critical path, and increases the likelihood of project delay. Also, whenever people perceive slack, they are less motivated to complete an activity early. The effect is called the “students’ syndrome,” hinting to students’ initial enthusiasm for a new course that soon wanes, not to resume until just before the final exam. A similar effect happens in production and project environments, shown in Figure 7.24.

Shortening activity durations and scheduling activities as late as possible (with buffers) reduces the tendency to procrastinate.

Buffer Management for Project Control

Every activity on a project is linked to a buffer: activities on the critical chain are linked to the project buffer and all others to feeding buffers. During project execution those buffers are monitored to predict the project completion date and assess the risk of missing the due date. The amount of buffer “consumed” is determined each day by simply asking people working on activities the expected remaining duration and calculating to what extent that duration overruns the aggressive estimate and, hence, consumes (penetrates) the buffer. As long as delays consume less time than the buffer holds, the project will be on time; if they consume more time than the buffer holds, the project will be late. Buffer consumption also provides a clear, objective way to determine priorities. Whenever someone is required to work on more than one activity, the most- consumed buffer indicates which activity has highest priority. Buffer management is further discussed in Chapter 11.

See Chapter 11

Challenge of CCPM: Changing Behavior

A belief in most project organizations is that because the project manager has to commit to the due date, everyone in the project must also commit to due dates. In CCPM, the premise is that only the project manager needs to commit to a completion date; everyone else works toward realistic (relatively “aggressive”) estimates. While getting everyone to accept this premise in small projects can be relatively easy, such is not the case for major projects. Since most people are accustomed to working toward deadlines, this requires no less than a cultural and behavioral change at all levels of the organization, including top management. Senior managers and customers who do not understand the principles of CCPM will try to work around them.

Software Support for CCPM19

Many project management software packages include provision for CCPM, and although many others require add-ons to make them compatible with CCPM. For example, Sciforma™ and Concerto™ software fully support CCPM, but MSProject supports it only with the Prochain™ add-on.

7.6 TOC Method for Allocating Resources to Multiple Projects20

As much as 90 percent (by value) of all projects are carried out in multi-project environments.21 The theory of constraints (TOC) provides a five-step procedure for scheduling the start of new projects so as to maximize the number of projects an organization can handle concurrently.

Step 1: Identify the Constraint

What prevents a company from doing more projects? If the company has few projects on the order books, the constraint might be limited market share or the size of the market. But if it has more demand for projects than the capacity to do them, the constraint is anything that reduces the rate at which projects are completed (flow rate) to less than the maximum; the most common constraint is a highly loaded resource or multi-tasking.

Production environments such as manufacturing “job shops” use priority rules (discussed earlier) to select the next job to which a resource (usually a machine) should be assigned. In job shops it is easy to identify the constraint—it is the machine ahead of which queues of work pile up. Such a resource, the system constraint, is called the “drum resource” because it sets the tone or pace of everything flowing through the process. The TOC philosophy emphasizes the importance of keeping the constrained (drum) resource busy, preventing starvation and blockage from reducing the flow. To ensure this, drum buffers are used. Application of drum buffer to project management is described elsewhere.

Experience with implementing the theory of constraints, however, suggests that while a specific resource might be identified as the constraint in a multi- project environment, often the real constraint is something other than that resource. In practice, the identified constraints might be different for planning a set of projects than for their execution. Typical such constraints are discussed next.

In a sequence of activities, regardless of the actual constraint, an activity near the end of a project may be chosen as a substitute for the constraint.22 For planning a set of projects, a rule regarding the scheduling of this activity may be used as proxy for the constraint of the set of projects. For example, in one electronics company that conducts multiple, concurrent projects, all projects must pass through “final integration” just before closeout, and a specialist engineer with high workload was identified as the resource constraint. Rather than using that resource to stagger projects, however, it was decided instead to use the rule of only three projects in final integration at a time. In Figure 7.25, the shaded activities represent final integration in nine projects. To ensure there are always three projects in final integration: Project 4 starts final integration as soon as Project 1 completes final integration, Project 5 starts final integration as soon as Project 2 completes final integration, and so on. This staggers the work on all resources through subordination of individual project schedules as discussed in Step 3 below. For executing the set of projects, the typical constraint is the time available for managers to support the projects.

Figure 7.25 Only three projects in final integration at any point in time.

Step 2: Decide how to Exploit (utilize) the constraint

The rule “only three projects in final integration” enables the company to exploit the final integration constraint for project planning purposes. Combining the

scheduled date for when a project should start final integration with the project’s duration determines when the project should be initiated. Whenever an integration task cannot start according to the rule, or work must wait for an integration task, then the duration of integration tasks is adjusted to enable the appropriate staggering of project release.

In the event that a project’s final integration is completed early, resource buffers (discussed earlier) will ensure that subsequent projects can be started early.

Because fewer projects are being worked on, staggering them in this way reduces the workload on most resources, reduces multi-tasking across projects, improves the flow of projects (i.e., the rate at which projects are completed), and ensures that commitments to customers are met.

If the constraint for executing (as opposed to releasing) the set of projects is time available for managers to support the projects, then measures must be taken to assure such time is available. If lack of management time constrains the flow of projects, then this constraint has to be removed.

Step 3: Subordinate everything else to decisions regarding the constraint

During scheduling, the release of projects (authorization) is based on the load on the constraint. If the company decides that it should have only three projects in the final integration phase, the proxy constraint is the rule “three projects in final integration.” Each new project would be slotted to start final integration at whatever time is necessary to maintain that three-project maximum. The schedules of individual projects are therefore subordinated to the schedule of the multi-project constraint—i.e., the rule regarding the number of projects in the integration phase. The project at the highest risk of missing its due date would be scheduled to start first, as indicated by its project buffer status. The utilization of all resources for the set of projects is also subordinated to the schedule, and people do not multi-task.

If the constraint for project execution is time available for management support, then all other work to be performed by managers must be subordinated

to this support role.

Step 4: Elevate the constraint

The constraint is “elevated” by providing additional capacity. Elevating the constraint involves, for example, increasing the capacity so as to increase the number of projects in final integration from three to four. It typically implies costly measures such as building new facilities and hiring and training additional people. Steps 2 and 3 therefore ensure that existing capacity is utilized effectively before money is devoted to acquiring additional resources.

If the constraint is management time available for project support, then the management system should be simplified to improve its effectiveness in performing support functions.

In multi-project environments, resource buffers have less utility. The resources are dedicated to individual projects; they do not become available when a task is completed. They simply begin work on the next task, even if they have to wait a while before starting. Actually, it is desirable that they are idle between projects: to maximize project flow, resources should have to wait for work; work should not wait for resources.

In this way it is possible that all activities (including those on noncritical paths) can start as soon as predecessor activities are completed. Monitoring project buffers is all that is necessary to keep projects on track (as illustrated in Chapter 11, Example 11.3). Tracking project buffers simplifies the tracking and control process during project execution, relieves managers’ workloads, and increases the time available to support other projects. In turn, this elevates the constraint for project execution—the time managers have available to make better project decisions.

See Chapter 11

Step 5: Return to Step 1

Adding resources might remove the constraint, in which case a new constraint would be identified and the process repeated. Sometimes, however, the new constraint would be too disruptive, in which case the extant constraint is allowed to remain and not be elevated.

Discussion

One company has applied the TOC method for managing multiple projects by using only three rules:

Rule 1: During planning, stagger the release of projects. Rule 2: Plan aggressive project durations using project buffers only one-third

the length of the critical chain. Rule 3: During execution (a) ensure that activities are executed according to

priorities indicated by buffer status (Chapter 11, Example 11.3) and (b) minimize buffer consumption by doing all tasks as soon as possible.23

How good is the TOC heuristic for planning compared to traditional priority rules? The answer is somewhat equivocal. For some simple projects the results are the same. One exploratory experiment where TOC was compared with the oft-used least slack rule showed TOC gave better results,24 but another yielded poorer results.25 Although TOC is based on logic and seems to make sense, verification in practice would require empirical research from a variety of different industrial settings, which has yet to be done.

7.7 Discussion and Summary

This chapter has covered project scheduling methods that address time constraints, resource constraints, uncertainty about activity and project durations, and multiple projects sharing resources. The methods offer ways to accelerate projects and reduce uncertainty about completion dates, although, unlike simpler techniques such as Gantt charts and critical path networks, they have gained lower acceptance and are applied mainly in relatively sophisticated industries. All the methods have limitations, yet all have merits.

• CPM enables managers to determine the least costly way of reducing project duration to complete the project by a due date or in the shortest time.

• PERT enables managers to estimate the probability of finishing a project by a predetermined date. But the method considers only the current critical path and ignores noncritical paths that could become critical. Monte Carlo simulation overcomes this limitation by accounting for the possibility of any path becoming critical.

• The critical chain method, CCPM, based on the theory of constraints (TOC), aims at reducing project duration. Using time buffers it transforms a stochastic problem into a simpler deterministic one. Unlike CPM wherein noncritical activities are scheduled as early as possible, CCPM schedules them as late as possible but with buffers. With other methods, variability in activity durations can lead to changes in the critical path without warning, but buffers in CCPM provide relative stability to the critical chain—the path connecting activities that require the same constrained resource. CCPM offers a practical and relatively simple way to schedule projects, but it requires a shift in human behavior since only the project manager and nobody else is required to commit to due dates. Many managers find that concept hard to swallow.

• Multi-project scheduling presents the challenges of allocating scarce resources to concurrent projects. The traditional way to allocate resources

among projects (and among activities within projects) is to use priority rules. The TOC way aims to allow as many concurrent projects as possible by improving the flow of projects through the system.

• All the above methods are supported by commercial software, which simplify their application and eliminate computational difficulties. But as with all management methods, appropriate application of the techniques assumes a sound understanding of the principles that underlie them and management acceptance.

Summary List of Symbols

n Number of activities on the critical path.

Cn Normal Activity Cost: The direct cost of completing an activity under normal

work effort; usually, the lowest cost for completing an activity.

Cc Crash Activity Cost: The direct cost of completing an activity under a crash

work effort; usually, the highest cost for completing an activity.

Tn Normal Activity Duration: The expected time to complete an activity under normal work effort; usually, assumed to be the longest time the work will

take.

Tc Crash Activity Duration: The expected time to complete an activity under a crash work effort; the shortest possible time in which an activity can be

completed.

te Expected Activity Duration: In PERT, the mean time to complete an activity, based on optimistic (a), most likely (m), and pessimistic (b) estimates of the

activity duration.

Te Expected Project Duration: The probability of the project finishing earlier than

this time is 50 percent and the probability of it taking longer is 50 percent.

Ts Target Completion Time for Project: A time specified for project completion.

V Variance of an Activity: The variability in expected activity duration.

Vp Variance of the Project Duration: The variability in the expected project

duration.

Review Questions and Problems

1. Define crash effort and normal effort in terms of the cost and time they represent. When would a project be crashed?

2. How do CPM and PERT differ? How are they the same? 3. What does the cost slope represent? 4. The cost slope always has a negative value. What does this indicate? 5. Time-cost tradeoff analysis deals only with direct costs. What

distinguishes these costs from indirect costs? Give examples of both direct and indirect costs.

6. What are the criticisms of CPM? How and where is CPM limited in its application?

7. The project network and associated costs (T in days, C in $1,000s) are shown below.

a. Verify that the normal duration is 22 days and that the direct cost

is $3,050. b. What is the least costly way to reduce the project duration to 21

days? What is the project cost? c. What is the least costly way to reduce the duration to 20 days?

What is the project cost? d. Now, what is the earliest the project can be completed and what

is the least costly way of doing this? What is the project cost?

8. The project network and associated costs (T in days, C in $1,000s) are shown below.

a. What is the earliest the project can be completed under normal conditions? What is the direct cost?

b. What is the least costly way to reduce the project duration by 2 days? What is the project cost?

c. What is the earliest the project can be completed and what is the least costly way of doing this? What is the project cost?

9. The following table gives information on a project (T in days, C in

$1,000s):

a. Draw the network diagram. Under normal conditions, what is the earliest the project can be completed? What is the direct cost? What is the critical path?

b. What is the cost of the project if it is completed 1 day earlier? Two days earlier?

c. What is the earliest the project can be completed? What is the lowest cost for completing it in this time?

d. If overhead (indirect) costs are $20,000 per day, for what project duration are total project costs (direct + indirect) lowest?

10. Has variability in a time estimate ever caused you to be late for an appointment? Describe.

11. A procurement officer finds that the delivery time for a specific item is never delivered in less than 5 days. The worst case scenario is that it takes 30 days for the item to arrive. A delivery lead time of 10 days is the most frequent.

a. Calculate the expected delivery time b. What estimate would you give for its variance? c. What factors would you take into account when deciding the

amount of time to allow of the item for in the project plan?

12. The tables below show the immediate predecessors and a, m, b for each activity in the two projects. For each project compute:

a. te and V for each activity

b. ES, EF, LS, and LF for each activity. c. Te and Vp for the project.

Activity Predecessors a m b A - 7 9 11 B A 1 2 3 C A 7 8 9 D B 2 5 11 E C 2 3 4 F C 1 4 8 G D, E 6 7 8 H F, E 2 6 9

Activity Predecessors a m b

A - 2 4 6 B - 2 2 3 C - 4 8 10 D A 4 6 7 E A, B 7 9 12 F D, E 1 2 3 G C 2 3 4 H F, E 2 6 9

13. Refer to the first network in the above problem.

a. What is P(Te< 23)? b. What is P(Te< 32)? c. For what Ts is the probability 95 percent that the project will be

completed?

14. For the network in Figure 7.12, what is the probability of completing each of the five paths within 30 days? What is the probability of completing them all within 30 days?

15. How would you use buffers to ensure that you are on time for

appointments? What factors would you take into account when you make a decision on the size of the buffer?

16. Explain in your own words how the principle of aggregation plays a role in reducing project duration.

17. The diagram below was drawn before it became clear that Mary would have to perform both Activity B and Activity F.

a. With the realization that Mary has to do the two tasks, indicate two possible critical chains.

b. Reschedule the work and indicate the position and the size of the feeding buffer.

18. Refer to the network in Question 19 in the Review Questions and Problems for Chapter 6.

See Chapter 6

a. Indicate the critical chain on the diagram. b. Assume the schedule uses durations from which any contingency

(padding) has been removed. Insert a project buffer and feeding buffers as required.

19. Refer to Figure 7.22. Scheduling Activity T before Activity Q would also have been a way to resolve the resource contingency. Explain why this

alternative was not selected. 20. Consider the data about project activities given in the table below.

a. Schedule the work in such a way that each person always has only one task to perform (do not reduce the durations of activities or insert buffers as yet).

b. Indicate the critical chain. c. Indicate where the feeding buffers should be inserted. d. What is the difference in the lengths of the critical path and the

critical chain?

Activity Predecessor(s) Duration (Days) Resources A - 2 John B A 3 Sue C - 3 Sue & John D C 2 Al E D, J 3 Sue & Al F E, B 2 John G F 2 Ann H - 4 Sue J H 2 Al

21. Discuss the difference between fast-tracking, concurrent engineering, and crashing.

22. Write an essay on the reasons why projects are often late. 23. Discuss the implications that subcontracted work would have on

implementing CCPM. 24. Discuss the implications of resource allocation for organizations involved

in multiple projects. 25. Revisit Question 18:

a. Use the shortest task-time rule to solve the problem and draw a Gantt chart.

b. Apply the least slack rule to solve the problem and draw a Gantt

chart. c. Apply the first three of the five TOC steps (section 7.6) to the

problem and draw a Gantt chart. d. Who would be the “drum resource”? e. How does the days that Ann has no work to do on this project

relate to TOC Step 3? f. Assume the two people in this problem also work on several

other projects as well, and the policy is to use the shortest task- time rule and the relative priorities of projects to decide on which activity a resource should work. Which rule (shortest task time or highest project priority) should have preference? Discuss.

26. In a multiple-project environment the drum resource carries a certain “status” since work performed by other resources (and the needs of other resources) are subordinated to it. In one company management put a flag at a work center to indicate that it was the drum resource. An improvement (TOC Step 4) removed this work center as the constraint and the flag was moved elsewhere to the new constraint. People working in the original center were disappointed and protested. How do you suggest management should handle this problem?

Questions About the Study Project

1. In the project you are studying, discuss which of the following kinds of analyses were performed:

a. PERT b. CPM/time-cost tradeoff analysis c. Scheduling with resource constraints d. CCPM

2. Discuss how they were applied and show examples. Discuss those applications which that were not applied but which seem especially applicable to the project.

3. How do you rate the risk of not finishing on time and what are the factors contributing to this risk?

4. Were people (other than the project manager) required to make commitments on the duration of activities? Comment on the possibility of changing this behavior.

Case 7.1 Bridgecon Contractors

Bridgecon Construction Company specializes in the detailed, design, and construction of steel and concrete bridges. The first phase of the company’s project management methodology, Initiation, includes identification of project opportunities and assessment of each project’s risks and alignment with strategic goals. Bridgecon’s marketing department identified an opportunity: a well-known bridge architect recently completed the concept design for a cable-stayed bridge intended to cross over electrified railway lines. Senior managers felt the company could handle the project and decided to pursue it; this marked the end of the first phase.

The project next enters the second phase, Estimating, which includes site visits by the estimating team, review of available resources and skills, detailed risk assessment, and preparing a preliminary plan for detail design, procurement, logistics, and construction. The phase includes activities A and B in Table 7.6, which are necessary to prepare the bid for building the bridge. The phase concludes with a presentation to the customer, the rail authority.

The project manager and the estimating team meet with the architect and structural engineers who produced the concept design to acquaint themselves with the design. They then meet with subcontractors who they might choose to construct the pilings and fabricate steel components. Following these meetings the “Initial Duration Estimate” and “Initial Cost Estimate” are completed, as listed in Table 7.6.

The RFP for building the bridge says acceptance of the plan by the rail authority is one criterion for selecting a contractor. Early on it becomes evident that starting with activity D and until the completion of activity S, operation of one of the railway lines under the bridge will be impaired, although an informal discussion with the rail authority indicates that that might be acceptable. During a subsequent meeting, however, the rail authority expresses concern that the impairment will last 17 weeks and requests Bridgecon to find ways to reduce that time. The estimating team suggests the following possibilities:

• The duration of activity N could be reduced from one week to half a week by using additional trucks. The additional cost would be $33,000.

• An alternative subcontractor for piling is approached. This subcontractor says it will be able to halve the time of activity H for a total cost of $960,000.

Two ways are identified to shorten the duration of activity D. First, additional temporary workers could be employed. This would reduce the duration to 3 weeks and increase the cost to $147,000. Second, a team of workers highly skilled in this procedure (and their

equipment) could be temporarily reallocated from another project. Adding this team and temporary workers to the original team could lead to completing the work in 1 week.

Table 7.6 Activities for Constructing the Cable-Stayed Bridge

Activity Activity Description Initial

Duration Estimate

Predecessors

Initial Cost

Estimate ($1,000)

A Detailed site investigation and survey

2 – 17

B Detailed planning 6 A 16 C Detailed design 6 B 557 D Preparation of site 4 C 47 E Relocate services 3 C 28

F Re-align overhead track electrification

4 C, E 650

G Access road and ramp construction

1 D 63

H Piling 2 G 820

J Construct foundations and abutments

3 H 975

K

Construct temporary supports to support bridge deck during

construction

2 F, G 720

L Fabrication planning of

structural steel components

2 C 13

M Manufacture structural steel components (off-

site) 2 L 1320

N Transport structural steel components and 1 M 433

erect on-site

P Erect pylons and fi ll with concrete

2 J 840

Q Construct main span

deck on pre-cast concrete beams

3 H, K, N, P 2800

R Cable-stay installation and lift the bridge deck off temporary supports

3 Q 875

S Removal of temporary supports

1 R 54

T Electrical system installation

1 S 147

U Roadway surfacing (paving)

2 S 142

V Finishing and ancillaries 2 T, U 76

W Commissioning – cut- over

1 V 14

X Formal hand-over and ceremony

1 W 9

Y Project sign-off 1 X 1 Z Administrative closure 1 W 4 AA Project End (Milestone) 0 Y, Z

10621

The manager of the other project estimates that the reallocation would cause him to forfeit an incentive fee of $150,000 for finishing his project early. The managers of the two projects agree that, should the reallocation be made, the value of incentive fee would be booked as a cost against the cable-stayed bridge project and transferred as a bonus to the other project.

• The duration of activity F can be reduced to 3 weeks but would increase the activity’s cost to $730,000. It could be reduced to 2 weeks but would cost $820,000.

• The duration of activity Q can be reduced to 2 weeks, but the activity would cost $2,929,000.

Questions

1. Compile a list showing the reduced periods for impairment of the rail operation and the associated additional costs.

2. Comment on the implications that crashing might have on the risk of not meeting the committed due date.

Case 7.2 Logon Project

After signing the contract, the management at Midwest Parcel Distribution (MPD) discovers that for many reasons it would be advantageous to complete the project in 40 weeks. It is too late for MPD to “require” the contractor Iron Butterfly to complete it in that time, but nonetheless it discusses the possibility with Iron Butterfly Company’s project manager, Frank Wesley. Reviewing the network diagram (below, Figure 7.26), Frank checks the feasibility of this and then asks his managers and technical staff to give him three time estimates for every activity in the project. The estimates are given below in Table 7.7.

Figure 7.26 LOGON project.

Questions

1. What is the probability of finishing within 40 weeks? 2. Do you foresee any significant risk of a delay that the calculations

for (1) above do not take into account? 3. Determine the most likely project duration.

Table 7.7 Time Estimates for LOGON Project

Activity Optimistic Duration(Weeks) Most Likely

Duration (Weeks) Pessimistic Duration

(Weeks) H 10 10 10 I 8 8 16 J 1 6 6 K 4 4 4 L 2 2 2 M 2 4 5 N 4 4 10 O 5 5 5 P 5 5 5 Q 5 5 5 R 2 5 5 S 3 3 6 T 3 3 3 U 1 1 2 V 3 5 5 W 2 2 8 X 3 3 3 Y 8 8 8 Z 6 6 6

Z 6 6 6

Case 7.3 Papua Petera Village Project

The Papua Petroleum Company is building a village to support workers for an oil field in Sumatra. The principle work of the project involves five work packages: build road, clear site, erect buildings, erect power generation plant, and build water purification system. Figure 7.27 is a high-level network diagram for the project. To explore ways to speed up the project, Papua asked its contractors to submit information about time and cost for crews working as many as three shifts a day. (Portable lighting technology would enable work to continue at night-time for second and third shifts.) The contractors responded with the following estimates, which excludes costs for materials, supplies, components, and systems that are fixed regardless of work times.

Figure 7.27 Papua Petera Village Project.

Work Package A: Build Road

• Road length, 10 km • One shift is able to build 0.1 km of road • First shift costs: labor, $4,000/day; equipment, $8,000/day • Second and third shifts, cost per shift: labor, $6,000; equipment

$9,000/day

Work Package B: Clear Site

• Using one shift, site can be cleared in 10 days; if two shifts, 5 days; if three shifts, 4 days

• First shift costs, labor and equipment: same as Work package A • Second and third shifts, cost per shift: same as Work package A

Work Package C: Erect Buildings

Forty buildings will be constructed of three standard models, all about the same size. Each shift is able to construct three buildings per week. Assume 5-day work weeks.

• First shift costs: labor, $4,000/day; equipment, $1,000/day • Second and third shifts, cost per shift: labor, $6,000; equipment

$1,500/day

Work Package D: Erect Power Generation Plant, Install Power Lines to Buildings

Work package will take 10 weeks; with a second shift, it will take 5 weeks. Assume 5 days/week.

• Labor shortage does not allow a third shift • First shift costs: labor, $6,000/day; equipment, $3,000/day • Second shift, cost per shift: labor, $9,000; equipment $4,200/day

Work Package E: Build Water Purification System, Install Water and Sewer Lines to Buildings

Work package will take 8 weeks; with a second shift it will take 4 weeks. Assume 5 days/week.

• Labor shortage does not allow a third shift • First shift costs: labor, $5,000/day; equipment, $4,000/day • Second shift, cost per shift: labor, $7,500; equipment $5,500/day

The above costs are all direct costs. Additonally is the indirect cost—the cost for management and administration of the overall project; this is estimated at $3,000/day for however long the project takes.

Given this information, Papua has asked project manager Abdul Ginting to estimate alternative total project costs and project durations for two cases: (1) the lowest cost alternative and how long the project would take, and (2) the shortest project duration alternative and how much the project would cost. Abdul is preparing his analysis and recommended course of action.

Endnotes

1. CPM first appeared in the article by its originators: Kelley J. and Walker M. Critical Path Planning and

Scheduling. Eastern Joint Computer Conference. Boston, MA; 1959, pp. 160–173.

2. Goldratt AY. Institute, group email messages sent on March 17 and 18, 1999; Larry English, Habitat for

Humanity, January 2007, Pretoria, South Africa; Habitat for Humanity, The Fastest House in the World,

accessed January 2007 from http://www.habitat.org/newsroom/1999archive/insitedoc004016.aspx?

print=true.

3. For a piece-wise approximation for nonlinear relationships, see Wiest J. and Levy F. A Management

Guide to PERT/CPM: with GERT/PDM/DCPM and other Networks. Englewood Cliffs, NJ: Prentice-Hall;

1977, pp. 81–85. The relationship between number of workers and activity duration is nonlinear; i.e.,

cutting the number of workers in half will not double the time but might increase it by, say, 50–150

percent, depending on the task. See Brooks F. The Mythical Man Month: Essay on Software Engineering.

Reading, MA: Addison-Wesley; 1995, pp. 13–36.

4. The method first appeared in the article by the originators of PERT: Malcolm D., Roseboom J., Clark C.

and Fazar W. Application of a technique for research and development program evaluation. Operations

Research 7, no. 5; 1959, 646–670.

5. See Miller R. Schedule, Cost, and Profit Control with PERT. New York, NY: McGraw-Hill; 1963, p. 58;

Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 10th

edn. New Jersey; 2009, p. 529

6. See Krakowski M. PERT and Parkinson’s Law. Interfaces 5, no. 1, November 1974; and Vazsonyi A.

L’Historie de la grandeur et de la decadence de la methode PERT. Management Science 16, no. 8, April

1970 (written in English). Other problems of PERT/CPM are described by Kerzner, Project Management,

pp. 519–522; Miller, Schedule, Cost, and Profit Control with PERT, pp. 39–45; and Weist and Levy, A

Management Guide to PERT/CPM, pp. 57–58, 73, 166–173. References to human behavior are in the

critical chain literature referenced in this chapter.

7. See Van Slyke R. Monte Carlo methods and the PERT problem. Operations Research 11, no. 5; 1963, 839–

860.

8. Adapted with permission from Evans J. and Olson D. Introduction to Simulation and Risk Analysis.

Upper Saddle River, NJ: Prentice Hall; 1998, p. 111–120.

9. Crystal Ball is a registered trademark of Decisioneering, Inc.; for information see decisioneering.com.

RiskSim is a trademark of Treeplan.com; see www.treeplan.com. For @Risk, see www.palisade.com. For

Arena, see www.rockwellautomation.com. For Simul8, see www.simul8.com

10. Viljoen P. Goldratt Schools, Personal communication, Pretoria, SA, May 2007, May 2010, and April 2015.

11. Goldratt E. What is this Thing Called Theory of Constraints and How Should it be Implemented? New

York: North River Press, Inc. 1990.

12. Pittman P. Project Management: A More Effective Methodology for the Planning and Control of Projects.

Georgia: PhD dissertation, University of Georgia; 1994; Goldratt E.M. Critical Chain. Great Barrington,

MA: North River Press; 1997.

13. Walker E. Planning and Controlling Multiple, Simultaneous, Independent Projects in a Resource

Constrained Environment, Georgia: PhD dissertation, University of Georgia; 1998. A TOC method for

allocating resources to multiple projects was developed in this study and subsequently has been

developed further.

14. Goldratt E. Critical Chain. Great Barrington, MA: North River Press; 1997, p. 156.

15. Herroelen W. and Leus R. On the merits and pitfalls of critical chain scheduling. Journal of Operations

Management 2001; (7): 559–577; Leach L. Critical Chain Project Management, 2nd edn. Norwood, MA:

Artech House, Inc, 2003; Geekie A. and Steyn H. Buffer sizing for the Critical Chain Project Management

method. SA Journal of Industrial Engineering; 2008; 19(1): 73–88.

16. Newbold R. Project Management in the Fast Lane – Applying the Theory of Constraints. New York: St.

Lucie Press; 1988.

17. Tukel I., Rom W. and Eksioglu S.D. An investigation of buffer sizing techniques in critical chain

scheduling. European Journal of Operational Research 2006; 172: 401–416; also see Trietsch D. The effect

of systemic errors on optimal project buffers. International Journal of Project Management, 2005; 23:

267–274; Shou Y. and Yeo K. Estimation of project buffers in Critical Chain Project Management.

Proceedings of the IEEE international conference on management of innovation and technology, 2000:

162–167.

18. Goldratt, Critical Chain.

19. For Prochain, see www.prochain.com; for Sciforma, see www.sciforma.com; for Concerto, see

www.realization.com.

20. Viljoen P. Goldratt Schools, Personal communication, Pretoria, SA, May 2007, May 2010, and April 2015.

21. Turner J.R. The Handbook of Project-Based Management. London, UK: McGraw-Hill; 1993.

22. In Goldratt E. and Cox J. The Goal 4th edn. Great Barrington, MA: North River Press; 2014; also in

Goldratt E. and Fox R. The Race. Croton-on-Hudson, NY: North River Press; 1986. The notion of using

the constraint (drum) to set the pace is described.

23. Adapted from training material of Realization. See www.realization.com.

24. Dass S. and Steyn H. An exploratory assessment of project duration in multiple-project schedules where

re-sources are allocated by the theory of constraints method. SA Journal of Industrial Engineering, 2006;

17(1): 39–54.

25. Cohen I., Mandelbaum A., and Shtub A. Multi-project scheduling and control: A process-based

comparative study of the critical chain methodology and some alternatives. Project Management Journal

2004; 35(2): 39–50.

Chapter 8 Cost Estimating and Budgeting

Cost estimates, budgets, WBSs, schedules, quality, and risk are interrelated. Ideally, cost estimates are based upon elements of the WBS and are prepared for each work package. When the cost cannot be estimated because an activity is too complex, the activity is broken down further until it can. When the work is ill- defined or uncertain, the estimate is initially based upon judgment and is later revised as information becomes available. Project schedules dictate the need for resources and the rate of expenditures, but the converse is also true: constraints on resources and working capital dictate the schedules. Imposing practical constraints on costs is necessary to create realistic project budgets; failing to do so results in projects being completed at exorbitant expense, or terminated prematurely due to lack of funds. Both occurrences are relatively commonplace.

Cost estimating, budgeting, and control sometimes are thought to be the exclusive concerns of cost specialists, planners, and accountants, but in projects they should be everyone’s concern. Project participants who are closest to the sources of costs—engineers, scientists, systems specialists, architects, or others— should be involved in the estimating and budgeting process. Commonly, however, these same people are disdainful of budgets and ignorant about how they work or why they are necessary.

The project manager, of course, must also be involved. Although she does not

need to be a financial wizard, she does need to be skillful in organizing and using cost figures. The project manager oversees the cost estimating and budgeting process, often with the assistance of a staff cost accountant. On most technical projects the cost engineer reviews the deliverables and requirements, assesses the project from both cost and technical points of view, and advises the project manager. Cost engineering is discussed later.

8.1 Cost Estimates

The cost estimate can seal the project’s financial fate. When project costs are overestimated, the contractor risks losing the job to a lower bidding competitor. Worse is when they are underestimated. A $50,000 fixed price bid might win the contract, but obviously the contractor will lose money if the project ends up costing $80,000. Underestimating is often accidental—the result of being overly optimistic, although sometimes it is intentional—the result of trying too hard to beat the competition. In a practice called buy in, the contractor reduces an initially realistic estimate just enough to win the contract, hoping to cut costs or renegotiate a higher price after the work is underway. The practice is risky, unethical, and, sadly, relatively commonplace. In large capital projects the tendency is to underestimate costs so as to get the funding needed to launch the project, but then forget the estimate soon afterward.

But a very low bid can also signify that the contractor cut corners in the estimate, forgot to include things, or was just sloppy. The consequences for both client and contractor can be disastrous, ranging from suffering a loss to bankruptcy. Cost estimates are used to develop budgets. After the project begins actual costs are compared to estimated, budgeted costs as one measure of the project’s performance. Without good estimates it is impossible to evaluate work efficiency or to determine in advance how much the project will cost on completion.

8.2 Cost Escalation

Estimating costs accurately can be difficult because the estimation process begins in project conception and before much is known about the project. The less well- defined the project, the greater the chances that actual costs will substantially differ from estimated costs. As a rule, the estimate will be too low and the project will suffer a cost overrun. The amount by which actual costs grow to exceed initial estimates is referred to as cost escalation. Some escalation is normal and up to 20 percent is common. Usually, the larger and more complex the project, the greater the potential for escalation. The costs of cutting-edge technology and research projects frequently escalate upwards of several hundred percent. The Concorde supersonic airliner exceeded the original estimate by a factor of five, nuclear power plants often exceed estimates by a factor of two or three, and NASA spacecraft sometimes by a factor of four to five.

Figure 8.1 shows a plot of percent cost overrun versus year of decision to build for 111 transportation-related projects spanning approximately 80 years.1 The study reporting these findings also looked at 246 other projects and got a similar picture. Clearly, overruns have been and remain common. How does that happen? There are many reasons.

Figure 8.1 Projects versus percent cost overrun.

Uncertainty and Lack of Accurate Information

Much of the information needed for accurate estimates is simply not available when costs are first estimated. At NASA, for example, lack of well-defined spacecraft design and unclear definition of experiments is the principal reason for cost overruns. Not until later, when the design is finalized and work activities are well-defined (during the definition phase) can material and labor costs be accurately determined. In most research and development projects the activities are unpredictable, of uncertain duration, or must be repeated. Nonetheless, management should strive for the clearest, most definitive scope of work, project objectives, and requirements, because without them, obtaining accurate cost estimates is near impossible.

During the project, whenever change to product designs or project schedules

are necessary due to product concept changes, developmental barriers, strikes, legal entanglements, or skyrocketing wages and material costs, the project cost estimate should also be updated so as to serve as a valid baseline for tracking and controlling project costs.

To allow for uncertainty, an amount called a contingency fund or budget reserve is added to the original estimate.2 This is the budget equivalent of the schedule reserve or buffer mentioned in previous chapters. The contingency amount is proportional to the uncertainty of the work; the greater the uncertainty, the larger the contingency.

The project manager (and sometimes the project sponsor or steering committee) controls allocation of the contingency fund. The fund (discussed later in this chapter) is intended primarily to offset small overruns arising from estimating errors, omissions, and minor design changes and schedule slippages. Each time the cost estimate is updated, so is the contingency fund. The fund is not a “slush” fund, and should be cut from the project budget when no longer needed as intended; otherwise, project costs will tend to rise to expend whatever remains in the fund. Contingencies are discussed later.

Changes in Requirements or Design

Cost escalation also occurs due to scope creep—discretionary, nonessential changes made to system requirements and plans. These changes come from a change in mind, not from oversights, mistakes, or mandates that would make them imperative. The routine tendency is for users and contractors alike to want to modify systems and procedures—to make “improvements” throughout the project life cycle. Such changes are especially common in the absence of thorough planning or strict control procedures.

Contracts occasionally include a change clause that allows the customer to make certain changes to contract requirements—sometimes for additional payment, sometimes not. The clause allows the customer flexibility to incorporate requirements not envisioned at the time of the original contract agreement. It can be exercised at any time and the contractor is obligated to comply. Any change, however, no matter how small, causes escalation; it usually

involves a combination of redesign or reorganizing work, acquiring new or different resources, altering plans, or undoing or scrapping earlier work. The further along the project, the more costly the change. When accumulated, even small changes have a substantial effect on schedules and costs. Formal change control procedures to reduce the number of changes and contain escalation are described in Chapter 11.

See Chapter 11

Economic and Social Factors

Even with good initial estimates and few changes, cost escalation occurs because of social and economic forces beyond anyone’s influence. Labor strikes, legal action by interest groups, trade embargoes, and materials shortages, all which serve to stifle progress and increase costs, cannot be precisely anticipated or factored into plans and budgets. Whenever work is suspended or interrupted, administrative and overhead costs continue to mount, interest and leasing costs on borrowed capital and equipment continue to accrue, and the date when payback begins and profit earned is delayed. Rarely can such problems be anticipated and their impacts incorporated into the contingency fund.

One economic factor that influences cost escalation is inflation. The contractor might offset this factor by inflating the price of the project, although ability to do that is often precluded by the actions of competitors or federal restrictions on price increases. Some protection from inflation may be gained by including clauses in the contract that allow wage and material cost increases to be appended to the contract price,3 but the protection may be limited. Inflation is not one-dimensional; it varies with the labor, materials, and equipment employed, and by geographical region and country. Subcontractors, suppliers, and clients use different contracts with different inflation protection clauses that might be advantageous or disadvantageous to other parties in the project.

Inflation also causes cash flow difficulties. Even when a contract includes an inflation clause, payment for inflation-related costs must be tied to the publication of inflation indices, which always lags behind inflation. Contractors

pay immediately for the effects of inflation but are not are reimbursed for those effects until later.

Cost estimates are typically based upon prices at the time of estimating. Thus, whenever inflation rates become known the estimates should be adjusted so as to provide a valid baseline from which to later identify cost variances and take corrective action. In long-term projects, future wage rates should be forecasted; this is done by starting with estimated wage costs in current dollars and then applying inflation rates over the project’s duration.

In international projects, costs escalate due to changes in exchange rates. When the costs are incurred in one currency but paid for in another, changes in the exchange rate will cause the relative values of costs and payments to change, resulting in a cost or price escalation. This topic is discussed in Chapter 19.

See Chapter 19

Inefficiency, Poor Communication, and Lack of Control

Cost escalation also results from work inefficiency, poor management and planning, poor communication, lack of supervision, and weak control. In large projects especially, these lead to conflicts, misunderstandings, duplication of effort, and mistakes. This is one source of escalation where management has substantial influence. Careful work planning, tracking and monitoring of activities and tight control improve efficiency and contain cost escalation.

Ego Involvement of the Estimator

Cost escalation also results from the way people estimate. Many people are overly optimistic and habitually underestimate the time and cost, especially for jobs where they have little experience. Have you ever estimated the time it would take for you to paint a room or tile a floor? How long did it really take? Sometimes, of course, the opposite happens: worried about overrunning the estimate, they “pad” it. The more the estimator’s ego is involved in the job, the

less reliable the estimate. Companies avoid the problem by employing professional cost estimators; these

are not the same people who will do the work. Remember the earlier contention about involving project participants in planning the project? Experienced workers are usually better at estimating time and materials than they are costs. So the doers (those who do the work) should define the work and estimate the needed resources and time, but the professionals should estimate the cost. People often confuse the estimate with a goal; they think an estimate is what a job should take or what they have been told it should take, not an honest prediction of what it will take. A cost estimate should never be based upon a previously set target or goal; thus, estimators must be positioned organizationally so they will not be coerced into providing the numbers someone wants.4

Project Contract

Chapter 3 describes the relative merits of different forms of contracts; at least two of these, fixed-price and cost-plus, are relevant to project cost escalation. A fixed- price agreement incents the contractor to control costs so as to keep the accrued costs below the contracted price. In contrast, a strictly cost-plus contract offers little incentive to control costs. In fact, when profit is computed as a percentage of costs (rare these days), the contractor is motivated to “allow” costs to escalate and tack on all kinds of fees. Other forms of agreements such as incentive contracts permit cost increases, but encourage cost control and provide motivation to minimize escalation.

See Chapter 3

Information and Assumptions

Information and assumptions from which estimates are made should always be cross-checked. Are the assumptions of the customer and contractor regarding costs correct? Does everyone agree on the work, materials, and other elements to

be covered in the estimate? Are the cost rates for labor, material, equipment, and services current? Is information about available facilities, equipment, systems, and services to be provided by the customer or other stakeholders accurate? Like the scope statement (and perhaps in reference to it), the cost estimate should explicitly identify all the cost elements used to produce the estimate.

Bias and Ambition5

Finally, it is human nature for the champions of projects to be optimistic about their projects. In fact, without champions most projects would never start and everyone might be worse off. That optimism, however, can lead to overestimating the benefits and underestimating the costs. Promoters of big projects know that if a project is important enough, sufficient funding to complete it will materialize, no matter the size of the overrun.

Example 8.1: Escalation of the Bandra-Worli Sea Link Project

January 1999—Government Clears Worli-Bandra Cable Bridge February 2001—Worli-Bandra Sea-link Enters Crucial Stage October 2002—Bandra-Worli Sea Link Toll To Be Costlier October 2003—Bandra-Worli Sea Link May Hit a Dead End January 2004—Bandra-Worli Sea Link Project Under Threat July 2005—Sea Link In Trouble over Extension May 2006—Bandra-Worli Sea Link To Be Ready By 2008

The headlines from local news media refer to the Bandra-Worli Sea Link (BWSL) roadway and cable-stayed bridge in Mumbai—India’s equivalent to San Francisco’s Golden Gate Bridge and a good example of megaproject woes. The 8-km bridge and its approaches bend 200 meters into the Arabian Sea to connect downtown Mumbai with its western suburbs. The bridge reduced travel time by half, to about 30 minutes.

The project was approved in early 1999 following 7 years of study; it was supposed to start in May, cost 650 crore (US $120M), and finish by mid 2001. But work did not begin until December, and already the estimated completion date had slipped to mid 2002. Then came the monsoons, which brought the project to a near halt in 2000 and 2001. In late 2001 the project’s prime consultant, Sverdrup, was dropped for failure to provide a “competent project engineer.” The replacement, Dar Consultants, modified the bridge design and added 2.8 km to its length and split the eight-lane main bridge into two four-lane roadways. By January 2002 the target completion date had slipped to March 2004. In October came the announcement that project costs had increased by 50 crores; due to a “paucity of funds” work had to be slowed and the completion date slipped to September 2004. A year later, monsoons and rough seas again halted work, delaying the completion date to 2005. Meantime, complaints grew from fishermen concerned about the link’s interference with their boats, and from environmentalists about its harm to marine ecology. In 2003 rains again stalled the project. The project’s primary contractor, Hindustan Construction, requested an additional 300 crores to cover delays and design changes, but the government balked and offered to pay only 120 crores. The controversy stalled the project for another year, though eventually funds materialized and the project resumed. By June 2005 the completion date was reset to September 2006 and the project cost to 1,306 crore. In May 2006 the completion date was again pushed back to April 2008, but not until June 2009 was the bridge dedicated. In March 2010, all lanes opened to traffic. Estimated cost: 1,600 crore (US $336M).

As illustrated, schedule delays and cost escalation are inextricably connected. The 11-year history of the BWSL project saw a 9-year schedule slip and 150 percent cost increase. Contributing factors included unknowns (weather), changes in scope and requirements (bridge and roadway design), social factors (livelihood and environmental impact concerns), economics (growing land values and interest), and management (dismissal of a major contractor).

8.3 Cost Estimating and the Systems Development Cycle6

Project cost estimating happens throughout all phases of the project life cycle. The first estimate is made during project conception. Since very little hard cost

information is available at that time, the estimate is the least reliable that it will ever be. Uncertainty about the project cost and duration may be large, as illustrated by the largest “region of time–cost uncertainty” in Figure 8.2. How much the project will really cost and how long it will really take are very much open to question. The project is compared to other, similar projects, and an estimate is made based upon standards of what it should take—labor time, materials, and equipment—to do the job. When there are no similar projects or standards, initial estimates are largely “guesstimates” and might end up being nowhere close to actual costs.

If the project is unique and ill-defined, uncertainty in cost estimates often dictates that contracts be of the cost-plus kind. As more aspects of the system and project are defined, the material costs, labor times, and labor rates can be nailed down, and cost estimates become more reliable. When the system and project are fairly routine, the estimates are somewhat more reliable and contractors are willing to accept incentive-type or fixed-price contracts. In fact, the awarding of contracts is sometimes put off until designs are somewhat complete and more accurate cost estimates are possible. This of course requires contractors to do a lot of front-end work without assurances that they will be awarded the job. Contractors required to bid before they can attain reliable estimates must include a contingency amount in the estimate to cover the uncertainty.

As the project moves into the middle and later phases, when work is being completed and funds expended, cost estimates become more certain. The shrinking time–cost uncertainty regions in Figure 8.2 illustrate this. As the uncertainty decreases, the amount in the contingency fund is reduced. A contingency starting out at 15 percent of the base project estimate might be decreased halfway through the project to 8 percent, then to 3 percent at the three- fourths mark, and then to 1 percent at final installation to cover minor

corrections at sign-off.

Figure 8.2 Time–cost graph showing cumulative project cost and regions of time–cost uncertainty.

As discussed in Chapter 4, usually a detailed plan is developed only for the most-immediate, upcoming phase of the project (phased or rolling wave plan), and that plan will include a cost estimate and cost commitments for the phase. At the same time, every attempt is made to look beyond that phase and to develop a realistic cost estimate for the entire project.

See Chapter 4

Once developed and approved, the estimate for the project becomes the budget and the baseline against which project progress and performance will be measured. It is thus bad practice to keep changing the estimate during the project because that destroys the purpose of a baseline—to measure progress and control costs. Sometimes, however, escalation factors render the baseline estimate

obsolete and mandate periodic revisions.

8.4 Cost Estimating Process

Estimate versus Target or Goal

Sometimes the word “estimate” is confused with “target” and “goal.” It shouldn’t be. Whereas an estimate is an attempted realistic assessment based upon known facts about the work, required resources, constraints, and the environment, a target or goal is a desired outcome. Other than by chance, the estimate will not be the same as the target or goal. That said, once computed the estimate can be compared to a target value or goal, and the work activities, resources, and schedules revised to bring the estimate closer to the target. Never should the estimate be a simple plug-in of the target value.

Accuracy Versus Precision

“Accuracy” represents the closeness of an estimated value to the actual value: the accuracy of a $99,000 estimate for a project that actually cost $100,000 is very good. In contrast, “precision” is the number of decimal places in the estimate. An estimate of $75,321 is more precise than one of $75,000 (though neither is accurate if the actual cost is $100,000). Accuracy matters more than precision: the aim is to derive the most accurate estimate possible.

Sometimes accuracy can be improved by employing a so-called three-point estimate, which combines optimistic (a), pessimistic (b), and most likely (m) cost estimates to arrive at an expected cost estimate—analogous to the PERT approach for computing expected time:

Classifying Work Activities and Costs

The cost estimating process begins by breaking the project down into work phases such as design, development, and fabrication, or into work packages from the WBS. The project team, including members from involved functional areas and contractors, meet to discuss the work phases or packages and receive specific assignments.

The team looks for tasks in the project that are similar to existing designs and standard practices and can readily be adopted. Work is classified as developmental or as an adaptation of existing, off-the-shelf (OTS) designs, techniques, or procedures. Developmental work involves uncertainty in design, testing, and fabrication, so cost estimating is more difficult compared to estimating for OTS items or duplicated work, which is straightforward and uses known prices or records of material and labor costs for similar systems or activities. Overruns for developmental work are common, especially due to inaccurate labor estimates. It is thus often beneficial to make use of existing designs and technology as much as possible.

Estimated costs are classified as recurring and nonrecurring. Recurring costs happen more than once and are associated with activities periodically repeated such as quality assurance and testing. Nonrecurring costs happen once and are associated with development, fabrication, and testing of one-of-a-kind items or procurement of special items.

In a pure project form of organization the project manager delegates responsibility for estimating to others, combines their estimates, and presents the final figures to management. In a matrix organization, estimating is the joint responsibility of the project and functional managers; the project manager coordinates the effort and accumulates results.

Although this typifies the estimating process, the actual approach will depend on the information available and the required accuracy of the estimate. Most estimates are made using variants of four methods: expert judgment, analogy, parametric, and cost engineering.

Expert Judgment

An expert judgment is an estimate provided by an expert—someone who from

breadth of experience or expertise is able to provide a ballpark estimate. It is a “seat of the pants” estimate used whenever lack of information precludes more- rigorous cost analysis. Expert opinion is usually restricted to estimates made during the conception phase and for projects that are poorly defined or unique and for which there are no previous, similar projects to compare.

Analogous Estimate

An analogous estimate is developed by reviewing costs from previous, similar projects. Often such an estimate is handy as a relatively fast reality check for estimates derived from detailed planning. The method can be used at any level: overall project cost can be estimated from the cost of an analogous project; work package cost can be estimated from analogous work packages; and activity cost can be estimated from analogous activities. The cost for a similar project or work package is analyzed and adjusted for differences between it and the proposed project or work package in terms of scale, locations, dates, and so on. If, for example, the analogy project was performed 2 years ago and the proposed project is to commence a year from now, the analogy project cost must be adjusted to account for inflation and price changes during the 3-year interim. If the analogy project was in California and the proposed project will be in New York, the cost estimate must account for regional differences in labor and material costs. If the scale (scope, capacity, or performance) of a proposed activity is twice that of the analogy activity, then costs from the analogy must be “scaled” up. But twice the size does not mean twice the cost, and the size-cost relationship must be uniquely determined.

Example 8.2: Estimating Project Costs by Scaling an Analogy Project

So-called process industries such as petrochemicals, breweries, and pharmaceuticals use the following formula to estimate the costs of proposed projects:

Cost (proposed) = Cost (analogy)[Capacity (proposed)/Capacity (analogy)]0.75 where “proposed” refers to a new facility and “analogy” to an analogous facility. In practice, the exponent varies from 0.35 to 0.9, depending on the kind of process and equipment used.7

Suppose a proposed plant is to have a 3.5 million cum (cubic meter) capacity. Using an analogy project for a plant with 2.5 million cum capacity and a cost of $15 million, the estimated cost for the proposed plant is

$15 million [3.5/2.5]0.75 = $15 million [1.2515] = $18.7725 million

Because the analogy method involves comparisons to earlier, similar projects, it requires extant information about prior projects. Companies that are serious about using the method gather cost documentation and retain it on a database that classifies costs according to type of project, work package, activity, and so on. When a new project is proposed, the database is accessed for cost details about similar projects and work packages. Of course, the basic assumption in the analogy method is that the analogy chosen is valid; sometimes that is where things go awry.

Example 8.3: A Case of Costly Mistaken Analogy8

In the 1950s and 1960s when nuclear power plants first appeared in the US, General Electric and Westinghouse, the two main contractors, together lost a billion dollars in less than 10 years on fixed-price contracts because they had underestimated costs. Neither had expected to make money on these early projects, but certainly they had not planned to lose so much either. The error in their method was assuming that nuclear power plants are analogous to coal power plants—for which the marginal costs actually get smaller as the plants get larger. But nuclear power plants are not like coal power plants. For one thing, they require more safeguards. When a pipe springs a leak in a coal plant, the water is turned off and the plant shut down until the leak is fixed. In a nuclear plant the water cannot be turned off or the plant shut down; the reactor continues to generate heat and if not cooled will melt,

cause pipes to rupture, and radiation to disperse. The water-cooling system needs a backup system, and the backup system needs a backup. Typical of complex systems, costs for nuclear plants increase somewhat exponentially with plant size—but in the early years of nuclear power nobody knew that.

Parametric Estimate

A parametric estimate is derived from an empirical, mathematical relationship. The method can be used with an analogy project (case in Example 8.3) to scale costs up or down, or it can be applied directly without an analogy project when costs are a function of system or project “parameters.” The parameters can be physical features such as area, volume, weight, or capacity, or performance features such as speed, rate of output, power, or strength. The method is especially useful when early design features are first being set and an estimate is needed quickly.

Example 8.4: Parametric Estimate of Material Costs

Warren Warehousing Company, a facilities contractor, needs a quick estimate of the material cost of a new facility. Company engineers investigate the relationship between several building parameters and the material costs for eight recent projects comparable in terms of architecture, layout, and construction material. Using the method of least squares (a topic covered in textbooks on mathematical statistics), they develop the following multiple regression model that relates material cost (y) to floor space (x1, in terms of 10,000 sq. ft.) and number of shipping/receiving docks (x2) in a building:

y = 201,978 + (41,490)x1 + (17,230)x2

The least squares method for this model indicates that the standard error of the estimate is small, which suggests that the model provides somewhat accurate cost estimates when compared to the actual cost of each of the

eight projects. A proposal is being prepared to construct a 300,000 sq. ft. facility with two

docks. The estimated material cost using the model is thus:

y = 201,978 + (41,490)(30) + (17,230)(2) = $1,481,138.

Cost Engineering

A cost engineering estimate is derived from a detailed analysis of individual cost categories at the work package or activity level. A bottom-up approach, it provides the most accurate estimates of all the methods, but it is also the most time-consuming. The method requires detailed work-definition information that, often, is not available early in the project. It first divides the project into activities or work packages (e.g., from the WBS), then divides each of these into cost categories. For small projects like Example 8.5 the approach is simple and straightforward.

Example 8.5: Cost Engineering Estimate for a Small Project

The project manager for the DMB project is preparing a project cost estimate. He begins by breaking the project into eight work packages and creating a simple schedule. Three labor grades will be working on the project; for each work package he estimates the needed number of labor hours per week for each grade. Hours per week per labor grade are represented inside the shaded boxes in Figure 8.3.

Figure 8.3 Schedule showing hours allocated to work packages by labor grade.

For each work package he also estimates the cost of material, equipment, supplies, subcontracting, freight charges, travel, and other non-labor costs. Table 8.1 summarizes the labor hours and non-labor costs. The sum of the non-labor costs is $26,500.

Table 8.1 Labor Hours and Non-Labor Costs

The hourly rates for labor grades 1, 2, and 3 are $10, $12, and $15, and the overhead rates are 90 percent, 100 percent, and 120 percent, respectively (the overhead amount is added to the labor cost; determining overhead rates is discussed later). Therefore, labor-related costs are:

Grade 1: 305($10)(100% + 90%) = $5,795 Grade 2: 350($12)(100% + 100%) = $8,400 Grade 3: 100($15)(100% + 120%) =  $3,300 

$ 17,495

The preliminary estimate for labor and non-labor cost is $17,495 + $26,500 = $43,995. Suppose the company routinely adds 10 percent to all projects to cover general and administrative expenses; this puts the cost at $43,995(1.1) = $48,395. If the contingency amount is also 10 percent, the total cost estimate for the DMB project is $48,395(1.1) = $53,235.

At the work package or lower level, detailed estimates are sometimes derived with the aid of standards manuals and tables. Standards manuals contain time and cost information about labor and materials to perform particular tasks. In construction, for example, the numbers of labor hours to install an electrical junction box or a square foot of wall section are both standards. To determine the labor cost of installing junction boxes in a building, the estimator multiplies an estimate of the required number of boxes, times the labor standard per box, and then multiplies that by the hourly labor rate. For software development the

industry standard is one person-year to create 2,000 lines of bug-free code. For larger projects the estimating procedure is roughly the same as illustrated

in Example 8.5 although more involved. First, the manager of each work package breaks the work package down into “basic” areas of work such as “engineering” and “fabrication.” Supervisors in each basic area then estimate the hours and materials needed to do the work. The engineering supervisor might further divide work into the tasks of structural analysis, computer analysis, layout and installation drawings, and manuals, then for each task develop an estimate of the duration and the labor grade or skill level involved. Similarly, the fabrication supervisor might subdivide the work by materials (steel, piping, wiring), hardware, machinery, equipment, insurance, and so on, then estimate how much (quantity, size, length, weight, etc.) of each will be needed. Estimates of time and materials are determined by reference to previous, similar work, standards manuals, reference documents, and rules of thumb (“one hour for each line of code”). The supervisors submit their estimates to the work package manager who checks, revises, and then forwards them to the project manager.

The project manager and professional estimators on the project staff review the submitted time and material estimates to be sure that no costs were overlooked or duplicated, everyone understood what they were estimating, correct estimating methods were used, and allowances were made for risk and uncertainty.9 The estimates are then aggregated as shown in Figure 8.4 and converted into dollars using standard wage rates and material costs (current or projected). The project manager then adds in a project-wide overhead (to cover project management and administrative costs) and a company-wide overhead (to cover general company expenses) to arrive at a cost estimate for the total project. The accumulation of work package estimates (upward arrows in Figure 8.4) to derive the project estimate is called the “bottom-up” approach.

Contingency Amount

Contingency amounts are added to estimates to offset uncertainty. As mentioned, the more complex or poorly defined the situation, the greater the required amount. Contingency amounts can be developed for individual activities or work

packages, or the project as a whole. Activity contingency is an amount estimated to account for “known unknowns” in an activity or work package, i.e., sources of cost increases that could or likely will occur; they include scrap and waste, design changes, increases in the scope, size, or function of the end-item, and delays due to weather. Later, when the project budget is established, this amount should be placed in a special budget, subdivided according to work packages, and strictly controlled by the project manager. When the sum of the activity contingencies is added to the total project cost, the result is the base estimate for the project cost.

Figure 8.4 The estimating process.

Senior managers, the program manager, or sometimes the project manager add yet another amount to the base estimate, a project contingency to account for “unknown unknowns”—external factors that affect project costs but cannot be pinpointed. Examples include unforeseen fluctuation in exchange rates, shortages in resources, and changes in the market or competition. In smaller projects, the project manager controls usage of the contingency; in larger projects, the program or senior management does. Adding the project contingency to the base estimate gives the final cost estimate. This is the most likely cost for the project.

Besides the activity and project contingencies, the corporation might set aside an allowance to cover overruns. This amount, the overrun allowance, is added to the most likely cost to yield a cost where, as a rule, the probability of exceeding it is less than 10 percent. The overrun allowance is controlled by program or corporate managers and ordinarily is not available to the project manager without approval.

Top-Down versus Bottom-Up

In general, estimating can be done in one of two ways: top-down and bottom-up. Top-down refers to estimating cost by looking at the project as a whole. A top- down estimate is typically based upon an expert opinion or analogy to other, similar projects. Bottom-up refers to estimating cost by looking at elements of the project—individual work packages and end-item components. Costs for each work package or end-item element are estimated separately and then aggregated to derive the total project cost. Example 8.5 is a bottom-up approach; Example 8.2 is a top-down approach. The approaches can be used in combination: portions of a project that are well-defined can be estimated bottom-up; other less-defined portions can be estimated top-down. The cost of each work package can also be estimated either way—by breaking the package into small elements and estimating the cost of each (bottom-up) or by making a gross estimate from analogy or expert opinion (top-down). The bottom-up method provides better estimates than the top-down method but is more time-consuming and requires more data.

Use of top-down or bottom-up corresponds somewhat to the project life cycle. In project initiation, the cost estimate might consist of no more than a top-down “ballpark” number to suggest the order of magnitude of the project cost. The estimate gives the customer or contractor a rough idea of the size of the cost, but the method involves little effort and, consequently, the estimate is low accuracy; little confidence is attached to it.

As the proposal is being prepared in the conception phase, the cost estimate is often based upon the top-down method of looking at previous but analogous projects and compensating for differences between, and lessons learned from,

them. The accuracy of the estimate depends upon the validity of the analogies and the ability to distinguish differences and areas of uncertainty.

In the definition phase (and sometimes also in conception, depending upon when reliable data is available), the cost estimate is often prepared using the bottom-up approach. This method provides a fairly accurate estimate as well as the cost figures necessary to establish the project budget and control accounts, discussed later.

Reconciling Estimates

The project manager submits the final cost estimate to company management along with forecasts showing the effects of potential escalation factors such as inflation and risks. Management compares the estimate against the gross estimate, the goal or target set by management or the customer, and either accepts it or mandates a revision. If the gross estimate is larger, the project manager reviews the work package estimates for possible oversights or over- optimism. If the final estimate is larger, the project manager reviews the work package estimates for incorrect assumptions, padding, and other sources of excess cost.

Reducing Costs

What happens if the final cost estimate must be reduced? Everyone in the project will want to retain their share of the budget and will resist funding or staff reductions. Non-managers especially (engineers, scientists, systems analysts), often unaware of the constraints, will resist cuts. Through diplomacy and negotiation, the project manager tries to convince everyone to look for ways to reduce costs. Failing that, she must convince them to accept any imposed reductions.

To reconcile differences between gross and final estimates, managers sometimes exercise an across-the-board cut on all estimates. This is poor practice because it fails to account for judgmental errors or excessive costs on the part of just a few units. It also unfairly penalizes managers who tried to produce fair

estimates and were honest enough not to pad them. Such indiscriminate, across- the-board cuts induce everyone later to pad estimates for their own protection.

Suppose you are the project manager and it is clear that top management’s target budget is simply too small to do the project. There are two courses of action: either undertake the project and attempt wholeheartedly to meet the budget, or hand it over to another manager. If you decide on the former, you should document and report your disagreement to top management; later, ways might be found to reduce costs and complete the project within budget. If the contract is cost-plus, the risk is low since additional costs will be reimbursed. If the contract is fixed-price and the budget is so underfunded as to likely require cutting corners or stalling the project, then you should suggest the project be cancelled or that another person be appointed project manager. Not only is this good business practice, it is the ethical thing to do.

8.5 Elements of Estimates and Budgets

Budgets and cost estimates both state the cost of doing something. The difference is that the estimate comes first and is the basis for the budget. An estimate might have to be refined many times, but once approved it becomes the budget and the amount for which the organization and work units then commit to performing the work. It is the agreed upon amount for what the work should cost and the baseline against which actual expenditures will be compared. Project budgets and fiscal operating budgets are similar; the difference is that the former covers the life of a project, the latter only a year at a time.

Estimates and budgets share the following elements:

• Direct labor expense • Direct non-labor expense • Overhead expense • General and administrative expense • Profit and total billing.

Direct Labor Expense10

Direct labor expense is the labor charge for the project. For each activity or work package, an estimate is made of the number of people needed in each labor grade, and the number of hours or days for each. This gives the distribution of labor hours or days required per labor grade. The labor hours for the various grades are then multiplied by their respective wage rates. The work package budget in Figure 8.5 shows the wage rates for three labor grades and the associated labor hours, time-phased over a 6-month period.

When the wage rate is expected to change over the course of the work, a weighted average wage rate is used. In Figure 8.5, suppose the initial rate for an assistant is expected to rise from $20 to $25 in months 3, 4, and 5. Instead of $8,000, the labor cost for an assistant would be 100($20) + 100($25) + 100($25) +100($25) = $9,500. The average wage rate would thus be $9,500/400 hours =

$23.75/hour.

Figure 8.5 Typical 6-month budget for a work package.

Direct Non-Labor Expense

Direct non-labor expense is the total expense of non-labor charges applied directly to the activity. It includes subcontractors, consultants, travel, telephone, computer time, material costs, purchased parts, and freight. This expense is represented in Figure 8.5 by the line “other direct cost.” Material costs include allotments for waste and spoilage and should reflect anticipated price increases. Material costs and freight charges sometimes appear as separate line items called direct materials and overhead on materials, respectively; computer time and consultants may appear as support.

Direct non-labor expenses also include necessities for installation and operation, such as instruction and maintenance manuals, engineering and programming documentation, drawings, and spare parts. Note that these are costs

incurred only for a specific project or work package. Not included are the general or overhead costs of doing business, unless those costs are tied solely to the specific project.

On smaller projects the direct non-labor expenses are individually estimated for each work package. In larger projects, a simple percentage rate is applied to cover travel and freight costs. For example, 5 percent of direct labor cost might be included as travel expense and 5 percent of material costs as freight. These percentages are estimated in the same fashion as overhead rates, discussed next.

Overhead, General, and Administrative Expenses

Direct expenses for labor and materials are easily charged to a specific work package, but other expenses cannot so easily be charged to specific work packages or even to specific projects. These expenses, termed overhead or non- direct expenses, are the costs of doing business. They include whatever is necessary to house and support the labor, including building rents, utilities, clerical assistance, insurance, and equipment. Overhead is usually computed as a percentage of the direct labor cost. Frequently, the rate is 100 percent but ranges from as low as 25 percent for companies that do most of their work in the field to over 250 percent for those with expensive facilities, laboratories, and equipment.

The overhead rate is computed by estimating the annual business overhead expense, then dividing by the projected total direct labor cost for the year. Suppose the total overhead for next year is projected to be $180,000. If total anticipated direct labor charges are $150,000, then the overhead rate to apply is 180,000/150,000 = 1.20. Thus, for every $1.00 charged to direct labor, $1.20 is charged to overhead.

Although this is the traditional accounting method for deriving the overhead rate, for projects it results in an arbitrary allocation of costs, which is counterproductive for project cost control because most overhead cost sources are not tied to any particular project. More appropriate for projects is to divide overhead costs into two categories: direct overhead for costs that can be allocated in a logical manner; and indirect overhead for costs that cannot. Direct overhead costs can be traced to the support of a particular project or work package; such

costs are allocated only among the specific projects or activities for which they apply. For example, the overhead cost for a department working on four projects is apportioned among the four projects based on the percentage of labor time it devotes to each. The department’s overhead cost is not allocated to projects it is not working on.

The other kind of overhead, indirect, includes general expenses for the corporation. Usually referred to as general and administrative expense, or G&A, it includes taxes, financing, penalty and warranty costs, accounting and legal support, proposal expenses, marketing and promotion, salaries and expenses of top management, and employee benefits. These costs might not be tied to any specific project, so they are allocated across all projects, to certain projects, or to parts of certain projects. For example, corporate-level overhead would be allocated across all projects, project management overhead on a per-project basis, and departmental overhead to specific project segments to which a department contributes. Often, G&A overhead is charged on a time basis, so the longer the project duration, the greater the G&A expense for the project.

The actual manner in which indirect costs are apportioned varies in practice. The example for the SETI Company in Table 8.2 shows three methods for distributing indirect costs between two projects, MARS and PLUTO.11 Notice that although company-wide expenses remain the same, the cost of each project differs depending on the method of allocating indirect costs.

Clients want to know the allocation method used by their contractors, and contractors should know the allocation method used by subcontractors. For example, Method I in Table 8.2 is good for the client when the project is direct labor (DL) intensive, but bad when it is direct non-labor (DNL) intensive. Method III is the opposite and gives a lower cost when the project is relatively non-labor intensive (i.e., labor costs are low but material and parts costs are high). This can be seen by comparing MARS (somewhat non-labor intensive) to PLUTO (somewhat labor intensive).

Table 8.2 Examples of Indirect Cost Apportionment

SETI Company: Company-Wide (Indirect Costs) Overhead (rent, utilities, clerical, machinery) OH 120

General (upper management, staff, benefits, etc.] G&A  40 

Indirect Total 160

Project Costs MARS Project PLUTO Project Total Direct labor (DL) 50 100 150

Direct nonlabor(DNL)  40   10   50  90 110 200

Direct Total  200 

Direct and Indirect Total 360 Some methods for apportioning indirect costs:

1. Total indirect proportionate to total direct costs

MARS Project PLUTO Project Total DL and DNL 90 110 200 OH and G&A  72   88   160 

162 198 360 II. OH proportionate to direct labor only; G&A proportionate to all direct costs

MARS PLUTO Total DL 50 100 150

OH on DL 40 80 120 DNL 40 10 50

G&A on (DLand DNL]  18   22   40  148 212 360

III. OH proportionate to direct labor only; G&A proportionate to DL and OH and DNL

MARS PLUTO Total DLand OH and DNL 130 190 320

G&A  16.25   23.75   40  146.25 213.75 360

Overhead costs appear in projects in different ways. Any overhead expense that can be traced to specific work packages should be allocated to them directly. These appear in the budget, as shown inFigure 8.5. Remaining overhead expenses that cannot be traced to specific work packages are assigned to a special “overhead” work package. This can be a single overhead work package for the

entire project, or a series of packages each tied to an individual project stage or phase.

Profit and Total Billing

Profit is the amount left over after expenses have been subtracted from the contractual price. It can also be an agreed-to fixed fee or a percentage of total expenses, determined, in part, by the kind of contract as discussed in the Appendix to Chapter 3. Total billing is the sum of total expenses and profit. Total billing and profit are included in estimates for the overall project, groups of work packages, and subcontracted work. They usually do not appear on budgets for lower-level work elements.

See Chapter 3

8.6 Project Cost Accounting Systems

A project might consist of hundreds or thousands of elements—workers, materials, and facilities, all of which must be estimated, budgeted, and controlled. To expedite the process, reduce confusion, and improve accuracy, you need a system to help compute estimates, create, store and process budgets, and track costs. Such a system, called a project cost accounting system (PCAS), is initially set up by the project manager, project accountant, or project management office (PMO). While the main focus of the PCAS is on project costs, the system also assists tracking and controlling schedules and work progress. When the PCAS is combined with other project planning, control, and reporting functions, the whole system is referred to as the project management information system (PMIS).

The PCAS is used throughout the project life cycle. During project conception and definition it accumulates work package costs estimates to produce the project cost estimate. This estimate later becomes the basis upon which the project and work package budgets are created.

During project execution, the PCAS accumulates, credits, and reports project and work package expenditures. It creates time-phased budgets (for example, Figure 8.5), which help managers monitor costs and verify that the work has been completed and charged. The system also enables budget revisions. The PCAS functions are summarized in Figure 8.6.

Figure 8.6 Elements of a project cost accounting system.

Example 8.6: A Pmis for Estimating Labor Requirements and Costs12

Sigma Associates is a large architectural/engineering firm that developed its own PMIS to assist in estimating, planning and scheduling.

At Sigma, the project manager begins each potential project by creating a WBS to identify the main work packages. Using a menu in the PMIS, she reviews the history of similar work packages from previous projects and the kind and amount of labor they required. By entering factors related to project size, construction costs, and type of client, she can estimate the labor requirements for every activity in the project. Using the PMIS, the project manager combines these labor estimates with requirements for existing projects to produce a labor resource loading forecast; this enables her to determine whether sufficient labor is available. If it is not, the project manager uses the system to review options such as modifying the schedule, using overtime, or leveling resources (discussed in Chapter 6).

See Chapter 6

The labor requirements estimate is given to the comptroller who, through the PMIS, applies existing or projected hourly rates to every activity. The comptroller then adds in employee benefits and labor overhead to produce an estimate for direct labor cost.

With information from the company general ledger, the comptroller computes the overhead rate, which he uses to charge the project for its share of company-wide expenses. He then uses the PMIS to roll up all of the estimated expenses and create an estimated project budget. Last, the comptroller analyzes the estimated budget along with the project plan for profitability. If the budget and plan show a reasonable profit and the comptroller and project manager both agree to the budget, the project is accepted. If not, a different plan is sought that maintains the same high- quality standards but is more profitable.

Time-Phased Budgets

The project manager needs a way to track and control where expenses are accruing, how well the project is progressing, and where problems are developing. One way is with a time-phased budget—a method that consolidates the project budget and the project schedule to show the distribution of budgeted costs according to the project schedule. Figure 8.5 is an example; it shows the distribution of costs in a work package over months 1 through 6. The PCAS generates reports like this for each work package, allowing the project manager throughout the duration of the project to compare budgeted costs and actual expenditures month-by-month.

For projects where a substantial amount of the costs originate from purchased items or services, a special time-phased budget is prepared for procured goods, work, and services. In large projects this budget is controlled by a materials or procurement manager.

8.7 Budgeting using Control (or Cost) Accounts

Budgeting and cost monitoring in small projects can be done using a single budget for the project as a whole. This budget, perhaps similar to the one in Figure 8.5, is used to compare actual costs with budgeted costs throughout the project.

On larger projects, however, a single, project-wide budget is too insensitive; once the project is underway and expenses accrue, it would be difficult to quickly locate the sources of cost overruns. The better way is to subdivide the project budget into smaller budgets called control accounts or cost accounts, each representing a work package on the WBS. Large projects have tens of control accounts; very large projects have hundreds.

The control account is the basic project tracking element in the PCAS. The accounts are set up in a hierarchy, similar or identical to the WBS. The lowest level account usually corresponds to a work package, although when the number of work packages is very large, one account might represent several work packages combined. Like work packages, each account might include:

• A work description • A time schedule • Who is responsible • Material, labor, and equipment required • A time-phased budget.

Control accounts also are established for project costs not readily attributable to any specific work package. For example, for monies allocated for items, materials, or equipment that can be used by anyone or any work package, or for jobs such as administration, supervision, or inspection that apply across the whole project, separate control accounts are established. These accounts are usually set up for the duration of the project or are extended period-by-period as needed or as funds are appropriated.

Figure 8.7 Integration of WBS and organization structure showing control accounts. (See Figures 8.8 through

8.12 for details.)

With a PCAS and control-account structure, it is easy to monitor cost performance for each work package, group of work packages, and the project as a whole. As an example consider the Robotics Self-Budgeting (ROSEBUD) project described in Chapter 6. Figure 8.7 shows the WBS for the project and the

See Chapter 6

organization chart for the contractor, KANE & Associates. The shaded boxes represent locations of control accounts; notice that each represents all or part of a work package for which a functional area is responsible. For the same project,

Figures 8.8 and 8.9 show, respectively, the time-phased budget portions of the control accounts for the programming department’s contributions to work packages L and W.

The WBS for ROSEBUD consists of nine work packages performed by four functional departments, plus an additional work package for project management. During the estimating phase each department submits a cost estimate for the work packages in its part of the project. Upon approval, with additions for overhead and G&A, each department’s estimate becomes a budget. In Figure 8.7, the ten shaded boxes represent departments/work packages for which initial cost estimates were made and, subsequently, budgets and control accounts were established.

8.8 Cost Summaries13

With the control account structure shown in Figure 8.7, high-level summary accounts can be developed by consolidating control accounts for the WBS and organizational hierarchies. Such consolidation is useful for monitoring the performance of individual departments and segments of the project. For example, consolidating accounts in Figure 8.7 horizontally results in a control account for each functional department. Figure 8.10 shows this with the time-phased budget for the programming department, which sums the budgets for work packages L and W (Figures 8.8 and 8.9).

Control accounts also can be consolidated vertically through the WBS. This would be useful for tracking and controlling individual work packages, clusters of work packages, or the project as a whole. Figure 8.12 is the time-phased budget for final tests, which is the sum of the budgets for work packages W (Figure 8.9) and X (Figure 8.11).

Figure 8.8 Budget for programming department for Work Package L.

Figure 8.9 Budget for programming department for Work Package W.

Figure 8.10 Budget for programming department.

Figure 8.11 Budget for Work Package X.

Figure 8.12 Budget summary for final tests.

Figure 8.13 Aggregation of control account information by project and organization.

The PCAS and control-account structure permit costs to be summarized in a variety of ways: Figure 8.13 shows budgeted amounts aggregated vertically and horizontally, and Table 8.3 shows budgeted cost types summarized for the five departments and nine work packages in the ROSEBUD project. Thus, through the PCAS and account structure, it is easy to identify cost deviations from budget at the project level or company level, and to readily trace such deviations to the work packages and departments that caused them. Chapter 11 will describe this.

See Chapter 11

8.9 Cost Schedules and Forecasts14

Questions arise during project planning about how expenditures vary throughout the project, which periods have the heaviest cash requirements, and how expenditures compare to income. To answer these and other such questions, it helps to anticipate the estimated “pattern of expenditures” as derived from work package cost estimates and the project schedule. Following are examples.

Table 8.3 Cost Summary for ROSEBUD Project

Cost Analysis with Early and Late Start Times

A simplifying assumption used in cost estimating is that costs in each work package are distributed uniformly. For example, a 2-week, $22,000 work package is assumed to have expenditures of $11,000 per week. With this assumption, it is easy to create a cost schedule that shows the cost each week of the entire project.

As an example look at Figure 8.14—the time-based network for the LOGON project using early start times. Then look at Table 8.4, which lists the work packages for LOGON and associated time and cost information. The weekly direct cost for each activity is the total cost divided by the time; e.g. for Activity H, it is $100K/10 weeks = $10K/week. Using the time-based network, the cost for the project each week can be computed by adding the costs for all activities scheduled in the week. The procedure is the same as described in the Chapter 6

for determining the resource loading. According to Figure 8.14, during the first 10 weeks only Activity H is scheduled, so the project weekly cost stays at $10K. Over the next 6 weeks activities I and J are scheduled, so the weekly cost is their sum, $16K + $8K = $24K. Further along, in weeks 17 and 18, four work packages— I, K, L, and J—are scheduled, so the weekly cost is their sum, $8K + $4K + $18K + $21K = $51K. These weekly costs, shown in the third column in Table 8.5, represent the cost schedule for the project. The fourth column, cumulative expense, represents the forecasted total project cost as of any given week. These costs are graphed in Figure 8.15.

See Chapter 6

Using the same procedure, project cost schedules and forecasts can be prepared based on late start times. Figure 8.16 is the time-based network for LOGON using late start times. The last two columns of Table 8.5 are the late-start weekly and cumulative costs.

Given the early and late cost figures in Table 8.5 it is possible to analyze the effects of delaying activities on project costs. By comparing weekly costs from early start times with those from late start times in Figure 8.17, the influence of schedule changes on project costs is readily apparent. The shaded region in the top figure—the feasible budget region, which is based on the early and late cumulative expenses, shows the range of budgets permissible by changes in the project schedule. The lower part of the figure shows the impact on weekly costs from delaying activities.

Figure 8.14 Time-based network for the LOGON project using early start times.

Table 8.4 Activities, Time, Cost, and Labor Requirements (Result of Work Breakdown Analysis)

Activity Time (Weeks)

Total Cost ($K)

Weekly Direct Cost ($K)

Weekly Labor Requirements (Workers)

H 10 100 10 5 1 8 64 8 4 J 6 96 16 8 K 4 16 4 2 L 2 36 18 6 M 4 84 21 3 N 4 80 20 CM 0 5 50 10 5 P 5 60 12 6 Q 5 80 16 CM R 5 0 0 0 S 3 0 0 0 T 3 0 0 0 U 1 14 14 9 V 5 80 16 14

w 2 24 12 6 X 3 36 12 6 Y 8 104 13 14 Z 6 66 11 5

Total Direct Cost- $990K

Table 8.5 LOGON Project Weekly Expense Using Early Start Times ($1,000)

When funding restrictions constrain project expenditures, cost schedules reveal the places where the schedule must be changed. For example, Figure 8.17 shows a peak weekly expense of $82,000 in Weeks 18 and 19. If a weekly budget ceiling of $60,000 per week were imposed on the project, then late start times would be preferred because they would result in a more “level” cost profile and peak expense of only $54,000. The method for leveling resources discussed in Chapter 6 is applicable to leveling project costs; costs are treated as just another resource.

See Chapter 6

Figure 8.15 Planned weekly expenses and cumulative expenses for the LOGON project.

Figure 8.16 Time-based network for the LOGON project using late start times.

Figure 8.17 Comparison of expenses, early versus late start times.

Effect of Late Start Time on Project Net Worth

Owing to the time value of money, the net present worth of work done farther in the future is lower than the same work if done earlier. Thus, delaying work in a lengthy project can provide substantial savings in the present worth of project costs. For example, suppose the duration of the LOGON is 47 months (instead of 47 weeks as used so far). If the annual interest rate is 24 percent, compounded at 2 percent per month, the present worth for the project would be $649,276. This is computed by using the monthly expenses in Table 8.5 (again, assuming the weeks shown to be months instead) and discounting them back to time zero. Now, when

the late start times are used instead, the present worth is only $605,915—a savings of $43,361.

Does this mean that activities should be delayed until their late start date? Not necessarily. Remember, delaying activities uses up slack time and leaves less time to deal with problems that could delay the project. Thus, whether or not to delay work should also depend on the certainty of the work. Activities that are unlikely to encounter problems can be started later to take advantage of the time value of money. Activities that are less familiar, such as research and development work, should be started earlier to retain slack that might be needed to absorb unanticipated delays. This assumes the critical path method; CCPM uses resource buffers, which preclude the need for slack. Also, whether or not to delay work should depend on the schedule of customer payments. If payments are tied to project milestones, then work tied to those milestones should not be delayed. Other factors concerning which activities can be delayed are discussed in Chapter 6.

See Chapter 6

Cash Flow

A problem the project manager often faces is maintaining positive cash flow, i.e., assuring that the cumulative cash inflows (payments received) exceed the cumulative cash outflows (payments made). Ideally, differences between cash in and cash out throughout the project will be small.15 The project manager must do a juggling act, balancing income from the client (typically milestone payments) or other funding sources with expense payments for labor, subcontractors, materials, and equipment. To help maintain this balance the manager can, for example, take advantage of the time lag between when materials and equipment are acquired, and when payments for them are required.

Figure 8.18 shows an example of forecasted cash flow. All contractually agreed-to sources of income over the life of the project are compared to all foreseeable expenditures, direct and indirect, as well as any penalty costs or scheduled payments—should the project be completed late. The deficit between

forecasted income and estimated expenditures represents the amount of working capital needed to meet payments for expenditures. Based upon this forecast, a funding plan should be created to ensure sufficient working capital is available throughout the project.

As mentioned, customer payments are sometimes made at milestones tied to completion of deliverables or project phases. Such payments help the contractor to cover his costs. The drawback, however, is that, should the project encounter serious problems, an unscrupulous contractor, having already received several payments, can simply walk away from the job and leave the customer in a fix! One way the customer can keep “hold” on the contractor is to withhold a significant portion of the agreed upon payment, called retention money, until all work is satisfactorily completed. Another way is to withhold a portion of the final payment, called a performance guarantee, for a period following handover of the end-item until all defects discovered by the customer have been rectified.

Figure 8.18 Balancing project income and expenditures.

8.10 Life Cycle Costs

Life cycle costs (LCC) represent all the costs of a system, facility, or product throughout its life, cradle-to-grave. The concept originated in military procurement when managers realized that costs to develop a system represent but the tip of the cost iceberg and that costs to operate (e.g. fuel consumption) and maintain (e.g. parts replacement) it are usually far greater. Whereas the emphasis in this chapter is on project costs, i.e., costs incurred during the project phases of definition and execution, LCC include costs for the remainder of the system life cycle—the operation phase, eventual disposal of the end-item, and sometimes the conception phase too (initiation and feasibility).

Anticipating LCC is necessary because costs influence many decisions. For example, suppose three contractors submit proposals to build a plant, and each proposal contains not only the plant’s construction cost but also its expected operating costs. If the bids are similar in terms of construction costs and plant features, the one with the lowest operating costs will likely win.

The LCC similarly affect decisions regarding development projects, and economic analysis in feasibility studies (Chapter 3) should consider all costs for acquisition, operation, maintenance, and disposal of the system to be developed. For example, most US aerospace manufacturers in the 1970s were hesitant to develop a supersonic commercial aircraft because of cost and environmental impact concerns. Costs to develop and produce the aircraft were projected to be high, as were costs for operation and maintenance. At issue were whether enough people would pay the high ticket prices necessary for the airlines to make a profit, and whether enough airlines would purchase the aircraft for the manufacturers to make money. Ultimately, many felt the answer was no on both counts. The US Congress cancelled subsidies for developing the aircraft, and the program dissolved. Meantime the Europeans decided differently and went on to manufacture the Concorde, only 14 of which went into service. Concorde flew for nearly 27 years and the last one was retired in 2003. The LCC were never recouped; had not the governments of Great Britain and France provided subsidies, the airlines and manufacturers would have lost money.

See Chapter 3

Key design decisions affecting the operation and maintenance of a system are made early in the project life cycle—in conception and definition. A product with a high development cost and purchase price becomes more appealing if it can be designed to have a relatively low operating cost. For example, a more fuel- efficient vehicle might be higher priced than less efficient vehicles, but customers readily pay the premium knowing that over the vehicle’s life they will recoup it through fuel savings and lower pollution. Of course, estimating LCC involves making assumptions about technology, market, and product demand, and relies on historical costs of similar systems and projects; still, it is a sensible way to assess projects, especially when there is a choice between alternative designs or proposals.

The LCC should also account for the time necessary to develop, build, and install the end-item, i.e., the time before the facility or system becomes operational or the product is “launched” to market. Time is important: it determines how soon the end-item will start to generate revenues, gain market share, and accrue profits or other benefits. The higher costs of speeding up the project are compared to the benefits gained from an early completion or product launch. Similarly, the cost of disposal at the end of the life cycle is also estimated; for facilities such as mines and nuclear power plants that require shut-down and rehabilitation after their useful lives, this cost can be substantial.

Analysis of LCC is also necessary for setting targets on development and operating costs and making design tradeoff decisions to achieve those targets. Following is an example:

Example 8.7: Life Cycle Costs for an Operational Fleet of Spaceships

This illustration extends on previous SpaceShip One examples, but the numbers are purely hypothetical. Having gained experience from SpaceShipOne, a larger spaceship and mothership are to be designed. The new spaceship will carry a pilot plus four paying passengers, go as high as

120 km, and be capable of 20 flights per year over an operational life of 5 years. The cost of developing and producing four of these spaceships and two motherships is estimated at $80 million. Meantime, a survey indicates that the number of people worldwide willing to pay the $190,000 ticket price to fly on these spaceships is at least 1,000 per year.

A “spaceline” that will use and maintain the spaceships is being created for a startup cost of $10 million. Operational costs for the spaceline consist of two parts: annual costs for ground operations (reservations, personnel, ground facilities, etc.)—$2 million/year; and per-flight costs for flight operations (fuel, parts, repairs, etc., for the spaceship and the mothership)— $0.4 million/flight. These costs are assumed constant for every year and flight, although realistically they would vary up or down depending on inflation, the learning curve, efficiencies, and economies of scale as more spaceships are added to the fleet. Annual revenues are assumed constant too, though they will likely grow as additional spaceships are made operational. Given these costs and ignoring other factors (e.g., time value of money), what is the LCC for the venture?

Assumptions

4 spaceships @ 20 flights/year each = 80 flights/year (320 passengers/year, which lies well within the estimated annual demand). 5 years of operation.

Costs

Development and manufacturing: $80 million Spaceline startup: $10 million Ground operations: $2 million/year Flight operations: $0.4 million/flight

Ticket price: $190,000 (marketing slogan: “Now YOU can go to space for under $200,000!”)

LCC Model

LCC ($ million) = Development and production cost + Startup cost + Operating cost (5 years) = $80 + $10 + {[5 yr x $2] + [5 yr x 80 flights x $0.4]} = $260 million Total revenues ($ million) = (5 yr x 80 flights x 4 passengers x $0.190) = $304 million.

Bottom line: Assuming the assumptions are correct, revenues will exceed costs by $44 million.

All the numbers are estimates, but some are more certain than others. For example, based upon experience with SpaceShipOne, the development cost might be fairly certain, but due to lack of long-term operational experience the per-flight cost is fairly uncertain. Startup and ground operations costs, if analogous to airline operations, might be somewhat certain, although passenger demand might be fairly uncertain.

The LCC model plays an important role in system design and development. Based on the model, sensitivity analysis can be performed to see what happens when costs increase or decrease to show best case, most likely, and worst case scenarios. The model can also be used to determine by how much and in what combination the costs must vary for the enterprise to become lucrative (or disastrous).

The LCC model is also used to set cost targets. If the decision is made to proceed with the $80 million development and production cost, then the project must be planned, budgeted, and controlled so as stay close to that amount. If the per-flight cost is set at $0.4 million, the project must strive to develop vehicles that will cost no more than that to operate. This will affect innumerable design decisions pertaining to many details. Early on, the design analysis must consider major alternatives (e.g., to carry five or six passengers, not four) and the expected costs, revenues, and benefits for each.

The best and only truly comprehensive approach to estimating and analyzing LCC is with a team of people that represents all phases of the system

development cycle—a cross-functional team of designers, builders, suppliers, and users, i.e., a concurrent engineering team. Concurrent engineering is discussed in Chapter 14.

See Chapter 14

Impact of Early Decisions on Life Cycle Costs

The importance of carefully defining requirements and the end-item system and preparing the project plan—in other words, devoting careful attention to decisions in Phases A and B of the project is illustrated in Figure 8.19, which shows the percent of life cycle costs committed to versus stage of the project. For example, the figure shows that about 80 percent of a product’s LCC is determined by decisions made in the project’s concept and design stages, which is well before the product is manufactured and used. This means that whatever the total product LCC, 80 percent is based upon choices made in the first two stages of the project.16 Unless those decisions correctly account for what will happen in the later stages of production and operation, the result will be a protracted systems development period, delayed launch of the product, and high production and operating costs.

8.11 Summary

Cost estimation and budgeting are part of the project planning process. Cost estimation logically follows work breakdown and precedes project budgeting. Accurate cost estimates are necessary to establish realistic budgets and to provide standards against which to measure actual costs; they are thus crucial to the financial success of the project.

Figure 8.19 Percent of life cycle cost set during stages of the systems development life cycle.

Costs in projects have a tendency to escalate over time. Defining clear requirements and work tasks, employing skilled estimators, being realistic in estimating, and anticipating escalation causes such as inflation all help to minimize escalation. Estimate accuracy is partly a function of the stage in the project life cycle during which the estimates are prepared; the further along the

cycle, the easier it is to produceaccurate estimates. However, accurate estimates are needed early in the project, and this accuracy can be improved by clearly defining project scope and objectives, and subdividing the project into small tasks and work packages. In general, the smaller the work element being estimated and more standardized the work, the greater the accuracy of the estimate. The aggregate of cost estimates for all the work elements plus overhead costs becomes the cost estimate for the overall project. The approved estimates become budgets after contingency reserves have been added.

The project budget is subdivided into smaller budgets called control accounts. Control accounts are derived from the WBS and project organization hierarchies and are the budget equivalent to work packages. In large projects a project cost accounting system (PCAS) is useful for aggregating estimates and maintaining a system of control accounts for budgeting and control.

Cost schedules are derived from time-phased budgets and show the pattern of costs and expenditures throughout the project. They are used to identify cash and working capital requirements for labor, materials, and equipment.

Forecasted project expenditures and other cash outflows are compared to schedule payment receipts and income sources to predict cash flow throughout the project. Ideally expenditures and income are balanced so that the contractor can maintain a positive cash flow. The forecasts are used to prepare a plan that guarantees adequate funding support for the project.

Review Questions and Problems

1. Why are accurate cost estimates so important, yet so difficult, in project planning? What are the implications and consequences of overestimating costs? Of underestimating costs?

2. Define cost escalation. What are major sources of cost escalation? 3. What is the purpose of a contingency fund (management reserve)? How

is the contingency fund used and controlled? 4. Describe what the term “phased (rolling wave) project planning” means. 5. How do changes in requirements cause cost escalation? 6. How does the type of contractual agreement influence the potential for

cost escalation? 7. What is the relationship between phases of the project life cycle and cost

escalation? 8. What are life cycle costs and how are they different from project costs? 9. Explain the difference between a cost estimate and a cost target. What

are the problems in confusing the two—in using cost targets as cost estimates?

10. Explain the difference between accuracy and precision. Give two examples that illustrate the difference.

11. For each of the following estimating methods, briefly describe the method, when it is used, and the estimate accuracy it provides:

a. expert opinion b. analogy c. parametric d. cost engineering.

12. Describe the process of using the WBS to develop cost estimates. Discuss “top-down” versus “bottom-up” estimating. How are work package estimates aggregated into total project cost estimates?

13. What is the role of the functional units and subcontractors in cost

estimating? 14. Describe the different kinds of contingency amounts and the purposes

each serves. 15. Describe the PCAS. What is its purpose and how is it used in project

planning? 16. What is a time-phased budget? What is the difference between a budget

and a cost estimate? 17. Distinguish recurring costs from nonrecurring costs. 18. What are six cost elements shared by most estimates and budgets? 19. How are direct labor expenses determined? 20. What expenses are included under direct non-labor? 21. How is the overhead rate determined? 22. What is a control account and what kinds of information does it

contain? How does a control account fit into the structure of the PCAS? 23. How are control accounts aggregated horizontally and vertically? Why

are they aggregated like this? 24. How are time-based forecasts prepared and how are they used? 25. What are the reasons for investigating the influence of schedules on

project costs? What is the feasible budget region? 26. What might happen if top management submitted a bid for a project

without consulting the business unit or department to be involved in the project?

27. Refer to Case 5.1, the Barrage Construction Company, in Chapter 5. The project manager Sean Shawn employed the analogy with adjustment method to estimate the cost of constructing a three-car garage. Specifically, he started with the cost of an average two-car garage, $43,000, and increased it by 50 percent to $64,500. Comment on the likely accuracy of the three-car garage estimate. Suggest a different approach that might yield a more accurate cost estimate, and then use this approach and made-up time and cost figures to compute the estimate. Argue why your estimate is better than Sean’s. See Chapter 5, Figure 5.19, for Sean’s WBS.

See Chapter 5

28. The example in Table 8.2 shows three possible ways of apportioning total direct costs. Using the same example, suppose the direct non-labor (DNL) cost and G&A are broken down as follows:

MARS Direct Non-Labor PLUTO G&A Materials 30 5 Freight 8 Other 10 5 Other 32

40 10 40

Assuming all remaining costs shown in Table 8.2 are unchanged, compute the project costs for MARS and PLUTO using the following apportioning rules:

a. Overhead (OH) is proportionate to direct labor (DL). b. Freight G&A is proportionate to materials. c. Other G&A is proportionate to DL, OH, DNL, and freight.

29. Chapter 7 discussed the impact of crashing activities and the relationship of schedules to cost. The CPM method assumes that as activity duration is decreased, the direct cost increases owing to the increases in direct labor rates from overtime. Overhead rates also may vary, although the overhead rate is often lower for overtime work. For example, the overhead rate may be 100 percent for regular time but only 20 percent for overtime. In both cases, the overhead rate is associated with the wage rate being used.

See Chapter 7

Suppose that in the MARS project in Table 8.2, 1,000 direct hours of labor are required at $50 per hour, and the associated overhead rate is 100 percent for regular time. Now suppose the overhead rate is 10 percent and overtime wage rate is time-and-a-half. Compare the project cost if it were done entirely on regular time with the cost if it were done entirely on overtime. Which is less expensive?

30. Use the table below and the network in Figure 8.20 to answer questions

about the ARGOT project:

Activity Time (Wks) Weekly Cost ($K) Total ($K) A 4 3 12 B 6 4 24 C 3 5 15 D 4 5 20 E 8 3 24 F 3 4 12 G 2 2 4

111

a. Compute the ESs and LSs for the project. Assume Ts is the same as the earliest project completion date.

b. Construct a time-based network for the project such as Figure 8.14 (use early start times).

c. Construct two diagrams similar to those in Figure 8.15 showing the weekly and cumulative project expenses.

Figure 8.20 ARGOT project network.

31. Using the data in problem 30, repeat Steps b and c using late start times. Then identify the feasible budget region using the cumulative curves.

32. Explain retention money and performance guarantee.

Questions About the Study Project

1. How were project costs estimated? Who was involved? Describe the process.

2. When did estimating take place? How were estimates checked and accumulated? How were they related to the WBS?

3. What, if any, were the principle causes of cost escalation in the project? 4. Was a life cycle cost analysis performed? If so, who did it, when, and

using what methods? How did the analysis affect the design, development, and production of the project deliverables or main end- item?

5. How often and when were cost estimates revised during the project? 6. How were overhead costs determined? What basis was used for

establishing overhead cost rates? 7. How were estimates tallied to arrive at a total project cost estimate?

Who did this? 8. What kind of project cost accounting system (PCAS) was used? Was it

manual or computerized? Describe the system and its inputs and outputs. Who maintained the system? How was it used during the project?

9. Describe the process of creating the project budget. Show a sample budget (or portion thereof).

10. How were management and supervisory costs handled in the budget? 11. Was the project budget broken down into control accounts? If so,

a. How were they related to the work packages and WBS? b. How were they tied into the PCAS?

12. What kinds of costs summaries were prepared? Who were they sent to? How were they used? Show some examples.

13. Did the PCAS produce time-phased cost schedules and forecasts? Show some examples. How were they used by the project manager?

14. Were life cycle costs a consideration in the project? Explain.

Case 8.1 Life Cycle Costs for Fleet of Tourist Spaceships

At the time of writing, Burt Rutan and Sir Richard Branson had teamed up to form The Spaceship Company, which will develop and manufacture commercial spacecraft (SpaceShipTwo, or SS2), launch aircraft (WhiteKnightTwo, or WK2), and support equipment. Branson’s “spaceline,” Virgin Galactic, will handle the operations for space tourist flights. Their hope is to eventually reduce by half the proposed initial ticket price of $190,000.

No information has been released about development and operating costs for the spaceline and equipment, so the figures used in this case are guesses. Refer to Example 8.7 for hypothetical life-cycle costs for the spaceline and spaceship fleet, but assume the following changes to the numbers:

• five spaceships, seven passengers per spaceship. • Development and manufacturing costs, $120 million. • Flight operations cost: $0.5 million/flight. • Ticket price: $190,000 for passengers on the first 100 flights, then

$150,000 for passengers on the next 100, and $100,000 for passengers on flights thereafter.

Questions

1. Assuming all other numbers from Example 8.7 are the same, what is the “bottom line” profit of the venture for 5 years of operation?

2. If the profit goal is $70 million,

a. What is the maximum development and production cost for the fleet?

b. What is the maximum per-flight operational cost; (note: assume $120 million development/production cost)?

3. Brainstorm. What are some ways that the development cost might be reduced? What are some possible design decisions for the spacecraft and mothership that would reduce the per flight operational cost? Next, research articles and news releases about SS2 and WK2 to see what the developers, Scaled Composites and The Spaceship Company, have been doing to contain costs.

Case 8.2 Estimated Costs for the Chunnel Project17

Before construction began on the English Channel Tunnel (Chunnel) Project, the banks underwriting the project hired consulting engineers to review cost estimates prepared by the contractors. The consultants concluded that the tunneling estimates were 20 percent too high. Their analysis was based on comparisons of costs from recent European tunnel projects, including 50 German railroad tunnels ranging in length from 400 m to 11 km, to the Chunnel, which would be 49 km in length. The costs of the tunnels ranged

from £55 to £140 per cum (cubic meter) of open tunnel; the cost of the Chunnel was estimated at £181 per cum on the British side of the channel and £203 on the French side (the difference owing to more difficult conditions on the French side). The Chunnel is actually three interconnected tunnels—one for trains going in each direction and a smaller service tunnel in between them. Note, however, that the cost estimates are per cubic meter of tunnel, so presumably, differences in tunnel lengths and diameters are not major factors. Why might the estimates for the Chunnel be so much higher per cum than the costs for the analogy projects? Discuss possible, logical adjustments to the analogy tunnel project costs to arrive at a cost estimate for the Chunnel.

Case 8.3 Fiona’s Estimate for the Gorgy Project

Fiona McDonald is preparing the cost estimate to accompany Highwire Systems’ bid proposal for the Gorgy Project. Her ballpark guess is that the project should take about 2 years and cost $3 million, however to help prepare the estimate she creates a WBS (Figure 8.21).

Figure 8.21 Gorgy Project.

She estimates the costs for the three work packages as follows:

Development $2 million Integration $1 million

Installation/Test $1.5 million Project $4.5 million

Although the total estimate is 50 percent more than her ballpark guess, she believes it is probably more accurate because it was developed “bottom up.”

She gives the estimate to Shireen Ghophal, Highwire Systems’ manager of contracts, who asks her, “Fiona, how did you arrive at the individual costs for the $4.5 million?” Fiona explains, “The development cost, $2 million, that was simple: I based it on the number provided in the RFP for what the development portion of the project should cost based on the customer’s experience from working with developers in similar projects. Besides, the number seemed ample to me, and since it was the only cost figure provided in the RFP, I considered it as sort of a mandate for the maximum development cost. As far as the integration cost, well, I looked at the customer’s hardware and software we’d be working with as listed in the RFP, and I compared it with the other projects we’d done with similar equipment and systems and what those projects cost. Finally, for installation and test, I reviewed six projects I’d completed in the last few years and their costs. Costs for installation and test ranged from $0.6 to $2 million, with $1.3 million average. So $1.5 seemed reasonable.”

Shireen replies, “Well, I ordinarily don’t question your work. But are you sure you’ve covered everything in the project in the work breakdown? Do the three work packages include everything? And don’t we usually do a site visit to inventory the customer’s equipment and systems that we’ll have to work with? Do you trust the RFP? Do they really know what they have? And looking at the project, it’ll take maybe 2 to 3 years. It’ll be a big project. Are you sure you and your staff will be able to manage and coordinate everything for that cost?”

Fiona responds, “Everything is covered. As far as the site visit is concerned, the proposal is due next week and we don’t have time. We’ll have to go with what they say in the RFP. As for installation, based on my experience the average installation/test cost was $1.3 million. I picked $1.5 million to be safe and cover any overages in development cost.”

Then Shireen repeats, “And what about the coordination and integration

effort?” to which Fiona replies, “Yes, that will probably be huge, but I’m pretty certain that if we get the contract, Highwire will let me hire maybe ten additional experienced analysts/engineers for my management staff. As you know we’ve run over on our last several projects and I’ve been arguing all along I just need more people to help coordinate and keep things under control.”

Shireen suspects that Fiona’s cost estimation approach is rather simplistic and leaves ample room for error. List at least four inadequacies in her approach and places where the estimates can go wrong.

Case 8.4 Melbourne Construction Company, D

Bill Asher, the estimator for Melbourne Construction Company, is currently estimating the days required to install the wall footings in the foundation of a hotel building. As is common for many of the activities in construction projects, he will develop the estimate using labor productivity standards.

Architectural drawings for the hotel indicate that the square foot contact area (SFCA) for the formwork footings is 13,340 sq. ft. (1,239 m2). Installation of footings is considered “standard”, so Bill refers to a manual of labor hour standards to estimate the total labor hours required for the task. The manual indicates that for the footings specified for the hotel, the standard is 0.066 labor hours per SFCA.18

1. Given the SCFA standard and the estimated SCFA for the footings, what is the estimated labor hours to install the footings?

2. The company intends to assign ten workers to install the footings. Assuming an 8-hour workday, what is Bill’s estimate for the number of days needed to complete this task? (Note: an assumption here is that for each additional worker assigned to a task, the task duration decreases proportionately. This is an important assumption since in many projects the task durations are not

proportionate to the number of workers. Adding workers will not necessarily shorten task times and might even increase them.)

Endnotes

1. Flyvbjerg B., Bruzelius N. and Rothengatter W. Megaprojects and Risk: An Anatomy of Ambition.

Cambridge: Cambridge University Press; 2003, p. 16.

2. See Archibald R.D. Managing High-Technology Programs and Projects. New York, NY: John Wiley &

Sons; 1976, pp. 167–168.

3. Harrison F. Advanced Project Management, Hants, England: Gower; 1981, pp. 172–173, gives an example

of an escalation clause.

4. Politically, how independent should the estimators be? So independent, says DeMarco, that the project

manager has “no communication with the estimator about how happy or unhappy anyone is about the

estimate.” DeMarco T. Controlling Software Projects. New York, NY: Yourdon Press; 1982, p. 19.

5. Flyvbjerg, Bruzelius and Rothengatter, Megaprojects and Risk: An Anatomy of Ambition.

6. Harrison, Advanced Project Management, pp. 154–161.

7. Dingle J. Project Management: Orientation for Decision Makers. London: Arnold/John Wiley & Sons;

1997, p. 105.

8. Pool R. Beyond Engineering: How Society Shapes Technology. New York, NY: Oxford University Press;

1997; Heppenheimer T.A. Nuclear power. Invention and Technology Fall 2002; 18(2): 46–56.

9. A complete discussion of the cost review procedure is given by Kerzner H. Project Management: A

Systems Approach to Planning, Scheduling, and Controlling, 10th edn. New York, NY: Van Nostrand

Reinhold; 2009, pp. 592–595.

10. See ibid., Chapter 14, for discussion of labor costing in projects.

11. This example is derived from a similar one in Rosenau M. Successful Project Management. Belmont, CA:

Lifetime Learning; 1981, pp. 89–91.

12. This example is derived from Wilson T. and Stone D. Project management for an architectural firm.

Management Accounting; October 1980, 25–46.

13. The kinds of cost summaries used often depend on the kind available in the software, though many

software packages permit customizing of reports.

14. Wiest J. and Levy F. A Management Guide to PERT/CPM, 2nd edn. Upper Saddle River, NJ: Prentice Hall;

1977, pp. 90–94.

15. Harrison, Advanced Project Management, p. 185, notes that balancing cash in foreign contracts is difficult

because “In many cases, the profits from [currency dealings] can exceed the profits from the project; [if

funds are] not managed effectively, the losses from foreign currency commitments can bring about large

losses on a project and lead to bankruptcy.”

16. Smith P. and Reinertsen D. Developing Products in Half the Time. New York: Van Nostrand Reinhold;

1991, pp. 224–225.

17. Fetherston D. The Chunnel. New York, NY: Times Books; 1997, pp. 141–142.

18. RS Means Labor Rates for the Construction Industry, 41st edn. Norwell, MA: RS Means; 2013.

Chapter 9 Project Quality Management

I have offended God and mankind because my work didn’t reach the quality it should have.

—Leonardo da Vinci

Besides meeting the budget and schedule, project success depends on how well a project meets performance requirements. Performance requirements generally are based upon project stakeholders’ needs and expectations about the functioning and performance of the project end-item or deliverables. A “high-quality” project is one that meets performance requirements, satisfies the needs and expectations of all key stakeholders, and causes no harm elsewhere.

9.1 The Concept of Quality

In the 1950s quality was viewed as the process of inspecting products that had already been produced and to separate the good ones from the bad. But in the current business environment, so the thinking goes, you have to prevent defects and failures rather than inspect for them; i.e., you cannot right a wrong by inspection. You have to build in processes to ensure things are done right the first time, every time, and a culture where everybody is quality-focused.

But in the competitive pursuit, project teams often seek ways to accelerate schedules and cut costs, even though this sometimes results in rework, mistakes, greater workload for the project team, and a “quality meltdown.” They become preoccupied with lowering costs and shortening schedules, even though “the bitterness of poor quality lives long after the sweetness of cheap price and timely delivery has been forgotten.”1

An example is the space shuttle Challenger. On January 28, 1986, defective seals allowed flames to breach the joint in a rocket motor and ignite the main fuel tank shortly after launch, causing an explosion and killing the seven astronauts onboard. While engineers had previously warned about the risk of this happening, the launch proceeded as scheduled because of a promise to politicians; for the sake of meeting a schedule, quality was compromised.

The London Tower Bridge, Figure 9.1, offers a contrast.2 It opened in 1894, 4 years late and costing nearly twice the estimated £585,000. But more than a century later, it has withstood the test of time. Originally designed and built to enable pedestrians and horse-drawn vehicles to cross the Thames River, it now carries 10,000 vehicles per day and is a major tourist attraction. It has survived floods and pollution—problems its original designers never considered. In terms of time and cost the project was a failure; in terms of quality it has been a raving success.

Figure 9.1 London Tower Bridge.

Source: iStock.

What is Quality?

Quality is meeting specifications or requirements—but it means more than that. While meeting project specifications will usually prevent a customer from taking a contractor to court, it alone cannot ensure the customer will be satisfied with the end result or the contractor will receive gratitude or win repeat business.

Ideally a project aims beyond specifications and tries to fulfill customer expectations—including those not articulated; it aims at delighting the customer. Project managers sometimes assume, wrongly, that customer needs, expectations, and requirements are readily evident or will require little effort to research and specify.

Fitness for Purpose

The term quality implies that a product or deliverable is fit for the intended purpose; this can involve a wide range of criteria such as performance, safety, reliability, ease of handling, maintainability, logistical support, and no harmful environmental impacts. Beyond fitness, however, the customer will also consider a product’s value for money and whether it is priced right for the intended purpose. Optimizing only one aspect of a product—fitness for purpose, value for money, or strategic benefit to the organization—will not necessarily result in an optimal product. The project manager must seek to balance the multiple aspects of a product and define specifications to reflect that balance.

Absence of Defects

Quality also implies an absence of defects, which is why people often associate the terms quality and defect. A defect is a nonconformity—a problem or mistake— something other than what the customer had expected. One way to achieve quality is to identify and correct as many nonconformities as possible—and to identify them as soon as possible. In general, the longer a nonconformity persists before it is discovered, the more costly it is to remedy or remove it. It might be relatively easy and inexpensive to fix a defect in a component part, but it is usually more expensive to fix it after the component has been put into an assembly, and even more expensive after the assembly has been imbedded inside a system. A defect is most expensive when it causes a product or system malfunction or failure while in use by the customer.

But “absence of defects” requires qualification, and the presumption that zero defects equates to high quality is not always true. A quality project is one that satisfies multiple requirements, and devoting too much attention to any particular one, such as eliminating all defects, may detract from fulfilling other more important requirements.3 For example, in most projects the requirements relate to time, cost, and performance. When the schedule must be maintained, trying to remove all defects can prove exceptionally costly. The customer might prefer to keep to the budget and schedule rather than eliminate all defects. Of

course, in some cases it is necessary to try to eliminate every defect.4 Even the most minor defect in an air traffic control system or artificial human heart can result in injury or loss of life. The point is, it depends on the customer. Often the customer prefers a deliverable to be completed on time, at lower cost, and with a few minor defects than completed late, at higher cost, but with no defects.

Good Enough Quality

In removing defects, emphasis is on those that would prevent the system from meeting its most important requirements. This is the concept of “good enough quality”—the default criteria when priorities on performance requirements, time, and cost preclude meeting all the requirements and force the project team into meeting only the most important ones. Says Bach, creating systems “of the best possible quality is a very, very expensive proposition, [though] clients may not even notice the difference between the best possible quality and pretty good quality.”5 The customer, of course, must be able to judge what is “good enough,” and to do that must be constantly updated about project progress, problems, costs, and schedules.

In the ideal case, everyone on the project team contributes to quality; each:

1. Knows what is expected of her 2. Is able and willing to meet those expectations 3. Knows the extent to which she meets the expectations 4. Has the ability and authority to take necessary corrective actions.

Such conditions require quality-focused leadership, training, and motivation efforts. Once everyone starts contributing, however, attention to quality should become automatic and require little influence from the project manager.

What Quality is Not

Quality implies that the product is fit for the purpose. But fit for purpose does not necessarily relate to the product’s expense, reliability, or features, all of which

refer to the product’s grade. In other words, quality and grade are not the same. For example, coal mines produce different grades of coal. The highest grade is used in steelmaking while lower grades are used in chemical products and power plants. Even though coal for a power plant is lower grade than that for steelmaking, it is the appropriate—hence best-quality—coal for the purpose; it would be inappropriate and uneconomical to use higher-grade coal in power plants. Of course, companies that mine the coal should strive for high-quality processes to deliver all grades of coal to meet the specifications of all their customers, including price and delivery specifications.

Quality Movements and Progress

The “quality revolution” started in the 1950s in Japan, in part under the influence of Dr. W. Edwards Deming, an American consultant. He proposed a quality philosophy that included continuous improvement, skills training, leadership at all levels, elimination of dependency on inspections, reliance on single-source rather than many-source suppliers, and use of statistical techniques. Since then a number of other quality movements have come and gone—some that could be described as fads. The most lasting and popular movement since the 1980s is total quality management (TQM). TQM is a set of techniques and more—it is a mindset, an ambitious approach to improving the total effectiveness and competitiveness of an organization. The key elements of TQM are identifying the mission, goals, and objectives of the organization, acting in ways consistent with those goals and objectives, and focusing on customer satisfaction. TQM involves the total organization, including teams of frontline workers and visible support from top management. Quality problems are systematically identified and resolved to continuously improve processes. In projects, this purpose is served by project reviews and closeout sessions, discussed in this and later chapters.

Complementing TQM is the management philosophy of lean production (LP). LP gives recognition to the fact that quality problems typically originate from “broken processes,” and it provides methods and tools to analyze processes and expose and eliminate sources of waste in processes. It includes relatively easy-to- implement methods to improve quality and reduce costs and lead times.6 The

most difficult aspect of implementing LP is developing a culture wherein employees everywhere have the authority and skills to continuously improve their processes—an unusual concept for many organizations. Principles of LP originated at Toyota and have been successfully adopted around the world. In some industries (e.g. autos and electronics) virtually all the big players have adopted lean production. In project environments, LP methods are being applied to product development and construction. Some of these methods are described in Chapter 13.

See Chapter 13

Another quality movement called Six Sigma originated in the 1980s at Motorola and was later popularized by General Electric. The term “Six Sigma” refers to the fact that in a normal distribution, 99.99966 percent of the population falls within −6σ to +6σ of the mean, where “σ” is the standard deviation. If the quality of a process is controlled to the 6σ standard, there would be less than 3.4 parts per million defects in the process—near perfection!

But the Six Sigma movement goes beyond statistics and is a philosophy for reducing process variability. It includes two five-step processes, one for improving existing processes and another for designing new processes and products, both aimed at 6σ quality levels. The first process, called DMAIC for Define, Measure, Analyze, Improve, and Control, involves the steps of defining the best actions to improve a process, implementing those actions, tracking the results, and reducing defects so that fewer outcomes fail to meet specifications. The second process is called DMADV—Define, Measure, Analyze, Design, and Verify. In projects, the Six Sigma approach translates into defining clear deliverables that relate to the mission of the organization and are approved by management. In some companies the DMAIC process is the project methodology and defines the stages of the project.

Project Quality Management

Project quality means quality of the project end-item, deliverable, or product.

Quality of the end-item or product starts with clearly defined system requirements or specifications agreed upon by both contractor and customer. If the contractor feels the customer has provided requirements that are unrealistic, he should review them with the customer and alter them so the desired end result can be achieved realistically. The agreed-upon specifications should reflect the customer’s expectations for the product’s fitness for the intended purpose and any negotiated compromises. Comprehensive specifications for the deliverable should be included in the project scope definition.

Project quality management includes management processes as well as techniques to reduce the risk that products or deliverables will not meet requirements. The following sections discuss these processes and techniques.

9.2 Project Quality Management Processes

Project quality management has three processes: quality planning, quality assurance, and quality control (Figure 9.2). Quality planning guides future quality activities; it sets the requirements and standards to be met and the actions necessary to meet them. Quality assurance performs the planned quality activities and ensures the project utilizes processes necessary to meet quality standards and end-item requirements. Quality control ensures that quality assurance activities are performed according to quality plans and that requirements and standards are being met. Think of quality control as the “medicine” to eliminate existing nonconformities and quality planning and assurance as the “healthy lifestyle” to prevent nonconformities in the first place.

As shown in Figure 9.2, project quality control links quality planning and quality assurance to ensure that quality assurance happens according to the quality plan. Quality assurance aims to ensure appropriate quality standards for a project, and to take advantage of learning opportunities from completed projects to improve on future projects.

Figure 9.2 The project quality management process.

Quality Planning

Quality planning should provide confidence that everything necessary to ensure quality has been taken care of. It has two aspects: (1) establishing quality management procedures and policies for the entire organization and (2) establishing a quality plan as part of the execution plan for each project.

Responsibility for establishing organization-wide policies and procedures to improve project quality typically falls on functional managers, especially the quality manager. Projects often employ quality standards that already exist such as the ISO 9001 standard (a quality management system).7 For design and development projects, this standard prescribes that an organization shall set procedures for (a) the design and development stages; (b) the necessary reviews, verifications, and validations appropriate to each of the stages; and (c) the

responsibilities and authorities for the stages.

Costs of Quality

Since quality is always related to value for the money spent, quality planning should consider the costs and benefits of quality activities. A cost–benefit analysis is performed to evaluate the proposed quality activities. Money spent on quality assurance and control should be justified in terms of expected savings or benefits from fewer or eliminated nonconformities.

The costs of quality are classified as prevention, appraisal and control (costs of conformance), and internal failure and external failure (costs of nonconformance):

1. Prevention: costs of training, design reviews, and activities aimed at preventing errors; includes cost of quality planning.

2. Appraisal and control: costs of evaluating products and processes, including product reviews, audits, tests, and inspections.

3. Internal failure: costs associated with nonconformities discovered by the producer; includes costs for scrap, rework, and retest.

4. External failure: costs incurred as a result of product failures after delivery to the customer; includes costs for replacements, warranty repairs, liability, lost sales, and damaged reputation.

While the costs of quality can be as little as 2 percent of earnings for a company with a good quality management system, it can exceed 20 percent for a company with a poor quality management system.8 It therefore makes sense to invest in a good system, i.e., to spend more on design reviews, audits, training, modeling, and testing so as to spend less on internal and external failures.

For projects, the costs of prevention, appraisal, control, and internal failure are incurred during the project; costs associated with external failure come after the project is completed. The costs of conformance (prevention, appraisal, and control) are among the many the project manager must justify to management and the customer, and include in the project plan and budget.

Project Quality Management Plan

The project quality management plan (quality plan) is an important component of the project execution plan discussed in Chapter 5. A central tenet of what is called “quality by design” is that quality can be planned and that many problems can be prevented by the way it is planned. Creating a quality plan therefore is important to the successful execution of projects.

See Chapter 5

Identifying, scheduling, budgeting, and assigning responsibility for quality assurance and control activities is done utilizing the same principles and methods as for other project activities, discussed in Chapters 4 through 8. The plan addresses the quality management approach of the project, indicates the stakeholders involved and how the project would respond to any changes in customer needs. It typically references relevant organizational policies and procedures (e.g. configuration

See Chapters 4–8

management system and classification of characteristics procedures – both discussed later) and how they would be implemented in the project.

If not covered sufficiently in a project management methodology, the plan should indicate how each of the project phases would be initiated and authorized, and how phases and the entire project would be closed out.

The plan should address all relevant elements indicated in Figure 9.2, including how the project team will ensure that the quality requirements as stated in the specifications and standards would be met. This can typically include:

• Any models to be produced and tested, and associated test specifications, procedures, and reports

• Inspections, equipment required for inspections, calibration of equipment, and required reports

• Final acceptance tests, including when they would take place and test

specifications, procedures and reports • Any required design reviews, the purpose of each, people involved, and

outputs required • Audits • Checklists • Techniques that would be used, e.g. FMEA or control charts.

The plan can also indicate how non-conformances, customer complaints, and corrective actions would be handled. It should clearly indicate the person primarily responsible for each task and the roles and responsibilities of others involved. The responsibility matrix discussed in Chapter 5 can be used for this purpose.

See Chapter 5

Quality Assurance

Project quality assurance relates to the execution of the project quality management plan and aims to reduce the risks of not meeting desired features or performance requirements of deliverables.

As shown in Figure 9.2, quality assurance covers the following:

1. Activities done in a specific project to ensure that requirements are being met and the project is being executed according to the quality plan.

2. Activities that contribute to the continuous improvement of current and future projects and to the project management maturity of the organization.

Quality assurance should provide confidence that everything necessary is being done to ensure the appropriate quality of project deliverables.

Continuous Improvement and Project Post-Completion Reviews

Continuous improvement is the foundation to progress: without it, humankind would not have moved beyond the Stone Age. Project organizations strive to continually improve their technical operations and managerial processes, in part, by conducting a formal post-completion review for every project. The review happens upon completion of the project or, better, upon completion of each phase of the project. Its purpose is to understand what happened and to learn lessons that can be applied to other projects and avoid repeating mistakes.

The project manager’s responsibility during reviews is to facilitate candid and constructive discussion about what happened—what worked and what did not, and to make sure that everyone participating is heard. The discussion is formally documented and a list of lessons learned created. This process, though essential for continuous improvement, is often neglected because people lose interest as the project winds down or as they become busy on new, upcoming projects. As a result, organizations repeat mistakes, reinvent the wheel, and do not learn from their experiences.9 Post-completion reviews are covered more in Chapter 12; they play an important role in knowledge management, discussed in Chapter 17.

See Chapters 12 and 17

Quality Control

Quality control is the ongoing process of monitoring and assessing work, and taking corrective action so as to achieve the planned quality outcomes (requirements and specifications). It also verifies that quality assurance activities are being performed as specified in the quality plan. Quality control is one aspect of project control—a topic of Chapter 11 but included here for continuity.

See Chapter 11

Quality control can be contrasted to scope verification: whereas scope verification refers to the acceptability of project deliverables by the customer, quality control refers to conformance to specifications as set by the contractor. Scope verification includes verifying the acceptability of specifications and

standards, but quality control refers to verifying adherence to previously-set specifications and standards.

The quality control process includes inspections to verify that deliverables are meeting specifications, plus acceptance tests before handover of deliverables to the customer. In the event that a minor feature does not meet specification, the contractor might request a waiver or deviation. A waiver applies to an unplanned condition that is discovered only after the item has been produced. It authorizes a temporary nonconformity, such as a scratch discovered on the paint of a hardware item. A deviation is also a temporary departure from specification, but it is discovered before production. For example, if a specified material is temporarily unavailable, the contractor can apply for a deviation to allow an alternative material to be used. A third form of deviation from specification is a modification; this is a change to specification that is considered permanent.

Control activities as illustrated in Figure 9.2 include both planned quality control activities and ad hoc problem solving. Planned activities include, for example, inspections on a construction site, tests on a product component, or audits to ensure a supplier is using correct materials. Ad hoc problem solving refers to handling problems and risks as they emerge. Techniques for analysis and problem solving are discussed later.

Quality control cannot happen in isolation; it must be integrated with scope control, cost control, progress control, and risk control. Thus, in the same way that the quality plan should be integrated with other aspects of the project plan, quality control should be integrated with the other aspects of project control.

Quality of Procured Items

Quality requirements for off-the-shelf items procured from suppliers are set by industry standards, in which case the main criterion for choosing a supplier is price. To buy a batch of standard items such as bolts, the procurement officer obtains price quotes from multiple suppliers and picks the lowest. When the batch arrives, an inspector checks the bolts to determine if they are acceptable. But to procure a system or item that must be newly developed, there likely is no industry standard. In that case the purchaser has to work with the supplier and

assist in planning for the quality assurance and control to assure the item meets specifications.

Of course, even for procurement of standard items, far better than selecting the lowest price supplier is selecting one that has proven capability and willingness to meet the contractor’s requirements, and then seeking to develop a mutually beneficial long-term relationship with the supplier. The two parties work together as partners and share responsibility for each other’s success. Establishing this kind of relationship is not always easy, especially when the supplier is much larger than the contractor or does not value the relationship or consider the contracted work a priority.

Contractors often invest heavily to make sure they can procure subsystems and components of the appropriate quality. A contractor often has a special vendor quality section within its procurement division to manage quality assurance of all its procured items—including their development and manufacture or construction. The purpose of this section is to assist in selecting suppliers, monitor suppliers’ processes to ensure quality, and perform inspections and acceptance tests of purchased items. Other responsibilities are described next.

Example 9.1: Companies Working Together for Quality Assurance and Control

Company A develops and manufactures mining vehicles. It is working on a new vehicle and must choose a supplier to develop, manufacture, and support a transmission for the vehicle. The company’s vendor quality section and procurement staff review proposals from supplier candidates and select Company B to provide the transmissions. Company A’s engineering division develops a functional specification for the transmission that includes performance characteristics, maintenance requirements, interfaces with other parts of the vehicle, and test requirements. Its vendor quality section then works with Company B’s engineers to ensure they will be using appropriate processes for cost- effective compliance with the specification, and that they will test all transmissions according to Company A’s functional specification for compliance to performance before shipment.

9.3 Techniques for Quality Assurance in System Development

This section further explains the items in Figure 9.2. In phased project planning, authorization of a phase implies that plans for the phase have satisfied pre- specified criteria, including that the plans include sufficient measures for quality assurance. System developers employ a variety of such measures, as discussed in this section.

Configuration Management10

During design and development of a system, vast amounts of information are generated for use in the design process and later in manufacturing (or construction), maintenance, and support. The information can include hundreds or thousands of documents (specifications, schematics, drawings, etc.), each likely to be modified in some way during the project. Keeping track of all the changes and knowing which version is the most current for every item can be difficult. Thus, any project aimed at delivering a technical product needs a system or process to keep up with and manage all the information; such is the purpose of configuration management.

Configuration management includes policies and procedures for monitoring and tracking design information and changes, and ensuring that everyone involved with the project (and, later, the end-item’s operation) has the most current information. Policies and procedures that form the configuration management system for a project should be included in the quality plan. As with all procedures, the best configuration management system is whatever permits the desired level of control and is the simplest to implement. The two main aspects of configuration management are configuration identification and configuration control.

Configuration Identification

Configuration identification is an inherent part of systems design and involves defining a system’s overall structure and its subsystems and components. Mentioned in Chapter 2, any subsystem, component,

See Chapter 2

or part that is to be tracked and controlled as an individual entity throughout a system’s life cycle is identified as a configuration item (CI). A CI can be a piece of hardware, a manual, a parts list, a software package, or even a service. Any part of the system that is procured is also treated as a CI. Every physical and functional characteristic that defines and is important for controlling the CI is identified and documented. Ultimately, every functional and physical element of the end-item system should be associated in some way with a CI, either as a CI in its own right or as a component within a subsystem that has been identified as a CI. Ideally, each CI is small enough to be designed, built, and tested by a small team.

The master copy (electronic or paper) of the configuration documents for every CI are retained in a single, secure location (the “configuration center”) and managed by someone not involved in the functions of design, construction, manufacture, or maintenance. (Documentation about design premises, assumptions, and calculations are not considered configuration documents and are retained elsewhere by the design authority.)

Any modifications, waivers, or deviations to a CI are recorded so that all CI documents reflect the “as-built” status of the system. In the case of a deliverable such as a building, ship, or other one-of-a-kind system that becomes operational, the “as-built” specification will later be used in its operation and maintenance. Where multiple units are produced (e.g. cars, airplanes, appliances) and modifications and improvements are introduced over time, the specific configuration for each individually produced unit must be known, which requires that each specific CI in the product must be traceable to its specific “as-built” specifications. This is necessary so that, for example, the correct spare parts, training, and operating manuals can be supplied, and problems can be traced and

analyzed in the event of accidents, customer complaints, or claims regarding product liability. This concept of “traceability” was introduced in Chapter 4 and is illustrated in the following example.

See Chapter 4

Example 9.2: Traceability and the Apollo Spacecraft11

To establish the reliability of an item, either many units of the item are tested until one fails, or the required reliability is designed-in through methods of engineering analysis. Regardless, to assure reliability everything about the item must be known—its manufacturing process, the composition of its parts and materials, and even the sources of those materials. For the Apollo space mission the goal of achieving mission success was set at 99 percent and crew survivability at 99.9 percent. To meet such high-level goals, every CI (subsystem, component, part, etc.) as it moved through the design and manufacturing process was accompanied with a package of documents that established its genealogy and pedigree. The saying went, “If you ordered a piece of plywood, you wanted to know from which tree it came.” Half-inch bolts for the Apollo spacecraft involved an 11-step manufacturing process with certification tests at each step. Every bolt was subjected to rigorous testing, as were the steel rods from which they were made, the billets from which the rods were extruded, and the ingots from which the billets were forged. Everything about the processes and tests for the bolts was documented, including the source of the iron for the bolts— Minnesota—and even the mine and the mine shaft. Such extreme tracking and control is necessary to ensure high reliability and enable problem diagnosis in case things go wrong. But it comes with a price though, which is why bolts available for 59 cents at the hardware store cost $8 or $9 apiece on rockets and spacecraft.

Configuration Control

The topic of configuration control, the second aspect of configuration management, relates more to quality control than quality assurance, but we cover it here for the sake of continuity. The design of a system is normally specified by means of several documents such as performance specifications, drawings, manuals, and testing procedures that are generated during the design process. As the design evolves these documents are subject to change, so a scheme is needed to manage and keep track of the changes. Such is the purpose of configuration control.

Configuration control is based on the following principles:

1. Any organization or individual may request a modification, waiver, or deviation.

2. The proposed change and its motivation are documented. Standard documents exist for this purpose: for modifications, the document is called a change proposal, change request, change order, or variation order.

3. The impact of the proposed change on system performance, safety, and the environment is evaluated; so is its impact on other hardware items, software, manuals, and methods of manufacturing or construction and maintenance.

4. The change is assessed for feasibility, which includes estimating the resources needed to implement the change and the impact of the change on schedules.

5. The group responsible for approving or rejecting the change is the configuration board (CB) or a configuration control board (CCB). The board usually includes the chief designer and representatives from manufacturing or construction, maintenance, and other important stakeholders, and often is chaired by the project manager or program manager.

6. Upon approval of the proposed change, the work to implement the change is planned. The plan includes actions with regard to the disposition of anything that might be affected by the change, including spare parts, equipment and processes for manufacturing or construction, and manuals

and other documentation. 7. The implemented change is monitored and controlled to ensure it

complies with the approved change proposal.

Change requests are sometimes classified as Class I or Class II. Class I requests can be approved by the contractor or the developer; Class II must be approved by the customer.

Configuration control is an aspect of project control and, in particular, change control, both discussed in Chapter 11.

See Chapter 11

Design Reviews

The project manager must ensure that the proposed design is acceptable in all respects; such is the purpose of design reviews—to ensure that the users’ requirements and assumptions have been correctly identified and that the proposed design is able to meet the requirements in an appropriate way. Design reviews (not to be confused with general project reviews, described in Chapter 12) provide confirmation of design assumptions (e.g. load conditions), data used in the design process, and design calculations. Ideally they ensure that all important life-cycle aspects of the end-item have been addressed and pose no unacceptable risks. In particular, reviews check the designs for:

See Chapter 12

1. omissions or errors 2. compliance to regulations, codes, specifications, and standards 3. cost of ownership 4. safety and product liability 5. reliability 6. availability 7. ability to be constructed or manufactured (manufacturability)

8. shelf life 9. operability 10. maintainability 11. intellectual property rights 12. ergonomics.

The reviews involve representatives from all disciplines, functions, users who will be connected to the deliverable throughout its life cycle, and, often, outside designers and subject matter experts. (This relates to concurrent engineering, discussed in Chapters 4 and 14.) For example, the design review for a chemical plant, mine, or factory would include representatives from:

See Chapter 4 and Chapter 14

• The organization that will operate the facility • The technical support area that will be maintaining the facility • The construction company • The marketing, procurement, legal services, and quality areas that wil