Week 8 Assignment 4

Contemporary Project Management Timothy J. Kloppenborg Th ird Edition

Contemporary Project M anagem

ent K

loppenborg

Th ird Edition

To learn more about Cengage Learning, visit www.cengage.com

Purchase any of our products at your local college store or at our preferred online store www.cengagebrain.com

Contemporary Project Management, 3e includes both time-tested and cutting-edge project management techniques that are invaluable to you as a student or practitioner. Check out some of the features of this text:

• Agile Approach to Project Planning and Management. The text fully integrates the agile approach and uses a margin icon and alternate font color to emphasize the difference between agile and traditional project management methods.

• PMBOK ® Guide Approach. This edition covers all knowledge areas and processes from the fi fth edition of the PMBOK® Guide and now includes ten PMBOK® Guide-type questions at the end of each chapter. All glossary defi nitions also refl ect the fi fth edition of the PMBOK® Guide.

• Real Project Management Examples. Each chapter contains examples from practitioners at actual companies in the U.S. and abroad.

• Actual Projects as Learning Vehicles. At the end of each chapter, there is an example project with a list of deliverables. Microsoft® Word and Excel templates for many project management techniques are also available on the textbook companion site.

• Full Integration of Microsoft® Project Professional 2013. Using screen captures, the text shows step-by-step instructions for automating project management techniques and processes in Microsoft® Project 2013.

Contemporary Project Management Timothy J. Kloppenborg

Need a study break? Get a break on the study materials designed for your course!

Find Flashcards, Study Guides, Solutions Manuals and more . . . Visit www.cengagebrain.com/studytools today to find discounted study tools!

MS Project 2013 Instructions in Contemporary Project Management 3e

Chapter MS Project

4 Introduction to MS Project 2013

Toolbars, ribbons, and window panes

Initialize MS Project for Use

Auto schedule, start date, identifying information, summary row

Create Milestone Schedule

Key milestones, projected finish dates, information

6 Set up Work Breakdown Structure (WBS)

Understand WBS definitions and displays, enter summaries, create the outline, Insert row number column, Hide/show desired amount of detail

7 Set up Schedule in MS Project

Define organization’s holidays, turn off change highlighting, understand types of project data

Build Logical Network Diagram

Enter tasks and milestones, define dependencies, understand network

diagram presentation, verify accuracy

Understand Critical Path

Assign duration estimates, identify critical path

Display and Print Schedules

8 Define Resources

Resource views, max units, resource calendars

Assigning Resources

In split view enter work, select resource, modify assignments

Identify Over allocated Resources

Resource usage and Detailed Gantt views together

Dealing with Over Allocations

Manual leveling and judgment

9 Develop Bottom-up Project Budget

Assignment costs, activity costs, various cost perspectives

Develop Summary Project Budget

11 Baseline Project Plan

14 Report Progress

How MS Project recalculates based upon actual performance, current and future impacts of variances, define the performance update process (what, when, and how)

Update the Project Schedule

Acquire performance data, set and display status date, Enter duration-

based performance data, reschedule remaining work, revise estimates

15 Close Project

Complete schedule, archive schedule, capture and publish lessons learned

PMBOK® Guide 5e Coverage in Contemporary Project Management 3e The numbers refer to the text page where the process is defined.

Project management (PM) processes and knowledge areas 9 Project life cycle 6-8, 62-64 Projects and strategic planning 28-31 Organizational influences 54-61 Portfolio and program management 31-34 Stakeholders 65-74

PMBOK® Guide 5th ed. Coverage

Knowledge Areas

Initiating Process Group Planning Process Group

Executing Process Group

Monitoring & Controlling Process Group

Closing Process Group

Project Integration Management

Develop Project charter 84-99

Develop Project Management Plan 116-118, 306-308

Direct and Manage Project Work 383-384

Monitor and Control Project Work 385-386 Perform Integrated Change Control 158-160, 386-387

Close Project or Phase 425-430

Project Scope Management

Plan Scope Management 146 Collect Requirements 146-148 Define Scope 148-150 Create WBS 150-158

Validate Scope 422 Control Scope 400-401

Project Time Management

Plan Schedule Management 172 Define Activities 175-176 Sequence Activities 176-181 Estimate Activity Resources 211-212 Estimate Activity Durations 181-184 Develop Schedule 184-192

Control Schedule 172, 401-405

Project Cost Management

Plan Cost Management 246 Estimate Costs 246-256 Determine Budget 256-259

Control Costs 259, 401-405

Project Quality Management

Plan Quality Management 302-306

Perform Quality Assurance 392-393

Control Quality 306, 393-400

Project Human Resources Management

Plan Human Resource Management 212-216

Aquire Project Team 348-350 Develop Project Team 350-364 Manage Project Team 364-367

Project Communications Management

Plan Communications Management 126-130

Manage Communications 388-391

Control Communications 391

Project Risk Management

PlanRiskManagement 270-275 Identify Risks 95, 275-277 Perform Qualitative Risk Analysis 95-96, 277-280 Perform Quantitative Risk Analysis 280 Plan Risk Responses 96, 281-283

Control Risks 387-388

Project Procurement Management

Plan Procurement Management 324-327, 331-333

Conduct Procurements 327-331

Control Procurments 334

Close Procurements 424-425

Project Stakeholder Management

Identify Stakeholders 97, 119-123

Plan Stakeholder Management 124-126

Manage Stakeholder Engagement 123-124, 367-368

Control Stakeholder Engagement 368-369

Source: Adapted from A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, Inc., 2013): 43.

Contemporary Project Management Organize / Plan / Perform

THIRD EDITION

TIMOTHY J. KLOPPENBORG Xavier University

Australia • Brazil • Japan • Korea • Mexico • Singapore • Spain • United Kingdom • United States

Contemporary Project Management: Organize / Plan / Perform, Third Edition

Timothy J. Kloppenborg

Product Director: Joe Sabatino

Product Manager: Clara Goosman

Content Developer: Kendra Brown

Product Assistant: Brad Sullender

Marketing Manager: Heather Mooney

Project Manager: Vanavan Jayaraman, Integra Software Services Pvt. Ltd.

Media Developer: Chris Valentine

Manufacturing Planner: Ron Montgomery

Sr. Rights Acquisitions Specialist: John Hill

Art and Cover Direction, Production Management, and Composition: Integra Software Services Pvt. Ltd.

Cover Images: © Laura Doss/Fancy/Corbis © R. Hamilton Smith/AgStock Images/ Corbis

© 2015, 2012 Cengage Learning

ALL RIGHTS RESERVED. No part of this work covered by the copyright herein may be reproduced, transmitted, stored, or used in any form or by any means graphic, electronic, or mechanical, including but not limited to photocopying, recording, scanning, digitizing, taping, web distribution, information networks, or information storage and retrieval systems, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the publisher.

For product information and technology assistance, contact us at Cengage Learning Customer & Sales Support, 1-800-354-9706.

For permission to use material from this text or product, submit all requests online at www.cengage.com/permissions.

Further permissions questions can be e-mailed to [email protected]

Library of Congress Control Number: 2013948555

ISBN-13: 978-1-285-43335-6

ISBN-10: 1-285-43335-1

Cengage Learning 200 First Stamford Place, 4th Floor Stamford, CT 06902 USA

Cengage Learning is a leading provider of customized learning solutions with office locations around the globe, including Singapore, the United Kingdom, Australia, Mexico, Brazil, and Japan. Locate your local office at www.cengage.com/global.

Cengage Learning products are represented in Canada by Nelson Education, Ltd.

To learn more about Cengage Learning Solutions, visit www.cengage.com.

Purchase any of our products at your local college store or at our preferred online store www.cengagebrain.com.

Printed in the United States of America 1 2 3 4 5 6 7 18 17 16 15 14 13

WCN: 02-200-208

Brief Contents Project Deliverables xiii Preface xv About the Author xxii

PART 1 Organizing Projects

1 Introduction to Project Management 2

2 Project Selection and Prioritization 26

3 Organizational Capability: Structure, Culture, and Roles 52

4 Chartering Projects 82

PART 2 Planning Projects

5 Stakeholder Analysis and Communication Planning 114

6 Scope Planning 144

7 Scheduling Projects 170

8 Resourcing Projects 208

9 Budgeting Projects 244

10 Project Risk Planning 268

11 Project Quality Planning and Project Kickoff 290

PART 3 Performing Projects

12 Project Supply Chain Management 320

13 Leading and Managing Project Teams 346

14 Determining Project Progress and Results 380

15 Finishing the Project and Realizing the Benefits 420

Appendix A PMP® and CAPM® Exam Prep Suggestions 439 Appendix B Strengths Themes as Used in Project Management (available on the

textbook companion site) Glossary Terms from the PMBOK® Guide 443 Index 451

iii

Contents

Project Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

PART 1 Organizing Projects

CHAPTER 1 Introduction to Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1 What Is a Project? 4

1.2 History of Project Management 4

1.3 How Can Project Work Be Described? 5 1.3a Projects versus Operations 5 / 1.3b Soft Skills and Hard Skills 5 / 1.3c Authority

and Responsibility 6 / 1.3d Project Life Cycle 6

1.4 Understanding Projects 8 1.4a Project Management Institute 8 / 1.4b Project Management Body of Knowledge

(PMBOK®) 9 / 1.4c Selecting and Prioritizing Projects 10 / 1.4d Project Goals and Constraints 10 / 1.4e Defining Project Success and Failure 11 / 1.4f Using Microsoft Project to Help Plan and Measure Projects 12 / 1.4g Types of Projects 12 / 1.4h Scalability of Project Tools 14

1.5 Project Roles 14 1.5a Project Executive-Level Roles 14 / 1.5b Project Management-Level Roles 14 /

1.5c Scrum Master 15 / 1.5d Project Associate-Level Roles 15

1.6 Overview of the Book 15 1.6a Part 1: Organizing and Initiating Projects 15 / 1.6b Part 2: Planning Projects 17 /

1.6c Part 3: Performing Projects 18

Summary 19

Key Terms from the PMBOK® Guide 19 Chapter Review Questions 20

Discussion Questions 20

PMBOK® Guide Questions 20 Example Project Instructions 21

References 22

Endnotes 22

Project Management in Action: Using Appreciative Inquiry to Understand Project Management 24

CHAPTER 2 Project Selection and Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1 Strategic Planning Process 28 2.1a Strategic Analysis 28 / 2.1b Guiding Principles 28 / 2.1c Strategic Objectives 31 /

2.1d Flow-Down Objectives 31

2.2 Portfolio Management 31 2.2a Portfolios 32 / 2.2b Programs 32 / 2.2c Projects and Subprojects 33 /

2.2d Assessing an Organization’s Ability to Perform Projects 34 / 2.2e Identifying

iv

Potential Projects 35 / 2.2f Methods for Selecting Projects 36 / 2.2g Using a Cost-Benefit Analysis Model to Select Projects 36 / 2.2h Using a ScoringModel to Select Projects 38 / 2.2i Prioritizing Projects 40 / 2.2j Resourcing Projects 41

2.3 Securing Projects 41 2.3a Identify Potential Project Opportunities 42 / 2.3b Determine Which Opportunities to

Pursue 42 / 2.3c Prepare and Submit a Project Proposal 43 / 2.3d Negotiate to Secure the Project 44

Summary 44

Key Terms from the PMBOK® Guide 45 Chapter Review Questions 45

Discussion Questions 45

PMBOK® Guide Questions 46 Exercises 46

Example Project Instructions 47

References 47

Endnotes 48

Project Management in Action: Prioritizing Projects at D. D. Williamson 49

CHAPTER 3 Organizational Capability: Structure, Culture, and Roles . . . . . . . . . . . . . . . . . . . . . 52

3.1 Types of Organizational Structures 54 3.1a Functional 54 / 3.1b Projectized 55 / 3.1c Matrix 56

3.2 Organizational Culture and Its Impact on Projects 59 3.2a Culture of the Parent Organization 60 / 3.2b Project Cultural Norms 61

3.3 Project Life Cycles 62 3.3a Define-Measure-Analyze-lmprove-Control (DMAIC) Model 62 / 3.3b Research and

Development (R&D) Project Life Cycle Model 62 / 3.3c Construction Project Life Cycle Model 63 / 3.3d Agile Project Life Cycle Model 63

3.4 Agile Project Management 64

3.5 Project Executive Roles 65 3.5a Steering Team 65 / 3.5b Sponsor 66 / 3.5c Customer 67 / 3.5d Chief Projects

Officer/Project Management Office 69

3.6 Project Management Roles 69 3.6a Functional Manager 69 / 3.6b Project Manager 70 / 3.6c Scrum Master 72 /

3.6d Facilitator 72

3.7 Project Team Roles 73 3.7a Core Team Members 73 / 3.7b Subject Matter Experts 74

Summary 74

Key Terms from the PMBOK® Guide 75 Chapter Review Questions 75

Discussion Questions 76

PMBOK® Guide Questions 76 Exercises 77

Example Project Instructions 77

References 77

Endnotes 78

Project Management in Action: Project Leadership Roles at TriHealth 79

Contents v

CHAPTER 4 Chartering Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.1 What Is a Project Charter? 84

4.2 Why Is a Project Charter Used? 85

4.3 When Is a Charter Needed? 85

4.4 Typical Elements in a Project Charter 87 4.4a Title 87 / 4.4b Scope Overview 87 / 4.4c Business Case 88 /

4.4d Background 88 / 4.4e Milestone Schedule with Acceptance Criteria 88 / 4.4f Risks, Assumptions, and Constraints 89 / 4.4g Resource Estimates 90 / 4.4h Stakeholder List 90 / 4.4i Team Operating Principles 90 / 4.4j Lessons Learned 91 / 4.4k Signatures and Commitment 91

4.5 Constructing a Project Charter 91 4.5a Scope Overview and Business Case Instructions 91 / 4.5b Background

Instructions 92 / 4.5c Milestone Schedule with Acceptance Criteria Instructions 92 / 4.5d Risks, Assumptions, and Constraints Instructions 95 / 4.5e Resources Needed Instructions 96 / 4.5f Stakeholder List Instructions 97 / 4.5g Team Operating Principles Instructions 97 / 4.5h Lessons Learned Instructions 98 / 4.5i Signatures and Commitment Instructions 98

4.6 Ratifying the Project Charter 99

4.7 Starting a Project using Microsoft Project 99 4.7a MS Project 2013 Introduction 99 / 4.7b Initialize Microsoft Project 2013 for General

Use 101 / 4.7c Initialize a Project 102 / 4.7d Construct a Milestone Schedule 104

Summary 105

Key Terms from the PMBOK® Guide 105 Chapter Review Questions 105

Discussion Questions 105

PMBOK® Guide Questions 106 Exercises 107

Example Project 107

References 107

Endnotes 108

Project Management in Action: Information Systems Enhancement Project Charter 108

PART 2 Planning Projects

CHAPTER 5 Stakeholder Analysis and Communication Planning . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.1 Develop the Project Management Plan 116

5.2 Identify Stakeholders 119 5.2a Find Stakeholders 119 / 5.2b Analyze Stakeholders 120 / 5.2c Document

Stakeholders 121

5.3 Build Relationships 123 5.3a Relationship Building within the Core Team 124 / 5.3b Relationship Building with

All Other Stakeholders 124

5.4 Plan Communications Management 126 5.4a Purposes of a Project Communications Plan 126 / 5.4b Communications Plan

Considerations 126 / 5.4c Communications Matrix 128 / 5.4d Knowledge Management 129

vi Contents

5.5 Project Meeting Management 130 5.5a Improving Project Meetings 130 / 5.5b Issues Management 132

5.6 Communications Needs of Global and Virtual Project Teams 134 5.6a Virtual Teams 134 / 5.6b Cultural Differences 135 / 5.6c Countries and Project

Communication Preferences 135

5.7 Communications Technologies 136 5.7a Current Technology Types 136

Summary 137

Key Terms from the PMBOK® Guide 137 Chapter Review Questions 137

Discussion Questions 138

PMBOK® Guide Questions 138 Example Project 139

References 139

Endnotes 140

Project Management in Action: Project Communication Planning for a Distributed Project 141

CHAPTER 6 Scope Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

6.1 Plan Scope Management 146

6.2 Collect Requirements 146 6.2a Gather Stakeholder Input 147

6.3 Define Scope 148 6.3a Reasons to Define Scope 148 / 6.3b How to Define Scope 149 / 6.3c How to

Define Scope in Agile Projects 150

6.4 Work Breakdown Structure (WBS) 150 6.4a What Is the WBS? 151 / 6.4b Why Use a WBS? 151 / 6.4c WBS Formats 152 /

6.4d Work Packages 154 / 6.4e How to Construct a WBS 155

6.5 Establish Change Control 158

6.6 Using MS Project for Work Breakdown Structures (WBS) 160 6.6a Set Up the WBS 161

Summary 165

Key Terms from the PMBOK® Guide 166 Chapter Review Questions 166

Discussion Questions 166

Exercises 167

PMBOK® Guide Questions 167 Example Project 168

References 168

Endnotes 168

Project Management in Action: Work Breakdown Structure Template 169

CHAPTER 7 Scheduling Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

7.1 Plan Schedule Management 172

7.2 Purposes of a Project Schedule 173

7.3 Historical Development of Project Schedules 173

Contents vii

7.4 How Project Schedules Are Limited and Created 174

7.5 Define Activities 175

7.6 Sequence Activities 176 7.6a Leads and Lags 179 / 7.6b Alternative Dependencies 180

7.7 Estimate Activity Duration 181 7.7a Problems and Remedies in Duration Estimating 182 / 7.7b Learning Curves 182

7.8 Develop Project Schedules 184 7.8a Two-Pass Method 185 / 7.8b Enumeration Method 189

7.9 Uncertainty in Project Schedules 190 7.9a Program Evaluation and Review Technique 190 / 7.9b Monte Carlo Simulation 191

7.10 Show the Project Schedule on a Gantt Chart 192

7.11 Using Microsoft Project for Critical Path Schedules 193 7.11a Set Up the Project Schedule 194 / 7.11b Build the Logical Network Diagram 196 /

7.11c Understand the Critical Path 199 / 7.11d Display and Print Schedules with MS Project 199

Summary 199

Key Terms from the PMBOK® Guide 200 Chapter Review Questions 200

Discussion Questions 201

Exercises 201

PMBOK® Guide Questions 202 Example Project 203

References 203

Endnotes 204

Project Management in Action: Bank Project Schedule 205

CHAPTER 8 Resourcing Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

8.1 Abilities Needed when Resourcing Projects 210 8.1a The Science and Art of Resourcing Projects 210 / 8.1b Considerations when

Resourcing Projects 210 / 8.1c Activity- versus Resource-Dominated Schedules 211

8.2 Estimate Resource Needs 211

8.3 Plan Human Resource Management 212 8.3a Identify Potential Resources 212 / 8.3b Determine Resource Availability 213 /

8.3c Decide Timing Issues when Resourcing Projects 214

8.4 Project Team Composition Issues 215 8.4a Cross-Functional Teams 215 / 8.4b Co-Located Teams 215 / 8.4c Virtual

Teams 215 / 8.4d Outsourcing 215

8.5 Assign a Resource to Each Activity 216 8.5a Show Resource Responsibilities on RACI Chart 216 / 8.5b Show Resource

Assignments on Gantt Chart 216 / 8.5c Summarize Resource Responsibilities by Time Period with Histogram 218

8.6 Dealing with Resource Overloads 219 8.6a Methods of Resolving Resource Overloads 219

8.7 Compress the Project Schedule 222 8.7a Actions to Reduce the Critical Path 222 / 8.7b Crashing 223 / 8.7c Fast

Tracking 226

viii Contents

8.8 Alternative Scheduling Methods 227 8.8a Critical Chain Project Management (CCPM) 227 / 8.8b Reverse Phase

Schedules 228 / 8.8c Rolling Wave Planning 228 / 8.8d Agile Project Planning 229 / 8.8e Auto/Manual Scheduling 229

8.9 Using MS Project for Resource Allocation 229 8.9a Step 1: Defining Resources 229 / 8.9b Setting Up a Resource Calendar 231 /

8.9c Step 2: Assigning Resources 231 / 8.9d Step 3: Finding Overallocated Resources 233 / 8.9e Step 4: Dealing with Overallocations 235

Summary 236

Key Terms from the PMBOK® Guide 237 Chapter Review Questions 237

Discussion Questions 237

Exercises 238

PMBOK® Guide Questions 238 Example Project 239

References 239

Endnotes 240

Project Management in Action: Managing Software Development with Agile Methods and Scrum 240

CHAPTER 9 Budgeting Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

9.1 Plan Cost Management 246

9.2 Estimate Cost 246 9.2a Types of Cost 247 / 9.2b Accuracy and Timing of Cost Estimates 250 /

9.2c Methods of Estimating Costs 251 / 9.2d Project Cost Estimating Issues 253

9.3 Determine Budget 256 9.3a Aggregating Costs 257 / 9.3b Analyzing Reserve Needs 258 / 9.3c Determining

Cash Flow 258

9.4 Establishing Cost Control 259

9.5 Using MS Project for Project Budgets 260 9.5a Develop Bottom-Up Project Budget 260 / 9.5b Develop Summary Project

Budget 261

Summary 263

Key Terms from the PMBOK® Guide 263 Chapter Review Questions 263

Discussion Questions 263

Exercises 264

PMBOK® Guide Questions 264 Example Project 265

References 265

Endnotes 266

Project Management in Action: The Value of Budget Optimization 266

CHAPTER 10 Project Risk Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

10.1 Plan Risk Management 270 10.1a Roles and Responsibilities 272 / 10.1b Categories and Definitions 272

Contents ix

10.2 Identify Risks 275 10.2a Information Gathering 275 / 10.2b Reviews 275 / 10.2c Understanding

Relationships 276 / 10.2d Risk Register 276

10.3 Risk Analysis 277 10.3a Perform Qualitative Risk Analysis 277 / 10.3b Perform Quantitative Risk

Analysis 280 / 10.3c Risk Register Updates 280

10.4 Plan Risk Responses 281 10.4a Strategies for Responding to Risks 281 / 10.4b Risk Register Updates 283

Summary 284

Key Terms from the PMBOK® Guide 284 Chapter Review Questions 284

Discussion Questions 285

Exercises 285

PMBOK® Guide Questions 285 Example Project 286

References 287

Endnotes 287

Project Management in Action: Risk Management on a Satellite Development Project 288

CHAPTER 11 Project Quality Planning and Project Kickoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Quality and Risk 291

11.1 Development of Contemporary Quality Concepts 292 11.1a Quality Gurus 292 / 11.1b Total Quality Management/Malcolm Baldrige 293 /

11.1c ISO 9001:2008 293 / 11.1d Lean Six Sigma 295

11.2 Core Project Quality Concepts 296 11.2a Stakeholder Satisfaction 296 / 11.2b Process Management 297 / 11.2c Fact-Based

Management 299 / 11.2d Empowered Performance 301 / 11.2e Summary of Core Concepts 302

11.3 Plan Quality Management 302 11.3a Quality Policy 303 / 11.3b Quality Management Plan Contents 305 /

11.3c Quality Baseline 305 / 11.3d Process Improvement Plan 305 / 11.3e Quality Assurance 305 / 11.3f Control Quality 306

11.4 Project Quality Tools 306

11.5 Develop Project Management Plan 306 11.5a Resolve Conflicts 307 / 11.5b Establish Configuration Management 308 /

11.5c Apply Sanity Tests to All Project Plans 308

11.6 Kickoff Project 308 11.6a Preconditions to Meeting Success 309 / 11.6b Meeting Activities 309

11.7 Baseline and Communicate Project Management Plan 309

11.8 Using MS Project for Project Baselines 311 11.8a Baseline the Project Plan 311 / 11.8b First Time Baseline 312 / 11.8c Subsequent

Baselines 312

Summary 312

Key Terms from the PMBOK® Guide 313 Chapter Review Questions 313

Discussion Questions 314

Exercises 314

PMBOK® Guide Questions 314

x Contents

Example Project 315

References 316

Endnotes 316

Project Management in Action: Quality Planning at GTC 317

PART 3 Performing Projects

CHAPTER 12 Project Supply Chain Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

12.1 Introduction to Project Supply Chain Management 322 12.1a SCM Components 323 / 12.1b SCM Factors 323 / 12.1c SCM Decisions 324 /

12.1d Project Procurement Management Processes 324

12.2 Plan Procurement Management 324 12.2a Outputs of Planning 325 / 12.2b Make-or-Buy Decisions 325

12.3 Conduct Procurements 327 12.3a Sources for Potential Suppliers 327 / 12.3b Information for Potential Suppliers 327 /

12.3c Approaches Used When Evaluating Prospective Suppliers 328 / 12.3d Supplier Selection 329

12.4 Contract Types 331 12.4a Fixed-Price Contracts 331 / 12.4b Cost-Reimbursable Contracts 332 /

12.4c Time and Material (T&M) Contracts 333

12.5 Control Procurements 334

12.6 Improving Project Supply Chains 334 12.6a Project Partnering and Collaboration 334 / 12.6b Third Parties 338 / 12.6c Lean

Purchasing 338 / 12.6d Sourcing 338 / 12.6e Logistics 339 / 12.6f Information 339

Summary 339

Key Terms from the PMBOK® Guide 340 Chapter Review Questions 340

Discussion Questions 340

PMBOK® Guide Questions 341 Exercises 341

Example Project 342

References 342

Endnotes 343

Project Management in Action: Implications for Project Management in a Networked Organization Model 343

CHAPTER 13 Leading and Managing Project Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

13.1 Acquire Project Team 348 13.1a Preassignment of Project Team Members 348 / 13.1b Negotiation for Project Team

Members 349 / 13.1c On-Boarding Project Team Members 350

13.2 Develop Project Team 350 13.2a Stages of Project Team Development 351 / 13.2b Characteristics of High-Performing

Project Teams 353 / 13.2c Assessing Individual Member Capability 355 / 13.2d Assessing Project Team Capability 355 / 13.2e Building Individual and Project Team Capability 358 / 13.2f Establishing Project Team Ground Rules 360

Contents xi

13.3 Manage Project Team 364 13.3a Project Manager Power and Leadership 364 / 13.3b Assessing Performance of

Individuals and Project Teams 366 / 13.3c Project Team Management Outcomes 366

13.4 Manage and Control Stakeholder Engagement 367

13.5 Managing Project Conflicts 369 13.5a Sources of Project Conflict 369 / 13.5b Conflict Resolution Process and Styles 370 /

13.5c Negotiation 371

Summary 372

Key Terms from the PMBOK® Guide 373 Chapter Review Questions 373

Discussion Questions 374

PMBOK® Guide Questions 374 Example Project 375

References 375

Endnotes 376

Project Management in Action: Centralizing Planning and Control in a Large Company After Many Acquisitions 377

CHAPTER 14 Determining Project Progress and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

14.1 Project Balanced Scorecard Approach 382

14.2 Internal Project Issues 383 14.2a Direct and Manage Project Work 383 / 14.2b Monitor and Control Project

Work 385 / 14.2c Monitoring and Controlling Project Risk 387 / 14.2d Manage Communications 388 / 14.2e Control Communications 391

14.3 Customer Issues 392 14.3a Perform Quality Assurance 392 / 14.3b Control Quality 393

14.4 Financial Issues 400 14.4a Control Scope 400 / 14.4b Control Schedule and Costs 401 / 14.4c Earned Value

Management for Controlling Schedule and Costs 401

14.5 Using MS Project to Monitor and Control Projects 405 14.5a What Makes a Schedule Useful? 405 / 14.5b How MS Project Recalculates the

Schedule Based on Reported Actuals 405 / 14.5c Current and Future Impacts of Time and Cost Variance 406 / 14.5d Define the Performance Update Process 406 / 14.5e Steps to Update the Project Schedule 406

14.6 Replanning if Necessary 410

Summary 411

Key Terms from the PMBOK® Guide 412 Chapter Review Questions 412

Discussion Questions 412

PMBOK® Guide Questions 413 Exercises 414

Example Project 415

References 415

Endnotes 416

Project Management in Action: Controlling, Monitoring, and Reporting Projects at a Major Medical Center 416

xii Contents

CHAPTER 15 Finishing the Project and Realizing the Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

15.1 Validate Scope 422

15.2 Close Procurements 424 15.2a Terminate Projects Early 424

15.3 Close Project 425 15.3a Write Transition Plan 425 / 15.3b Knowledge Management 426 / 15.3c Create

the Closeout Report 430

15.4 Post-Project Activities 430 15.4a Reassign Workers 430 / 15.4b Celebrate Success and Reward Participants 430 /

15.4c Provide Ongoing Support 431 / 15.4d Ensure Project Benefits Are Realized 431

15.5 Using MS Project for Project Closure 431

Summary 432

Key Terms from the PMBOK® Guide 432 Chapter Review Questions 432

Discussion Questions 433

PMBOK® Guide Questions 433 Exercises 434

Example Project 434

References 434

Endnotes 435

Project Management in Action: The Power of Lessons Learned 436

Appendix A PMP® and CAPM® Exam Prep Suggestions . . . . . . . . . . . . . . . . . . . . . . . 439 Appendix B Strengths Themes as Used in Project Management (available on the

textbook companion site) Glossary Terms from the PMBOK® Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

PROJECT DELIVERABLES CHAPTER

Project Customer Tradeoff Matrix 1

Project Success Definition 1

Project SWOT Analysis 2

Project Elevator Pitch 2

Project Selection/Prioritization 2

Project Resource Assignment 2

Project Source Selection 2

Project Charter 4

Stakeholder Prioritization 5

Stakeholder Register 5

Project Communications Matrix 5

Project Meeting Agenda 5

Project Meeting Minutes 5

Contents xiii

PROJECT DELIVERABLES CHAPTER

Project Issues Log 5

Project Meeting Evaluation 5

Project Requirements Traceability Matrix 6

Project Scope Statement 6

Work Breakdown Structure 6

Change Request 6

Activity List 7

Network-Based Schedule 7

Gantt Chart Schedule 7

Project RACI Chart 8

Resource Histogram for Resolving Overloads 8

Project Crashing 8

Project Budget Aggregation 9

Project Risk Register 10

Project SIPOC 11

Project Quality Plan 11

Project Supplier Selection 12

Project Member Assessment 13

Project Team Assessment 13

Project Progress Report 14

Earned Value Analysis 14

Project Customer Feedback 15

xiv Contents

Preface

While project managers today still need to use many techniques that have stood the test of twenty to fifty years, they increasingly also need to understand the business need for a project, sort through multiple conflicting stakeholder demands, and know how to deal with rapid change, a myriad of communication issues, global and virtual project teams, modern approaches to quality improvement, and many other issues that are more chal- lenging than in projects of previous times.

Contemporary project management utilizes the tried-and-true project management techniques along with modern improvements such as the most current versions of Microsoft® Project Professional 2013 and the fifth edition of the Guide to the Project Management Body of Knowledge (PMBOK® Guide). Contemporary project management also uses many tools and understandings that come from modern approaches to quality and communications, expanded role definitions, leadership principles, human strengths, agile planning and execution, and many other sources. Contemporary project manage- ment is scalable, using simple versions of important techniques on small projects and more involved versions on more complex projects.

Distinctive Approach This book covers the topics of contemporary project management. It was also developed using contemporary project management methods. For example, when considering the topic of dealing with multiple stakeholders, every chapter was reviewed by students, practitioners, and academics. This allowed student learning, practitioner realism, and ac- ademic research and teaching perspectives to be simultaneously considered.

The practical examples and practitioner reviewers came from many industries and from many sizes and types of projects to promote the scalability and universality of con- temporary project management techniques.

New to This Edition

• Agile approach. The agile approach to project planning and management in which planning and implementing are done incrementally is introduced in Chapter 1. Throughout the book when the agile approach is different from the traditional, a margin icon and alternate color print are used to emphasize the difference. In this book’s contemporary approach to project management in practice, agile and tradi- tional are both used extensively.

• Updated to reflect the fifth edition of the PMBOK® Guide. All fifth edition PMBOK® Guide knowledge areas and processes are specifically included. The end of each chapter now contains ten PMBOK® Guide-type questions that are typical of what would be seen on PMP® and CAPM® exams. Appendix A gives study suggestions for the CAPM® and PMP® exams.

• New examples throughout the text. Each chapter starts with a motivating example for why the student would want to read the chapter and ends with an example of how a company actually used some tools and/or concepts from the chapter. There are many smaller examples throughout each chapter that illustrate specific points. Many of these are new examples from around the world and from many different industries such as the Fiesta® San Antonio Commission (Texas) and an IT rollout

xv

within a system of regional schools in Germany (Chapter 5); the rollout of a project management tool to a South African banking group (Chapter 7); the Panama Canal expansion (Chapter 10); the determination of supplier ratings at General Tool Company in Ohio (Chapter 11); and the control, monitoring, and reporting of projects at Cincinnati Children’s Hospital Medical Center (Chapter 14).

• Microsoft® Project Professional 2013 fully integrated into the fabric of eight chapters. Though techniques are demonstrated in a by-hand fashion, a demonstra- tion of how to automate them using Microsoft® Project Professional 2013 is shown in a step-by-step manner with numerous screen captures. On all screen captures, critical path activities are shown in contrasting color for emphasis.

• Project deliverables. A list of project deliverables that can be used for students assignments are included after the expanded table of contents. Many instructors may choose some but not all of these depending on class organization.

• Templates. Electronic templates for many of the techniques (student deliverables) are available on the textbook companion website. These Microsoft® Word and Excel documents can be downloaded and filled in for ease of student learning and for consistency of instructor grading.

Distinctive Features • PMBOK® Guide approach. This consistency with the established standard gives

students a significant leg up if they decide to become certified Project Management Professionals (PMPs®) or Certified Associates in Project Management (CAPMs®). All glossary definitions are from the PMBOK® Guide.

• Actual project as learning vehicle. One section at the end of each chapter lists deliverables for students to create (in teams or individually) for a real project. These assignments have been refined over the last decade while working with the local PMI® chapter, which provides a panel of PMP® judges to evaluate projects from a practical point of view. Students are encouraged to keep clean copies of all deliver- ables so they can demonstrate their project skills in job interviews. A listing of these deliverables is included after the detailed table of contents.

• Student oriented, measurable learning objectives. Each chapter begins with a listing of the most important points students should learn and identifies the PMBOK® topics covered in the chapter. The chapter material, end-of-chapter questions and problems, PowerPoint® slides, and test questions have all been updated to correlate to specific objectives.

• Blend of classical and modern methods. Proven methods developed over the past half century are combined with exciting new methods that are emerging from both industry and research.

• Executive, managerial, and associate roles. This book covers the responsibilities of many individuals who can have an impact on projects so aspiring project managers can understand not only their own roles, but also those of people with whom they need to deal.

• Balanced scorecard approach. Many factors are included in how project success is measured and how project results are determined. An adaptation of the balanced scorecard helps students understand how these fit together.

• Integrated example project. An example project has been developed to demonstrate many of the techniques throughout the book. That way students can see how the various project planning and control tools develop and work together.

xvi Preface

Organization of Topics The book is divided into three major parts. Part 1, Organizing Projects, deals with both the environment in which projects are conducted and getting a project officially approved.

• Chapter 1 introduces contemporary project management by first tracing the history of project management, then discussing what makes a project different from an ongoing operation. Various frameworks that help one understand projects—such as the PMBOK® Guide—are introduced, as well as the executive-, managerial-, and associate-level roles.

• Chapter 2 discusses how projects support and are an outgrowth of strategic plan- ning, how a portfolio of projects is selected and prioritized, how a client company selects a contractor company to conduct a project, and how a contractor company secures project opportunities from client companies.

• Chapter 3 deals with organizational capability issues of structure, life cycle, culture, and roles. The choices parent organizations make in each of these provide both opportunities and limitations to how projects can be conducted.

• Chapter 4 presents project charters in a step-by-step fashion. Short, powerful char- ters help all key participants to develop a common understanding of all key project issues and components at a high level and then to formally commit to the project. Charters have become nearly universal in initiating projects in recent years. Micro- soft® Project Professional 2013 is used to show milestone schedules within charters.

Part 2, Planning Projects, deals with all aspects of project planning as defined in the PMBOK® Guide. • Chapter 5 introduces methods for understanding and prioritizing various stake-

holder demands and for building constructive relationships with stakeholders. Since many projects are less successful than desired due to poor communications, detailed communication planning techniques are introduced along with meeting management.

• Chapter 6 helps students understand how to determine the amount of work the project entails. Specifically covered are methods for determining the scope of both the project work and outputs, the work breakdown structure (WBS) that is used to ensure nothing is left out, and how the WBS is portrayed using Microsoft® Project Professional 2013.

• Chapter 7 is the first scheduling chapter. It shows how to schedule activities by identifying, sequencing, and estimating the durations for each activity. Then critical path project schedules are developed, methods are shown for dealing with uncer- tainty in time estimates, Gantt charts are introduced for easier communications, and Microsoft® Project Professional 2013 is used to automate the schedule development and communications.

• Chapter 8 is the second scheduling chapter. Once the critical path schedule is de- termined, staff management plans are developed, project team composition issues are considered, resources are assigned to activities, and resource overloads are iden- tified and handled. Schedule compression techniques of crashing and fast tracking are demonstrated and multiple alternative scheduling techniques including Agile are introduced. Resource scheduling is demonstrated with Microsoft® Project Profes- sional 2013.

• Chapter 9 deals with project budgeting. Estimating cost, budgeting cost, and establishing cost controls are demonstrated. Microsoft® Project Professional 2013 is used for developing both bottom-up and summary project budgets.

Preface xvii

• Chapter 10 demonstrates project risk planning. It includes risk management plan- ning methods for identifying risks, establishing a risk register, qualitatively analyzing risks for probability and impact, quantitatively analyzing risks if needed, and decid- ing how to respond to each risk with contingency plans for major risks and aware- ness for minor risks.

• Chapter 11 starts by covering project quality planning. This includes explaining the development of modern quality concepts and how they distill into core project quality demands. Then the chapter covers how to develop a project quality plan and how to utilize the simple project quality tools. It then ties all of the planning chap- ters together with discussions of a project kick-off meeting, a baselined project plan, and the ways Microsoft® Project Professional 2013 can be used to establish and maintain the baseline.

Part 3, Performing Projects, discusses the various aspects that must be managed simultaneously while the project is being conducted.

• Chapter 12 deals with project supply chain management issues. Some of these issues, such as developing the procurement management plan, qualifying and selecting vendors, and determining the type of contract to use are planning issues, but for simplicity they are covered in one chapter with sections on how to conduct and control procurements and to improve the project supply chain.

• Chapter 13 deals with leading and managing both the project team and stakeholders. It includes acquiring and developing the project team, assessing both potential and actual performance of team members and the team as a whole, various types of power a project manager can use, and how to deal productively with project conflict.

• Chapter 14 is concerned with determining project results. This chapter starts with a balanced scorecard approach to controlling projects. Internal project issues covered include risk, change, and communication. Quality is the customer issue. Financial issues are scope, cost, and schedule, including how to use Microsoft® Project Pro- fessional 2013 for control.

• Chapter 15 deals with how to end a project—either early or on time. Included are validating to ensure all scope is complete, formally closing procurements and the project, knowledge management, and ensuring the project participants are rewarded and the clients have the support they need to realize intended benefits when using the project deliverables.

Instructor Resources To access the instructor resources go to www.cengage.com/login, log in with your faculty account username and password, and use ISBN 9781285433356 to search for and to add instructor resources to your account. Key support materials—instructor’s manual with solutions, test bank, data set solutions, regular and exhibit-only Power- Point® presentations—provide instructors with a comprehensive capability for customizing their classroom experience. All student resources are also available on the instructor companion site.

• Instructor’s Manual with Solutions. Prepared by Tim Kloppenborg and based on his years of experience facilitating the student learning experience in his own project management classes (undergraduate, MBA, hybrid, and continuing education on six continents), each chapter of the instructor’s manual includes an overview of learning objectives, detailed chapter outlines, teaching recommendations, and many detailed suggestions for implementing community-based projects into your project management class. Solutions are also provided for all of the end-of-chapter content.

xviii Preface

• Microsoft® Word Test Bank. Prepared for this edition by Joyce D. Brown, PMP® and Thomas F. McCabe, PMP® of the University of Connecticut, this compre- hensive test bank builds upon the original test bank created by Kevin Grant of the University of Texas at San Antonio. The test bank is organized around each chapter’s learning objectives. All test questions are consistent with the PMBOK®. Every test item is labeled according to its difficulty level and the major topical heading within the textbook that it relates to, allowing instructors to quickly construct effective tests that emphasize the concepts most significant for their courses. The test bank includes true/false, multiple choice, essay, and quantitative problems for each chapter. All question content is now tagged according to Tier I (Business Program Interdisciplinary Learning Outcomes), Bloom’s Taxonomy, and difficulty level.

• Cognero™ Test Bank. Cengage Learning Testing Powered by Cognero™ is a flexi- ble, online system that allows you to author, edit, and manage test bank content from multiple Cengage Learning solutions; create multiple test versions in an instant; deliver tests from your LMS, your classroom, or wherever you want. The Cognero™ test bank contains the same questions that are in the Microsoft® Word test bank.

• PowerPoint Presentation. Prepared by Deborah Tesch of Xavier University, the PowerPoint presentations provide comprehensive coverage of each chapter’s essential concepts in a clean, concise format. Key exhibits from the textbook are also included as an exhibit-only presentation to enhance in-class illustration and discussion of important concepts. Instructors can easily customize the PowerPoint presentation to better fit the needs of their classroom.

Student Resources Students can access the following resources by going to www.cengagebrain.com and searching 9781285433356

• Student Data Sets. The data sets contain Excel data that is used in the completion of select end-of-chapter problems. There are also templates in Word and Excel for completing various project planning and control tools.

• Other Project Management Resources. Additional material on the website includes definitions of strengths written from a project management perspective as assessed by Gallup’s StrengthsFinder assessment and classic examples that were used in previous editions of this text.

Acknowledgments A book-writing project depends on many people. Through the last three decades of project work I have been privileged to learn from thousands of people including students, faculty members, co-trainers, co-consultants, co-judges, clients, research partners, and others. Hundreds of individuals who have provided help in research and developing teaching methods are members of the Southwest Ohio and Miami Valley chapters of the Project Management Institute and of the Cincinnati and Louisville sections of the Center for Quality of Management. Many individuals have provided wonderful examples and those who wish to be acknowledged are named with their contributions.

I also want to acknowledge the wonderful help of various professionals at Cengage Learning including Clara Goosman (Product Manager), Kendra Brown (Content Devel- oper), and Chris Valentine (Media Developer). I also want to thank Charles McCormick,

Preface xix

Jr., retired Senior Acquisitions Editor, for his extensive help and guidance on the first and second editions of Contemporary Project Management.

Other individuals who have provided significant content are Lynn Frock, PMP®, of Lynn Frock and Company, who provided the Microsoft® Project material, Debbie Tesch of Xavier University, who provided the PowerPoint slides, Joyce D. Brown, PMP® and Thomas F. McCabe, PMP® of University of Connecticut, who revised the test bank and provided addi- tional PMBOK® questions to each chapter, and Kathryn N. Wells, Independent Consultant, CAPM® who provided the Chapter Review and Discussion Questions.

Special thanks are also due to all of the people whose feedback and suggestions have shaped this edition of Contemporary Project Management as well as the previous two editions:

Carol Abbott, Fusion Alliance, Inc.

Stephen Allen, Truman State University

Vittal Anantatmula, Western Carolina University

Loretta Beavers, Southwest Virginia Community College

Shari Bleure, Skyline Chili

Reynold Byers, Arizona State University

John Cain, Viox Services

Robert Clarkson, Davenport University

Nancy Cornell, Northeastern University

Steve Creason, Metropolitan State University

Jacob J. Dell, University of Texas at San Antonio

Scott Dellana, East Carolina University

Maling Ebrahimpour, Roger Williams University

Jeff Flynn, ILSCO Corporation

Jim Ford, University of Delaware

Lynn Frock, Lynn Frock & Company

Lei Fu, Hefei University of Technology

Patricia Galdeen, Lourdes University

Kathleen Gallon, Christ Hospital

Paul Gentine, Bethany College

Kevin P. Grant, University of Texas–San Antonio

Joseph Griffin, Northeastern University

Raye Guye, ILSCO Corporation

William M. Hayden Jr., University at Buffalo

Sarai Hedges, University of Cincinnati

Marco Hernandez, Dantes Canadian

Bill Holt, North Seattle Community College

Sonya Hsu, University of Louisiana Lafayette

Paul Hudec, Milwaukee School of Engineering

Anil B. Jambekar, Michigan Technological University

Dana Johnson, Michigan Technological University

Robert Judge, San Diego State University

xx Preface

David L. Keeney, Stevens Institute of Technology

George Kenyon, Lamar University

Naomi Kinney, MultiLingual Learning Services

Paul Kling, Duke Energy

Matthew Korpusik, Six Sigma Black Belt

Sal Kukalis, California State University—Long Beach

Young Hoon Kwak, George Washington University

Laurence J. Laning, Procter & Gamble

Dick Larkin, Central Washington University

Lydia Lavigne, Ball Aerospace

James Leaman, Eastern Mennonite University

Claudia Levi, Edmonds Community College

Marvette Limon, University of Houston Downtown

John S. Loucks, St. Edward’s University

Diane Lucas, Penn State University– DuBois Campus

S. G. Marlow, California State Polytechnic University

Daniel S. Marrone, SUNY Farmingdale State College

Chris McCale, Regis University

Abe Meilich, Walden University

Bruce Miller, Xavier Leadership Center

Ali Mir, William Paterson University

William Moylan, Eastern Michigan University

Warren Opfer, Life Science Services International

Peerasit Patanakul, Stevens Institute of Technology

Joseph Petrick, Wright State University

Kenneth R. Pflieger, Potomac College

Charles K. Pickar, Johns Hopkins University

Chris Rawlings, Bob Jones University

Natalee Regal, Procter & Gamble

Pedro Reyes, Baylor University

Linda Ridlon, Center for Quality of Management, Division of GOAL/QPC

David Schmitz, Milwaukee School of Engineering

Sheryl R. Schoenacher, SUNY Farmingdale State College

Jan Sepate, Kimberly Clark

Patrick Sepate, Summitqwest Inc.

William R. Sherrard, San Diego State University

Brian M. Smith, Eastern University

Kimberlee D. Snyder, Winona State University

Siti Arshad-Snyder, Clarkson College

Rachana Thariani, Atos-Origin

Nate Tucker, Lee University

Guy Turner, Castellini Company

Jayashree Venkatraman, Microsoft Corporation

Nathan Washington, Southwest Tennessee Community College

Kathryn N. Wells

And I especially want to thank my family members for their love and support: Bet, Kate Noel, Nick, and Andy.

—Timothy J. Kloppenborg

Preface xxi

About the Author

Timothy J. Kloppenborg is a Castellini Distinguished Professor of Management at Williams College of Business, Xavier University. He previously held faculty positions at University of North Carolina Charlotte and Air Force Institute of Technology and has worked temporarily at Southern Cross University and Tecnológico de Monterrey. He has over 100 publications including Strategic Leadership of Portfolio and Project Manage- ment, Project Leadership and Managing Project Quality. His articles have appeared in Project Management Journal, Journal of Management Education, Journal of General Management, SAM Advanced Management Journal, Information Systems Education Jour- nal, Journal of Managerial Issues, Quality Progress, Management Research News, and Journal of Small Business Strategy. Tim has been active with Project Management Insti- tute for 30 years and a PMP® since 1991. He is a retired U.S. Air Force Reserve officer who served in transportation, procurement, and quality assurance. Dr. Kloppenborg has worked with over 150 volunteer organizations, many directly and others through super- vising student projects. He has hands-on and consulting project management experience on six continents in construction, information systems, research and development, and quality improvement projects with organizations such Duke Energy, Ernst and Young LLP, Greater Cincinnati Water Works, Kroger, Procter and Gamble, TriHealth, and Texas Children’s Hospital. Dr. Kloppenborg has developed and delivered innovative cor- porate training, undergraduate, MBA, and Executive MBA classes in project manage- ment, leadership, teamwork, and quality improvement and he teaches PMP Prep classes. He holds a B.S. in business administration from Benedictine College, an MBA from Western Illinois University, and a Ph.D. in Operations Management from Univer- sity of Cincinnati.

xxiixxii

PART1 ORGANIZING PROJECTS organize / plan / perform

Chapter 1 Introduction to Project Management

Chapter 2 Project Selection and Prioritization

Chapter 3 Organizational Capability: Structure, Culture, and Roles

Chapter 4 Chartering Projects

1

CHA P T E R 1 Introduction to Project Management

I have returned from a successful climb of Mt. Aconcagua in Argentina; at 22,841 feet, it is the highest peak in the world outside of the Himalayas. While there, seven other climbers died; we not only survived, but our experience was so positive that we have partnered to climb together again.

During the three decades that I’ve been climbing mountains, I’ve also been managing projects. An element has emerged as essential for success in both of these activities: the element of discipline. By discipline, I am referring to doing what I already know needs to be done. Without this attribute, even the most knowledgeable and experienced will have difficulty avoiding failure.

The deaths on Aconcagua are an extreme example of the consequences associated with a lack of discipline. The unfortunate climbers, who knew that the predicted storms would produce very hazardous conditions, decided to attempt the summit instead of waiting. They did not have the discipline that

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Define a project in your own words, using characteristics that are common to most projects, and describe reasons why more organizations are using project management.

• Describe major activities and deliverables at each project life cycle stage.

• List and define the ten knowledge areas and five process groups of the project management body of knowledge (PMBOK®).

• Delineate measures of project success and failure, and reasons for both.

• Contrast predictive or plan-driven and adaptive or change- driven project life cycle approaches.

• Identify project roles and distinguish key responsibilities for each.

© Pr es sm

as te r/S

hu tte rs to ck .c om

2

Topics:

• Project management introduction

• Project life cycle

• Stakeholders

• Project management processes

we demonstrated to act on our earlier decision to curtail summit attempts after the agreed-to turn-around time or in severe weather.

I’ve experienced similar circumstances in project management. Often I have found myself under pressure to cast aside or shortcut project management practices that I have come to rely on. For me, these practices have become the pillars of my own project management discipline. One of these pillars, planning, seems to be particularly susceptible to challenge. Managing projects at the Central Intelligence Agency for three decades, I adjusted to the annual cycle for obtaining funding. This cycle occasionally involved being given relatively short notice near the end of the year that funds unspent by some other department were up for grabs to whoever could quickly make a convincing business case. While some may interpret this as a circumstance requiring shortcutting the necessary amount of planning in order to capture some of the briefly available funds, I understood that my discipline required me to find a way to do the needed planning and to act quickly. I understood that to do otherwise would likely propel me toward becoming one of the two-thirds of the projects identified by the Standish Group in their 2009 CHAOS report as not successful. I understood that the top 2 percent of project managers, referred to as Alpha Project Managers in a 2006 book of the same name, spend twice as much time planning as the other 98 percent of project managers. The approach that I took allowed me to maintain the discipline for my planning pillar. I preplanned a couple of projects and had them ready at the end of the year to be submitted should a momentary funding opportunity arise.

A key to success in project management, as well as in mountain climbing, is to identify the pillars that will be practiced with discipline. This book offers an excellent set of project management methods from which we can identify those pillars that we will decide to practice with the required levels of discipline. I believe that project management is about applying common sense with uncommon discipline.

Michael O’Brochta, PMP, founder of Zozer Inc. and previously senior project manager at the Central Intelligence Agency

3

PMBOK® Guide

1-1 What Is a Project? Frequently, a business is faced with making a change, such as improving an existing work process, constructing a building, installing a new computer system, merging with another company, moving to a new location, developing a new product, entering a new market, and so on. These changes are best planned and managed as projects. So, what is a project?

A project is “a temporary endeavor undertaken to create a unique product, service, or result.”1 A project requires an organized set of work efforts that are planned in a level of detail that is progressively elaborated upon as more information is discovered. Projects are subject to limitations of time and resources such as money and people. Projects should follow a planned and organized approach with a defined beginning and ending. Project plans and goals become more specific as early work is completed. The output often is a collection of a primary deliverable along with sup- porting deliverables such as a house as the primary deliverable and warrantees and instructions for use as supporting deliverables. Each project typically has a unique combination of stakeholders—“an individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.”2 Projects often require a variety of people to work together for a limited time, and all participants need to understand that completing the project will require effort in addition to their other assigned work.

Project management is “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.”3 This includes work processes that initi- ate, plan, execute, control, and close work. During these processes, tradeoffs must be made among the following factors:

• Scope (size) • Schedule • Quality (acceptability of the results) • Resources • Cost • Risks4

When project managers successfully make these tradeoffs, the project results meet the agreed upon requirements, are useful to the customers, and promote the organization. Project management includes both administrative tasks for planning, documenting, and controlling work and leadership tasks for visioning, motivating, and promoting work associates. Project management knowledge, skills, and methods can be applied and modified for most projects regardless of size or application.

1-2 History of Project Management Projects of all sizes have been undertaken throughout history. Early construction projects included the ancient pyramids, medieval cathedrals, and Indian cities and pueblos. Other large early projects involved waging wars and building empires. In the development of the United States, projects included laying railroads, developing farms, and building cities. Many smaller projects have consisted of building houses and starting businesses. Throughout most of history, projects were conducted, but there was very little systematic planning and control. Some early projects were accomplished at great human and financial cost. Others took exceedingly long periods of time to complete.

Project management eventually emerged as a formal discipline to be studied and prac- ticed. In the 1950s and 1960s, techniques for planning and controlling schedules and costs were developed, primarily on huge aerospace and construction projects. During this time, project management primarily involved determining project schedules based

4 Part 1 Organizing Projects

on understanding the order in which work activities had to be completed. Many large manufacturing, research and development, government, and construction projects used and refined management techniques. In the 1980s and 1990s, several software companies offered ever more powerful and easier ways to plan and control project costs and sche- dules. Risk management techniques that were originally developed on complex projects have increasingly been applied in a simplified form to less complex projects.

In the last few years, people have realized more and more that communication and leadership play major roles in project success. Rapid growth and changes in the informa- tion technology and telecommunications industries especially have fueled massive growth in the use of project management in the 1990s and early 2000s. People engaged in banking, insurance, retailing, hospital administration, and many other service industries are now turning to project management to help them plan and manage efforts to meet their unique demands. Project planning and management techniques that were originally developed for large, complex projects can be modified and used to better plan and manage smaller pro- jects. Now project management is commonly used on projects of many sizes and types in a wide variety of manufacturing, government, service, and nonprofit organizations.

The use of project management has grown quite rapidly and is likely to continue growing. With increased international competition, customers demand to have their pro- ducts and services developed and delivered better, faster, and cheaper. Because project management techniques are designed to manage scope, quality, cost, and schedule, they are ideally suited to this purpose.

1-3 How Can Project Work Be Described? Project work can be described in the following ways:

• Projects are temporary and unique while other work, commonly called operations, is more continuous.

• Project managers need certain “soft skills” and “hard skills” to be effective. • Project managers frequently have more responsibility than authority. • Projects go through predictable stages called a life cycle.

1-3a Projects versus Operations All work can be described as fitting into one of two types: projects or operations. Projects as stated above are temporary, and no two are identical. Some projects may be extremely different from any other work an organization has performed up to that time, such as planning a merger with another company. Other projects may have both routine and unique aspects such as building a house. Operations, on the other hand, consist of the ongoing work needed to ensure that an organization continues to function effectively. Operations managers can often use checklists to guide much of their work. Project man- agers can use project management methods to help determine what to do, but they rarely have checklists that identify all of the activities they need to accomplish. Some work may be difficult to classify as totally project or totally operations. However, if project manage- ment methods and concepts help one to better plan and manage work, it does not really matter how the work is classified.

1-3b Soft Skills and Hard Skills To effectively manage and lead in a project environment, a person needs to develop both “soft” and “hard” skills. Soft skills include communication and leadership activ- ities. Hard skills can include risk analysis, quality control, scheduling, budgeting, and

Chapter 1 Introduction to Project Management 5

so forth. Soft and hard skills go hand in hand. Some people have a stronger natural ability and a better comfort level in one or the other, but to be successful as a proj- ect manager a person needs to develop both along the judgment about when each is needed. A wise project manager may purposefully recruit an assistant that excels in his area of weakness. Training, experience, and mentoring can also be instrumental in developing necessary skills.

1-3c Authority and Responsibility A project manager will frequently be held accountable for work that she cannot or- der people to perform. Projects are most effectively managed with one person being assigned accountability. However, that person often needs to negotiate with a func- tional manager, who is “someone with management authority over an organizational unit… the manager of any group that actually makes a product or performs a service.”5 Functional managers negotiate for workers to perform the project work in a timely fashion. Since the workers know their regular manager often has other tasks for them and will be their primary rater, they are tempted to concentrate first on the work that will earn rewards. Hence, a project manager needs to develop strong com- munication and leadership skills in order to persuade subordinates to focus on the project when other work also beckons.

1-3d Project Life Cycle All projects go through predictable stages called a project life cycle. A project life cycle is “the series of phases that a project goes through from its initiation to its closure.”6 An organization’s control needs are to be assured that the work of the project is proceeding in a satisfactory manner and that the results are likely to serve its customer’s intended pur- pose. The project customer is the person or organization that will use the project’s product, service, or result. Customers can be internal to the organization (that is, part of the com- pany that is performing the project) or external to the organization. Many different project life cycle models are used for different types of projects, such as information systems, improvement, research and development, and construction. The variations these pose will be explored in Chapter 3. In this book we will use the following project stages (as seen in the chapter opener Project Life Cycle diagram for all of the following chapters.):

• Selecting and initiating—starts when an idea for a project first emerges and the project is selected and planned at a high level, and ends when key participants commit to it in broad terms.

• Planning—starts after the initial commitment, includes detailed planning, and ends when all stakeholders accept the entire detailed plan.

• Executing—starts when the plan is accepted, and includes authorizing, executing, monitoring, and controlling work until the customer accepts the project deliverables.

• Closing and realizing—includes all activities after customer acceptance to ensure project is completed, lessons are learned, resources are reassigned, contributions are recognized, and benefits are realized.

The pace of work and amount of money spent may vary considerably from one life cycle stage to another. Often, the selecting is performed periodically for all projects at a division or corporate level, and then initiating is rather quick—just enough to ensure that a project makes sense and key participants will commit to it. The planning stage can become rather detailed and will normally require quite a bit more work. The execution stage or stages are the time when the majority of the hands-on project tasks are accomplished. This tends to be a time of considerable work. Closing is a time when loose

6 Part 1 Organizing Projects

ends are tied up and the work level decreases significantly, but realizing benefits from the project occurs over time, may be measured months after project completion, and may be done by people other than those who performed the project. See Exhibit 1.1 for a predic- tive or plan-driven project life cycle and Exhibit 1.2 for an adaptive or change-driven proj- ect life cycle. The primary difference is that in the first, the product is well-understood and all planning precedes all executing, while in the second, early results lead into planning later work. The extreme of predictive is sometimes called waterfall and the extreme of adaptive is sometimes called agile. Agile will be defined in Chapter 3, but throughout the book a margin icon will indicate ideas from agile, and the text will be in color.

EXHIBIT 1.1 PREDICTIVE OR PLAN-DRIVEN PROJECT LIFE CYCLE

WITH MEASUREMENT POINTS

Other Approvals

Closing & Realizing

Administrative Closure

Benefits Measures

Level of Effort

Stage

Stage Ending Gates

Selecting & Initiating

Charter

Selection

Planning

Kickoff

Executing

Project Result

Progress Reports

EXHIBIT 1.2 ADAPTIVE OR CHANGE–DRIVEN PROJECT LIFE CYCLE

WITH MEASUREMENT POINTS

Other Approvals

Closing & Realizing

Administrative Closure

Benefits Measures

Level of Effort

Stage

Stage Ending Gates

Selecting & Initiating

Charter

Selection

Planning Executing

Planning Executing

· · ·

Interim Result

Interim Result

Project Result

A G I L E

Chapter 1 Introduction to Project Management 7

Three other points should be made concerning the project life cycle. First, most com- panies with well-developed project management systems insist that a project must pass an approval of some kind to move from one stage to the next.7 In both exhibits, the approval to move from selecting and initiating to planning, for instance, is the approval of a charter. Second, in many industries, the project life cycle is highly formal- ized and very specific. For example, in information systems, the executing stage is often described as two stages: writing code and testing code. In the construction industry, the executing stage is often described as the three stages of design, erection, and finish- ing. Many companies even have their own project life cycle model, such as the one Midland Insurance Company has developed for quality improvement projects as shown in Exhibit 1.3. This book will present examples of company-specific life cycle models, but for clarity will use the predictive or plan-driven model shown in Exhibit 1.1 when describing concepts except when we discuss agile with the adaptive or change-driven model. Third, in addition to stage-ending approvals, frequently projects are measured at additional points such as selection, progress reporting, and benefits realization, as shown in Exhibit 1.1.

1-4 Understanding Projects Several frameworks that can help a person better understand project management are described below: the Project Management Institute (PMI); the Project Management Body of Knowledge (PMBOK® Guide); methods of selecting and prioritizing projects, project goals and constraints; project success and failure; use of Microsoft Project to help plan and measure projects, and various ways to classify projects.

1-4a Project Management Institute Project management has professional organizations just as do many other professions and industry groups. The biggest of these by far is the Project Management Institute.

It was founded in 1969, grew at a modest pace until the early 1990s, and has grown quite rapidly since. As of March 2013, PMI had well over 650,000 members and creden- tial holders in 185 countries. PMI publishes and regularly updates A Guide to the Project Management Body of Knowledge (PMBOK® Guide). All of the definitions in this book come from the PMBOK® Guide, fifth edition.8 PMI has established a professional certification entitled Project Management Professional (PMP). To be certified as a PMP,

EXHIBIT 1.3 MIDLAND INSURANCE COMPANY PROJECT LIFE CYCLE FOR

QUALITY IMPROVEMENT PROJECTS

InitiationInitiation PlanningPlanning ExecutionExecution Close -OutClose Out

1) Define Problem

2) Factually Describe Situation

3) Analyze Causes

4) Solution Planning and Implementation

5) Evaluation of Effects

6) Sustain Results

7) Share Results

Source: Martin J. Novakov, American Modern Insurance Group.

8 Part 1 Organizing Projects

a person needs to have the required experience and education, pass an examination on the PMBOK® Guide, and sign and be bound by a code of professional conduct. PMI has also established a second certification—Certified Associate in Project Management (CAPM)—that is geared toward junior people working on projects before they are eligi- ble to become PMPs. PMI also has established additional credentials, practice standards, and extensions of the PMBOK® Guide in areas such as program management, agile, risk, scheduling, resource estimating, work breakdown structures, construction, and government.9

1-4b Project Management Body of Knowledge (PMBOK®) The Project Management Body of Knowledge consists of a project life cycle (see earlier “Project Life Cycle” section), 5 process groups, and 10 knowledge areas. A project man- agement process group is “a logical grouping of the project management inputs, tools and techniques, and outputs.”10 The five process groups, paraphrased from the PMBOK® Guide, are as follows:

1. Initiating—“define a project or a new phase by obtaining authorization” 2. Planning—“establish the project scope, refine objectives and define actions to attain

objectives” 3. Executing—“complete the work defined to satisfy project specifications” 4. Monitoring and controlling—“track, review, and regulate progress and perfor-

mance, identify changes required, and initiate changes” 5. Closing—“finalize all activities to formally close project or phase”11

The 10 knowledge areas, paraphrased from the PMBOK® Guide, are as follows:

1. Integration management—“processes and activities to identify, define, combine, unify, and coordinate the various processes and project management activities”12

2. Scope management—“processes to ensure that the project includes all the work required, and only the work required, to complete the project successfully”13

3. Time management—“processes to manage timely completion of the project”14

4. Cost management—“processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling costs so that the project can be com- pleted within the approved budget”15

5. Quality management—“processes and activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken”16

6. Human resources management—“processes that organize, manage, and lead the project team”17

7. Communications management—“processes to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and ultimate disposition of project information”18

8. Risk management—“processes of conducting risk management planning, identifi- cation, analysis, response planning, and control… to increase the likelihood and impact of positive events and decrease the likelihood and impact of negative events in the project”19

9. Procurement management—“processes to purchase or acquire products, services, or results from outside the project team”20

10. Stakeholder management—“processes to identify the people, groups, or organiza- tions, that could impact or be impacted by the project, analyze their expectations and impact, and develop strategies for engaging them and managing conflicting interests”21

Chapter 1 Introduction to Project Management 9

1-4c Selecting and Prioritizing Projects During the selecting and initiating stage of a project, one of the first tasks leaders must do is to identify potential projects. Ideally, this is accomplished in a systematic manner— not just by chance. Some opportunities will present themselves. Other good opportu- nities need to be discovered. All parts of the organization should be involved. For exam- ple, salespeople can uncover opportunities through open discussions with existing and potential customers. Operations staff members may identify potential productivity- enhancing projects. Everyone in the firm should be aware of industry trends and use this knowledge to identify potential projects.

Once identified, organizations need to prioritize among the potential projects. The best way to do this is to determine which projects align best with the major goals of the firm. The executives in charge of selecting projects need to ensure overall organiza- tional priorities are understood, communicated, and accepted. Once this common under- standing is in place, it is easier to prioritize among the potential projects. The degree of formality used in selecting projects varies widely. Regardless of the company’s size and the level of formality used, the prioritization efforts should include asking the following questions:

• What value does each potential project bring to the organization? • Are the demands of performing each project understood? • Are the resources needed to perform the project available? • Is there enthusiastic support both from the external customers and from one or

more internal champions? • Which projects will best help the organization achieve its goals?

1-4d Project Goals and Constraints All projects should be undertaken to accomplish specific goals. Those goals can be described both by scope—“the sum of the products, services, and results to be provided as a project”22 and by quality—“the degree to which a set of inherent characteristics ful- fills requirements.”23 Taken together, scope and quality are often called performance and should result in outputs that customers can be satisfied with as they use them to effec- tively do their job. From a client perspective, projects generally have time and cost con- straints. Thus, a project manager needs to be concerned with achieving desired scope and quality, subject to constraints of time and cost. If the project were to proceed exactly according to plan, it would be on time, on budget, with the agreed upon scope and the agreed upon quality.

EXHIBIT 1.4 PROJECT CUSTOMER TRADEOFF MATRIX

ENHANCE MEET SACRIFICE

Cost Pay up to $5,000 extra if it saves 10 days

Schedule Save up to 10 days

Quality Must meet

Scope Must meet

Source: Adapted from Timothy J. Kloppenborg and Joseph A. Petrick, Managing Project Qualify (Vienna, VA: Management Concepts, 2002): 46.

10 Part 1 Organizing Projects

However, many things can happen as a project is conducted. Obstacles or challenges that may limit the ability to perform often arise, as well as opportunities to exceed original expec- tations. A project manager needs to understand which of these four goals and constraints (scope, quality, time, budget) should take precedence and which can be sacrificed. The project manager needs to help the customer articulate how much he wants to enhance achievement of one of these four dimensions. The customer must also state which dimension he is willing to sacrifice, by how much, and under what circumstances to receive better achievement of the other one. For example, on a research and development project, a customer may be willing to pay an extra $5,000 to finish the project 10 days early. On a church construction project, a customer may be willing to give up five extra light switches in exchange for greater confidence that the light system will work properly. Understanding the customer’s desires in this manner enables a project manager to make good project decisions. A project manager can use a project customer tradeoff matrix such as the one in Exhibit 1.4 to reflect the research and development project tradeoffs discussed above.

From an internal perspective a project manager also needs to consider two more con- straints: the amount of resources available and the decision maker’s risk tolerance. From an agile perspective, resources (including cost) and schedule are considered fixed and what can vary is value to the customer.

1-4e Defining Project Success and Failure Project success is creating deliverables that include all of the agreed-upon features (meet scope goals). The outputs should satisfy all specifications and please the project’s custo- mers. The customers need to be able to use the outputs effectively as they do their work (meet quality goals). The project should be completed on schedule and on budget (meet time and cost constraints).

Project success also includes other considerations. A successful project is one that is com- pleted without heroics—that is, people should not burn themselves out to complete the proj- ect. Those people who work on the project should learn new skills and/or refine existing skills. Organizational learning should take place and be captured for future projects. Finally, the performing organization should reap business-level benefits such as development of new products, increased market share, increased profitability, decreased cost, and so on. A con- temporary and complete view of project success is shown in Exhibit 1.5.

Project failure can be described as not meeting the success criteria listed in Exhibit 1.5. Many projects are fully successful in some ways but less successful in others. The goal of excellent project management is to reach high levels of success on all mea- sures on all projects. Serious project failure—when some of the success criteria are

A G I L E

EXHIBIT 1.5 PROJECT SUCCESS

• Meeting Agreements —Cost, schedule, and specifications met

• Customer’s Success —Needs met, deliverables used, customer satisfied

• Performing Organization’s Success —Market share, new products, new technology

• Project Team’s Success —Loyalty, development, satisfaction

Source: Adapted from Timothy J. Kloppenborg, Debbie Tesch, and Ravi Chinta, “21st Century Project Success Measures: Evolution, Interpretation, and Direction,” Proceedings, PMI Research and Education Conference 2012 (Limerick, Ireland, July 2012).

Chapter 1 Introduction to Project Management 11

missed by a large amount and/or when several of the success criteria are missed—can be attributed to numerous causes. In each chapter of this text, more specific possible failure causes will be covered, along with how to avoid them, but some basic causes of failure are as follows:

• Not enough resources are available for project completion. • Not enough time has been given to the project. • Project expectations are unclear. • Changes in the scope are not understood or agreed upon by all parties involved. • Stakeholders disagree regarding expectations for the project. • Adequate project planning is not used.

1-4f Using Microsoft Project to Help Plan and Measure Projects A useful tool to capture and conveniently display a variety of important project data is Microsoft® (MS) Project. MS Project is demonstrated in a step-by-step fashion using screen shots from a single integrated project throughout the book.

1-4g Types of Projects Four ways to classify projects that help people understand the unique needs of each are by industry, size, understanding of project scope, and application.

CLASSIFYING BY INDUSTRY Projects can be classified in a variety of ways. One method is by industry, which is useful in that projects in different industries often have unique requirements. Several industry-specific project life cycle models are in use, and various trade groups and special interest groups can provide guidance. For example, PMI had 39 specific communities of practice as of March 1, 2013, as shown in Exhibit 1.6. These groups allow project managers worldwide to share and learn

EXHIBIT 1.6 PMI COMMUNITIES OF PRACTICE

Aerospace and Defense Global Diversity New Practitioners

Agile Global Sustainability Organizational Project Management

Automation Systems Government Pharmaceutical

Change Management Healthcare Program Management Office

China Project Management Human Resource Project Management Project Management Quality

Construction Industry Information Systems Project Risk Management

Consulting Innovation and New Product Development Requirements Management

Earned Value Management International Development Retail

eBusiness IT and Telecom Scheduling

Energy, Oil, Gas and Petrochemical Leadership in Project Management Service and Outsourcing

Entertainment Learning, Education, and Development Transportation

Ethics in Project Management Legal Project Management Troubled Projects

Financial Services Industry Marketing and Sales Utility Industry

Source: http://www.pmi.org/Get-Involved/Communities-of-Practice.aspx, accessed March 1, 2013.

12 Part 1 Organizing Projects

together. Many of those groups are devoted to specific challenges faced by project managers in a particular industry.

CLASSIFYING BY SIZE Another method of classifying projects is by size. Large projects often require more detailed planning and control. However, even the smallest projects still need to use planning and control—just in a more simplified manner. For example, construction of a multistory building in China would require a highly detailed construc- tion schedule, but even a much simpler construction project of building a one-car garage would also need to follow a schedule.

CLASSIFYING BY TIMING OF PROJECT SCOPE CLARITY A third method of classi- fying projects deals with how early in the project the project manager and team are likely to be able to determine with a high degree of certainty what the project scope will be. For example, it may be rather simple to calculate the cubic feet of concrete that are required to pour a parking lot and, therefore, how much work is involved. At the oppo- site end of the spectrum, when developing a new pharmaceutical, very little may be determined in the project until the results of some early experiments are reported. Only at that time is it possible to begin estimating cost and determining the schedule with confidence. The planning becomes iterative, with more detail as it becomes available. In the first case, predictive or plan-driven project techniques may work well. In the second case, adaptive or change-driven methods to iteratively determine the scope and plan for risks may be more important.

CLASSIFYING BY APPLICATION For the purpose of this book, we will discuss many types of projects, such as those dealing with organizational change, quality and pro- ductivity improvement, research and development (R&D), information systems (IS), and construction. Many of these projects include extensive cross-functional work, which adds to the challenge. Remember, all projects require planning and con- trol. Part of the art of project management is determining when to use certain tech- niques, how much detail to use, and how to tailor the techniques to the needs of a specific project.

A large construction project, like this multistory building in China, requires a highly detailed construction schedule.

© Ch in a Ph ot os /G et ty Im ag es

Chapter 1 Introduction to Project Management 13

1-4h Scalability of Project Tools Projects range tremendously in size and complexity. In considering construction projects, think of the range from building a simple carport to building an office tower. In both cases, one would need to determine the wants and needs of the customer(s), understand the amount of work involved, determine a budget and schedule, decide what workers are available and who will do which tasks, and then manage the construction until the owner accepts the project results. It should be easy to see that while both projects require plan- ning and control, the level of detail for the carport is a tiny fraction of that for the office tower. In this book, we first demonstrate concepts and techniques at a middle level and then use a variety of project examples to demonstrate how to scale the complexity of the techniques up or down.

1-5 Project Roles To successfully initiate, plan, and execute projects, a variety of executive, management, and associate roles must be accomplished, as shown in Exhibit 1.7. In a large organiza- tion, a person often fills only one of these roles; sometimes, more than one person fills a particular role. In small organizations, the same person may fill more than one role. The names of the roles also vary by organization. The work of each role must be accom- plished by someone. Project managers are successful when they build strong working relationships with the individuals who execute each of these roles.

1-5a Project Executive-Level Roles The four project executive-level roles are the steering team, sponsor, customer, and the chief projects officer. A steering or leadership team for an organization is often the top leader (CEO or other officer) and his or her direct reports. From a project standpoint, the important role for this team is to select, prioritize, and resource projects in accor- dance with the organization’s strategic planning and to ensure that accurate progress is reported and necessary adjustments are made.

The second executive-level project role is that of sponsor. PMI’s official definition of a sponsor is “the person or group that provides resources and support for the project and is accountable for enabling success.”25 This textbook expands the sponsor’s role to include taking an active role in chartering the project, reviewing progress reports, playing a behind-the-scenes role in mentoring, and assisting the project manager throughout the project life.

The third executive-level project role is that of the senior customer representative. This person ensures that the needs and wants of the various constituents in the customer’s orga- nization are identified and prioritized and that project progress and decisions continually support the customer’s desires. In agile projects, the customer representative role is contin- uous and active. The chief projects officer’s role is sometimes called a project management office (PMO), which is defined as “an organizational structure that standardizes the project related governance processes and facilitates the sharing of resources, methodologies, tools and techniques.”24 The PMO can range from supporting project managers, to controlling them by requiring compliance to directive in actually managing projects.

1-5b Project Management-Level Roles The most obvious management-level role is the project manager. The project manager is “the person assigned by the performing organization to lead the team that is responsible for achieving the project objectives.”63 The project manager is normally directly account- able for the project results, schedule, and budget. This person is the main communicator,

A G I L E

14 Part 1 Organizing Projects

is responsible for the planning and execution of the project, and works on the project from start to finish. The project manager often must get things done through the power of influence since his or her formal power may be limited.

Another key management role is the functional manager. Functional managers are the department heads—the ongoing managers of the organization. They normally determine how the work of the project is to be accomplished, often supervise that work, and often negotiate with the project manager regarding which workers are assigned to the project.

The third managerial role is that of facilitator. If the project is complex and/or con- troversial, it sometimes makes sense to have another person help the project manager with the process of running meetings and making decisions.

1-5c Scrum Master In agile projects, a new title is introduced—the scrum master. In effect, this is a project manager who serves and leads in a collaborative, facilitating manner.

1-5d Project Associate-Level Roles The project management team is composed of “members who are directly involved in project management activities.”27 In this book, these individuals are called core team members. The core team, with the project manager, does most of the planning and makes most of the project-level decisions.

The temporary members that are brought on board are called subject matter experts. These people are used on an as-needed basis.

1-6 Overview of the Book Contemporary project management blends traditional, plan-driven and contemporary, agile approaches. It is integrative, iterative, and collaborative. Project management is in- tegrative since it consists of the 10 knowledge areas and the 5 process groups described in the PMBOK® Guide, and one must integrate all of them into one coherent and ethical whole. Project management is iterative in that one starts by planning at a high level and then repeats the planning in greater detail as more information becomes available and the date for the work performance approaches. Project managers need to balance plan- ning, control, and agility. Project management is collaborative since there are many sta- keholders to be satisfied and a team of workers with various skills and ideas who need to work together to plan and complete the project. With these thoughts of integration, iter- ation, and collaboration in mind, this book has three major parts: Organizing and Initi- ating Projects, Planning Projects, and Performing Projects.

1-6a Part 1: Organizing and Initiating Projects Part 1 consists of four chapters that deal with organizing for and initiating projects.

EXHIBIT 1.7 PROJECT ROLES

EXECUTIVE ROLES MANAGERIAL ROLES ASSOCIATE ROLES

Steering team Project manager Core team member

Chief projects officer Functional manager Subject matter expert

Sponsor Facilitator

Senior customer representative

A G I L E

Chapter 1 Introduction to Project Management 15

CHAPTER 2 covers project selection and prioritization. This includes both internal pro- jects, which should be selected in a manner consistent with the strategic planning of the organization, and external projects. It also explains how to respond to requests for proposals.

CHAPTER 3 focuses on organizational structure, organizational culture, project life cycle, and project management roles of the parent organization. The organizational structure section describes ways an organization can be configured and the advantages and disadvantages of each in regard to managing projects. Next covered is the culture of the parent organization and the impact it has on the ability to effectively plan and manage projects. The industry and type of project often encourage managers to select or customize a project life cycle model. The roles covered include executive-, managerial-, and associate-level responsibilities that must be performed. The demands of each role are explained, along with suggestions for how to select and develop people to effectively fill each role, considering both the role and the unique abilities and inter- ests of each person.

CHAPTER 4 discusses chartering projects. The project charter is “a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.”28 The charter can further be considered an agreement by which the project sponsor and project manager (and often the project core team) agree at a high level what the project is, why it is important, key milestone points in the schedule, major risks, and possibly a few other items. It allows the project manager and core team to understand and agree to what is expected of them. Finally, Microsoft Proj- ect, a tool that facilitates effective project planning, controlling, and communicating, is introduced. Microsoft Project is utilized in eight chapters to demonstrate how to auto- mate various project planning and control techniques. The examples and illustrations in this book use Microsoft Project 2013. If a person is using an earlier version of Microsoft Project, there are slight differences. If a person is using a competing project scheduling package, the intent remains the same, but the mechanics of how to create certain docu- ments may differ.

EXHIBIT 1.8 PROJECT LIFE CYCLE WITH MEASUREMENT POINTS

Other Approvals

Closing & Realizing

Administrative Closure

Benefits Measures

Level of Effort

Stage

Stage Ending Gates

Selecting & Initiating

Charter

Selection

Planning

Kickoff

Executing

Project Result

Progress Reports

16 Part 1 Organizing Projects

1-6b Part 2: Planning Projects Part 2 includes seven chapters dealing with various aspects of project planning.

CHAPTER 5 begins by identifying the various project stakeholders, their wants and needs, and how to prioritize decisions among them. Chapter 5 also includes communica- tions planning for the project because poor communication can doom an otherwise well- planned and well-managed project. The information needs of each stakeholder group should be included in the communications plan.

CHAPTER 6 shows how to determine the project scope and outline it in the work breakdown structure (WBS). The WBS is “a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.”29 The WBS is a document that progressively breaks the project down into its components so that each piece can be described as a deliverable for which one person can plan, estimate the costs, estimate the time, assign resources, manage, and be held accountable for the results. This is a critical document since it is the foundation for most of the other planning and control. The chapter ends with instructions on putting a WBS into Microsoft Project.

CHAPTER 7 deals with scheduling projects. The project schedule “presents linked activities with planned dates, durations, milestones and resources.”30 This chapter starts with a background on project scheduling and then covers construction of schedules by defining activities, determining the order in which they need to be accomplished, esti- mating the duration for each, and then calculating the schedule. Chapter 7 also includes instructions on how to interpret a project schedule; clearly communicate it using a bar chart called a Gantt chart; and use Microsoft Project to construct, interpret, and commu- nicate project schedules.

CHAPTER 8 demonstrates how to schedule resources on projects: determining the need for workers, understanding who is available, and assigning people. All of the techniques of resourcing projects are integrated with the behavioral aspects of how to deal effectively and ethically with the people involved. Resource needs are shown on a Gantt chart de- veloped in Chapter 7, the responsibilities are shown as they change over time, conflicts and overloads are identified, and methods for resolving conflicts are introduced. Alterna- tive approaches for creating and compressing schedules are shown. Many of the techni- ques in this chapter are also shown with MS Project.

CHAPTER 9 A project budget, the subject of this chapter, is dependent on both the schedule and the resource needs developed in the previous two chapters. The budget is “the approved estimate for the project or any work breakdown structure component or any schedule activity.”31 Cost planning, estimating, budgeting, establishing cost control, and using MS Project for project budgets are all included.

CHAPTER 10 starts with establishing a risk management plan. It covers methods for identifying potential risks and for determining which risks are big enough to justify specific plans for either preventing the risk event from happening or dealing effec- tively with risk events that do happen. Finally, in risk response planning, strategies for dealing with both positive risks (opportunities) and negative risks (threats) are discussed.

CHAPTER 11 begins with a discussion of how modern project quality concepts have evolved. Then it deals with core project quality demands of stakeholder satisfaction, empowered performance, fact-based management, and process management. The third

Chapter 1 Introduction to Project Management 17

chapter topic is developing the project quality plan. Next, the chapter describes various quality improvement tools for projects.

Since this is the last planning chapter, it concludes with a method of integrating the various sections developed in the previous chapters into a single, coherent project plan. Conflicts that are discovered should be resolved, judgment needs to be applied to ensure that the overall plan really makes sense, and one or more kickoff meetings are normally held to inform all of the project stakeholders and to solicit their enthu- siastic acceptance of the plan. At this point, the project schedule and budget can be baselined in MS Project. While bits of the project that might have caused delays if they were not started early may already be in progress, the formal kickoff is the sig- nal that the project is underway!

1-6c Part 3: Performing Projects Part 3 includes four chapters that deal with performing the project.

CHAPTER 12 begins by introducing relevant supply chain concepts such as a supply chain view of projects, the components that form a supply chain, factors to consider when dealing with a supply chain, and methods of improving the performance of a supply chain. Make-or-buy analysis and contract types lead the reader through pro- curement planning. Identifying and selecting sellers lead into managing contracts to assure receipt of promised supplies and services according to contractual terms. The chapter ends with advantages and requirements of effective project partnering.

CHAPTER 13 describes how to carry out the project work with a project team in order to accomplish the project objectives. The project manager needs to simultaneously cham- pion the needs of the project, the team, and the parent organization. The project man- ager manages the people side of the project by effectively using the stages of project team development, assessing and building the team members’ capability, supervising their work, managing and improving their decision making, and helping them maintain enthusiasm and effective time management. Project managers guide their team in managing and controlling stakeholder engagement.

CHAPTER 14 While the project work is being performed, the project manager needs to determine that the desired results are achieved—the subject of this chapter. Monitor and control project work is defined as “the process of tracking, reviewing, and reporting the progress to meet the performance objectives defined in the project management plan.”32

This starts with gathering performance data already identified during project initiating and planning. The actual performance data are then compared to the desired perfor- mance data so that both corrective and preventive actions can be used to ensure that the amount and quality of the project work meet expectations. MS Project can be used for this progress reporting and for making adjustments. Earned value analysis is used to determine exactly how actual cost and schedule progress are compared with planned progress. Overcoming obstacles, managing changes, resolving conflicts, reprioritizing work, and creating a transition plan all lead up to customer acceptance of the project deliverables.

CHAPTER 15 deals with finishing projects and realizing benefits. Close project or phase is defined as “the process of finalizing all activities across all of the project process groups to formally close a project or phase.”30 This chapter includes a section on terminating projects early, in case either the project is not doing well or conditions have changed and the project results are no longer needed, and a section on timely termination of successful projects. Topics include how to secure customer feedback and use it along with the team’s

18 Part 1 Organizing Projects

experiences to create lessons learned for the organization; reassign workers and reward those participants who deserve recognition; celebrate success; perform a variety of closure activities; and provide ongoing support for the organization that is using the results of the project. Finally, after the project deliverables have been used for some time, an assessment should determine if the promised benefits are being realized.

Summary A project is an organized set of work efforts undertaken to produce a unique output subject to limitations of time and resources such as money and people. Since the world is changing more rapidly than in the past, many people spend an increasing amount of their working time on projects. Project management includes work processes that initiate, plan, execute, monitor and control, and close project work. During these processes, tradeoffs must be made among the scope, quality, cost, and schedule, so that the project results meet the agreed-upon requirements, are useful to the customers, and promote the organization.

All projects, regardless of size, complexity, or appli- cation, need to be planned and managed. While the level of detail and specific methods vary widely, all need to follow generally accepted methods. PMI is a large professional organization devoted to promoting and standardizing project management understanding and methods. One of PMFs standards, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), is composed of 5 process groups: initiating,

planning, executing, monitoring and controlling, and closing; along with 10 knowledge areas: integration, scope, time, cost, quality, human resources, communi- cations, risk, procurement, and stakeholders.

To successfully initiate, plan, and execute projects, two more things are needed. One is to understand what proj- ect success is and what drives it, along with what project failure is and its major causes. The other is an under- standing of the various executive-, managerial-, and associate-level roles in project management. This book is organized to be useful to students who will enter a variety of industries and be assigned to projects of all sizes and levels of complexity. Students will learn how to understand and effectively manage each of these process groups and knowledge areas. Microsoft Project 2013 is used in eight chapters to illustrate how to automate vari- ous planning, scheduling, resourcing, budgeting, and controlling activities. All definitions used are from the PMBOK Guide, fifth edition. This book follows a chrono- logical approach throughout a project’s life cycle, empha- sizing knowledge and skills that lead to project success.

Key Terms from the PMBOK® Guide The glossary in this book exclusively uses terms as defined in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) project, 4 stakeholders, 4 project management, 4 functional manager, 6 project life cycle, 6 project management process group, 9 initiating processes, 9 planning processes, 9 executing processes, 9 monitoring and controlling processes, 9 closing processes, 9 integration management, 9 scope management, 9 time management, 9 cost management, 9 quality management, 9

human resources management, 9 communications management, 9 risk management, 9 procurement management, 9 stakeholder management, 9 scope, 10 quality, 10 project management office (PMO), 14 sponsor, 14 project manager, 14 project management team, 15 project charter, 16 work breakdown structure (WBS), 17 project schedule, 17 budget, 17 monitor and control project work, 18 close project or phase, 18

Chapter 1 Introduction to Project Management 19

Chapter Review Questions 1. What is a project? 2. What is project management? 3. How are projects different from ongoing

operations? 4. What types of constraints are common to most

projects? 5. Which deliverable authorizes the project team to

move from Selecting & Initiating to Planning? 6. At what stage of a project life cycle are the

majority of the “hands-on” tasks completed? 7. During which stage of the project life cycle are

loose ends tied up? 8. What are the five process groups of project

management? 9. Which process group defines a new project or

phase by obtaining authorization?

10. What are the 10 project management knowledge areas?

11. What two project dimensions are components of project performance?

12. How do you define project success? 13. How do you define project failure? 14. List four common causes of project failure. 15. What are three common ways of classifying

projects? 16. What is predictive or plan-driven planning, and

when should it be used? 17. What is adaptive or change-driven planning and

when should it be used? 18. What makes someone a project stakeholder? 19. What are the three project executive-level roles? 20. List and describe each of the managerial and

associate roles.

Discussion Questions 1. Using an example of your own, describe a project

in terms that are common to most projects. 2. Why are more organizations using project man-

agement? If you were an executive, how would you justify your decision to use project manage- ment to the board of trustees?

3. Explain how to scale up or down the complexity of project planning and management tools and what effect, if any, this might have on the project life cycle.

4. List and describe several issues that pertain to each stage of the project life cycle.

5. Put the five project management process groups in order from the one that generally requires the least work to the one that requires the most.

6. Name the 10 project management knowledge areas, and briefly summarize each.

7. Discuss how a project could be successful in terms of some measures yet unsuccessful by others.

8. What does project failure mean? What are some examples?

9. Compare and contrast advantages and disad- vantages of predictive/plan-driven and adaptive/change-driven project life cycle approaches.

10. You are given a project to manage. How do you decide whether to use a predictive or adaptive approach?

11. Contrast project managers and functional managers.

12. List as many project roles as you can, and iden- tify what each one is responsible for in terms of the project.

PMBOK® Guide Questions The purpose of these questions is to help visualize the type of questions on PMP and CAPM exams.

1. Which project role provides resources or support for the project, promotes and protects the project at higher levels of management, and takes an active role in the project from the chartering stage through project closure? a. functional manager b. project manager c. project team member d. project sponsor

2. Which PMBOK® Guide Knowledge Area includes those processes required to ensure that the proj- ect includes all the work required, and only the work required, to complete the project successfully? a. cost management b. scope management c. risk management d. quality management

20 Part 1 Organizing Projects

3. In order to be successful, the project team must be able to assess the needs of stakeholders and manage their expectations through effective communications. At the same time they must balance competing demands between project scope, schedule, budget, risk, quality, and resources, which are also known as project _____? a. plan elements b. deliverables c. constraints d. targets

4. In which project management process group would you find those processes that establish the scope of effort for the project, refine the project objectives, and define the course of action to achieve the objectives? a. initiating process group b. planning process group c. executing process group d. monitoring and controlling process group

5. Projects pass through a series of phases as they move from initiation to project closure. The names and number of these phases can vary significantly depending on the organization, the type of application, industry, or technology employed. These phases create the framework for the project, and are referred to collectively as the: a. project life cycle b. project management information system (PMIS) c. product life cycle d. quality methodology

6. Based on PMI’s definition, which of these is a good example of a project? a. manufacturing a standard commodity b. following policies and procedures for procur-

ing an item c. designing and launching a new website d. using a checklist to perform quality control

7. The responsibilities of a project management of- fice (PMO) and the degree of control that it provides can cover a broad spectrum. All of these

are examples of types of PMO structures within organizations except: a. controlling—require compliance through

various means b. selective—review business cases and select and

prioritize projects to be initiated c. supportive—perform a consultative role

through training, templates, and best practices d. directive—provide a high degree of control by

directly managing the projects 8. When would a predictive project life cycle be the

preferred approach? a. when the high-level vision has been developed,

but the product scope is not well defined b. when the environment is changing rapidly c. when the product to be delivered is well

understood d. when the product will be created through a

series of repeated cycles 9. To be effective, a project manager needs

to possess all of the following competencies except: a. personal effectiveness—attitudes, core person-

ality traits, leadership b. authority—power or right granted by the

organization c. performance—what project managers can

accomplish while applying their project man- agement knowledge

d. knowledge of project management—under- standing of project management tools and techniques

10. In Adaptive Life Cycles (change—driven or agile methods) ________. a. the overall scope of the project is fixed,

and the time and cost are developed incrementally

b. the overall cost is fixed, and the project scope and schedule are developed iteratively

c. the time and cost are fixed, but the scope is developed iteratively

d. change control is very important

Example Project Instructions This book is designed to give your professors the option to have you practice the concepts and techni- ques from each chapter on a real project. Often, the project chosen will be for a nonprofit group of some kind such as a United Way agency, a church, or a school. The project could, however, be for a company

or a part of the university. For traditional classes, the example project can often be one that several stu- dents will be assigned to work on as a team. For online classes, it may be more practical to have each student work on a separate project at his or her place of employment.

Chapter 1 Introduction to Project Management 21

Each chapter provides suggested assignments to practice project management skills on the real or potential project you are using. Depending on the emphasis your professor chooses, you may need to per- form some, most, or all of these assignments. At a min- imum, your professor will probably assign the charter, work breakdown structure, and schedule.

In any case, each chapter after this prompts you to perform various activities to plan and execute the proj- ect. At some point in the first couple of weeks, your professor will probably invite at least one representative from each organization to your class to introduce their project and to meet you. We will call these per- sons sponsors and define their role more fully in Chapter 3. Since this first chapter is a broad introduc-

tion to project management, your task for the Chapter 1 sample project is to familiarize yourself with your new student team, your sponsor, your sponsor’s organiza- tion, and the overall direction of your project. Your professor may ask you to answer certain specific and/or open-ended questions concerning your newly assigned project.

Subsequent chapters give you more in-depth tools to acclimatize you to your project, the organization you will be working for, and the various stakeholders who have an interest in the project. For example, in the next chapter, you learn how project selection flows from an organization’s strategic planning, and you should seek to learn why this project was chosen and how it sup- ports the strategic goals of the organization.

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Cooper, Robert G., “Winning at New Products: Pathways to Profitable Innovation,” Proceedings, PMI Research Conference 2006 (Montreal, July 2006).

Crowe, Andy, Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not (Atlanta: Velociteach, 2006).

Kloppenborg, Timothy J., and Warren A. Opfer, “The Current State of Project Management Research: Trends, Interpretations, and Predictions,” Project Management Journal 33 (2) (June 2002): 5–18.

Kloppenborg, Timothy J., Debbie Tesch, and King, Broderick, “21st Century Project Success Measures: Evolution, Interpretation, and Direction,” Proceed- ings, PMI Research and Education Conference 2012 (Dublin, Ireland, July 2012).

Muller, R., and R. Turner, “The Influence of Project Managers on Project Success Criteria by Type of Project,” European Management Journal 25 (4) (2007): 298–309.

PMI Community of Practice Listing, http://www.pmi .org/Getlnvolved/Pages/Communities-of-Practice .aspx, accessed March 1, 2013.

Shenhar, A. J., and D. Dvir, Reinventing Project Manage- ment (Boston: Harvard Business School Press, 2007).

Endnotes 1. PMBOK® Guide 553. 2. PMBOK® Guide 563. 3. PMBOK® Guide 554. 4. PMBOK® Guide 6. 5. PMBOK® Guide 541. 6. PMBOK® Guide 554. 7. Robert G. Cooper, “Winning at New Products:

Pathways to Profitable Innovation,” Proceedings, 2006).

8. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013). Copyright and all rights reserved. Material from this publication has been reproduced with permission of PMI.

9. www.pmi.org/about0us.aspx, accessed March 1, 2013.

10. PMBOK® Guide 554. 11. PMBOK® Guide 49. 12. PMBOK® Guide 63. 13. PMBOK® Guide 105. 14. PMBOK® Guide 141. 15. PMBOK® Guide 193. 16. PMBOK® Guide 227. 17. PMBOK® Guide 255. 18. PMBOK® Guide 287. 19. PMBOK® Guide 309. 20. PMBOK® Guide 355. 21. PMBOK® Guide 391. 22. PMBOK® Guide 562.

22 Part 1 Organizing Projects

23. PMBOK® Guide 556. 24. PMBOK® Guide 554. 25. PMBOK® Guide 563. 26. PMBOK® Guide 555. 27. PMBOK® Guide 555. 28. PMBOK® Guide 553.

29. PMBOK® Guide 567. 30. PMBOK® Guide 555. 31. PMBOK® Guide 530. 32. PMBOK® Guide 546 . 33. PMBOK® Guide 531.

PROJECT MANAGEMENT I N ACT I ON

Using Appreciative Inquiry to Understand Project Management

Each project creates a unique product, service, or result that certain stakeholders desire. Project success requires understanding stakeholder requirements, clarifying project expectations, and agreeing upon project scope. As such, it is imperative to identify relevant stakeholders and to have a constructive engagement with them. One tool that is helpful for allowing such engagement and for navigating through complexities is Appreciative Inquiry (Al).

What Is Appreciative Inquiry? The principles: Appreciative inquiry is a positive philosophy for changewhereinwhole systems convene to inquire for change (Cooperrider 2003). Al recognizes the power of the whole and builds on conversational learning that emergesout of thewhole. It operates on thebelief that human systemsmove in the direction of their shared image and idea of the future, and that change is based on intentional and positive inquiry into what has worked best in the past. In this sense, Al suggests that human organizing and change is a relational process of inquiry that is grounded in affirmationandappreciation. Typically, the process works its way through the four phases of Discovery, Dream, Design, and Delivery (Conklin, 2009).

Implications of Al on Defining Project Scope Project success partially depends upon identifying key stakeholders: eliciting their true wants and needs to determine project scope; and keeping them appropriately engaged throughout the entire project. The early involvement is critical because it lays out clear goals and boundaries of project scope. However, eliciting accurate responses may be difficult, especially since many projects may be planned and conducted in an atmosphere of uncertainty. The ongoing involvement helps to ensure stakeholders know what they will get from the project and will be pleased.

Appreciative inquiry is a tool that may assist project stakeholders to navigate through their inquiries via positive conversations. For example, a typical process may look like this:

Discovery (What has been?): This phase inquires into and discovers the positive capacity of a group, organization, or community. People are encouraged to use stories to describe their strengths, assets, peak experiences, and successes to understand the unique conditions that made their moments of excellence possible. In this step, stakeholders reflect on the past to recollect instances when they believed they could clearly articulate their true needs and wants; and when their needs and wants were folded into the project scope. Through story- telling, they collectively discover the process of project selection and prioritization, and articulate a gauge of project success. As they discuss, they start generating a dense web of understanding—an understanding and an appreciation of all their capacities that make moments of excellence possible. Agile projects use a similar method of story telling to understand user requirements and ultimately define project scope.

Dreaming (What could be?): Building on the moments of excellence of the participants, this phase

Delivery: What will

be?

Discovery: What has

been?

Design: What

should be?

Dream: What

could be?

Source: Adapted from Conklin, 2009.

Chapter 1 Introduction to Project Management 23

encourages the participants to imagine what would happen if their moments of excellence were to become a norm. Participants dream for the ideal conditions and build hope and possibility of an ideal future. As people share their stories, the focus of the process now shifts to dreaming a perfect, desirable state for the stakeholders. Through this journey, the goal should be to enable the participants to build positive energy around their strengths and also to dream about the direction in which they feel comfortable moving.

Designing (What should be?): This phase creates design principles that will help the participants realize their dream. Participants are encouraged to stretch their imagination to move the system from where it currently is to where the participants want it to be. At this stage, the participants should be encouraged to imagine a perfect world without any constraints. Therefore, if there were no resource constraints, what would the scope of the project look like.

Delivery (What will be?): In this phase, participants are encouraged to think of the various subsystems that should take the responsibility of the design phase to

“sustain the design from the dream that it discovered” (Cooperrider et al., 2003, p. 182). In this phase, various stakeholders are encouraged to decide what they will be committing themselves to.

Key Outcome Going through this entire process allows stakeholders to elicit and articulate their expectations from the project. Stakeholders also have a better understanding of how their needs and wants link to and lead them to a desirable future state. Finally, in order to sustain their dream, their commitment is clearly articulated. As stakeholders commit themselves to specific endeavors on the project, theywill implicitly revisit the opportunities and cost that lay ahead of them which allows stakeholders to draw a realistic boundary around their commitment to the project.

Projects are temporary and unique, and may have shifting boundaries over time. The process of engaging stakeholders via appreciative inquiry (AI) is an effective way to address the ambiguity and uncertainty in project management.

Source: Rashmi Assudani, Associate Professor and Chair, Department of Management and Entrepreneurship, Williams College of Business, Xavier University. Adapted from Conklin, T. A., “Creating Classrooms of Preference: An Exercise in Appreciative Inquiry.” Journal of Management Education 33 (6) (2009): 772–792. Cooperrider, D. L., D. Whitney, and J. M. Stavros, Appreciative Inquiry Handbook (Bedford Heights, OH: Lakeshore, 2003).

24 Part 1 Organizing Projects

CHA P T E R 2 Project Selection and Prioritization

How does a truly global company with fewer than 200 associates achieve noteworthy results and market leadership? Certainly strong and talented people are a key part of the answer. A good set of leadership and management tools and processes, and the discipline to use them, is another key. A small, privately held company in Louisville, Kentucky, has been fortunate to use both talent and process to achieve success by any measure. That company is D. D. Williamson.

D. D. Williamson was founded in 1865 and today is a global leader in non- artificial colors. Operating nine facilities in six countries and supplying many of the best-known food and beverage companies around the world, D. D. Williamson has more complexity to manage than most companies, regardless of their size.

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Explain in your own words the strategic planning and portfolio management processes.

• Compare strengths and weaknesses of using financial and scoring models to select projects.

• Describe how to select, prioritize, and resource projects as an outgrowth of strategic planning.

• Given organizational priorities and several projects, demonstrate how to select and prioritize projects using a scoring model.

• From a contractor’s viewpoint, describe how to secure projects.

© w av eb re ak m ed ia /S hu tte rs to ck .c om

26

Topics:

• Portfolio management

• Program management

• Projects and strategic planning

• Source selection criteria

• Statement of work

• Business case

D. D. Williamson identified the need to improve project management as a key strategy to achieve the vision. Our weakness was twofold—we had too many projects, and the projects that were active were sometimes late, over budget, and not achieving the desired results. We began by creating a prioritization matrix to select 16 “critical projects” that would have senior leadership sponsors and be assigned trained and capable project managers to improve our execution.

The prioritization matrix was a great initial step to narrow our focus and improve our results—overall project completion improved. However, 16 projects meant that the scope and impact of projects still had wide variation. Smaller, simpler projects were likely to be executed brilliantly and improve our total percentage of “on time and on target” projects, but if the project that was late or over budget was very high impact, we were still leaving opportunities for growth and profitability on the table.

We next improved our prioritization process, selecting no more than five “Vision Impact Projects” (VIPs) that would get high-level focus and attention—monitoring and asking for corrective measures in weekly senior management meetings, tracking online in our project management system for our Continuous Improvement Manager, and tunneling time and resources to help when projects get off course.

The results are dramatic—large and complicated projects are getting the attention and resources and are achieving our strategic target of “on time, on budget and on target” regularly. Our successes have positioned D. D. Williamson to continue to do what we do best—serve customers effectively, grow our business, and return strong financial results to ensure a solid future for the business.

Elaine Gravatte, Chief People Officer and North American President, D. D. Williamson

PMBOK® Guide

27

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative Closure

Planning Executing Closing RealizingInitiating

RealizedResultTo Proceed

2-1 Strategic Planning Process One of the tasks of a company’s senior leadership is to set the firm’s strategic direction. Some of this direction setting occurs when an organization is young or is being revamped, but some needs to occur repeatedly. Exhibit 2.1 depicts the steps in strategic planning and how portfolio management should be an integral part.

2-1a Strategic Analysis The first part of setting strategic direction is to analyze both the external and internal environments and determine how they will enhance or limit the organization’s ability to perform. This strategic analysis is often called strengths, weaknesses, opportunities, and threats (SWOT). The internal analysis (elements within the project team’s control) consists of asking what strengths and weaknesses the organization possesses in itself. The external analysis (elements over which the project team has little or no control) consists of asking what opportunities and threats are posed by competitors, suppliers, customers, regulatory agencies, technologies, and so on. The leaders of an organization often need to be humble and open to ideas that are unpleasant when conducting this analysis. Per- formed correctly, a strategic analysis can be very illuminating and can suggest direction for an organization. An example of SWOT analysis for the Built Green Home at Sunca- dia is shown in Exhibit 2.2. (The Built Green Home at Suncadia, Washington, was devel- oped using advanced sustainability concepts and a large degree of stakeholder involvement. A more detailed description of this house appears in Chapter 5.)

2-1b Guiding Principles Once the SWOT analysis is complete, the organization’s leadership should establish guid- ing principles such as the vision and mission. Some organizations break this step into more parts by adding separate statements concerning purpose and/or values. Often, these

EXHIBIT 2.1 STRATEGIC PLANNING AND PORTFOLIO ALIGNMENT

Flow-Down Objectives

Strategic Objectives

Strategic Analysis

Guiding Principles: Vision & Mission

Portfolio Alignment

28 Part 1 Organizing Projects

sections are included in the mission. For simplicity’s sake, they will be treated as part of the mission in this book. It is more important to understand the intent of each portion and achieve it rather than worry about the exact format or names of individual portions.

VISION The vision “must convey a larger sense of organizational purpose.”1 It should be both inspiring and guiding, describing the organization as it can be in the future, but stated in the present tense. A clear and compelling vision will help all members and all stakeholders of an organization understand and desire to achieve it. Visions often require extra effort to achieve but are considered to be worth the effort. Visions are often multi-year goals that, once achieved, suggest the need for a new vision.

One of the visions most often cited, because it was so clear and compelling, was President John F. Kennedy’s goal of placing a man on the moon before the end of the 1960s. Kennedy set this goal after Russia launched Sputnik and the United States found itself behind in the space race. His vision was very effective in mobilizing people to achieve it.

A more recent example was in 2009 when hundreds of community leaders in Cleve- land, Ohio, decided to use a systems approach to guide many interrelated social and economic efforts in their region. The vision they stated is “Cleveland and other cities throughout Northeast Ohio should be green cities on a blue lake….”2 They use this vision to guide regional leaders as they choose where to invest their time and resources in bettering the region and life for its residents.

Increasingly companies are incorporating the triple bottom line into their vision state- ments. This approach emphasizes the social, environmental, and economic health of all of the company’s stakeholders rather than a narrow emphasis only on the economic return for shareholders. This stated desire to be a good corporate citizen with a long-term view of the world can motivate efforts that achieve both economic return for shareholders and other positive benefits for many other stakeholders.

EXHIBIT 2.2 SWOT ANALYSIS FOR THE BUILT GREEN HOME AT SUNCADIA

STRENGTHS WEAKNESSES

Green building has a buzz Green building has not reached mainstream

Seattle has a strong green building community Limited project resources community

support Distance away from Seattle

Strong community support Green building is perceived to be costly

Growth in green building projects that demonstrate value

High cost of green projects

Need to provide numbers on green building value

Committed developer and builder

OPPORTUNITIES THREATS

Uniqueness of product

Location

Existing thinking on green building and its niche focus

Community surrounding house Building schedule

Lack of data on green building (wealth) value Community (location)

Rumors

Source: Brenda Nunes, developer, BuiltGreen Home at Suncadia.

Chapter 2 Project Selection and Prioritization 29

MISSION STATEMENT The vision should lead into the mission statement, which is a way to achieve the vision. The mission statement includes the “organization’s core purpose, core values, beliefs, culture, primary business, and primary customers.”3 Several of these sections may flow together in the mission statement and, sometimes, an overall statement is formed with expanded definitions of portions for illustration. The rationale for including each section (either as one unified statement or as separate statements) is as follows:

• By including the organization’s purpose, the mission statement communicates why the organization exists.

• By including the organization’s core values, a mission statement communicates how decisions will be made and the way people will be treated. True organizational values describe deeply held views concerning how everyone should act—especially when adhering to those values is difficult.

• By including beliefs, a mission statement communicates the ideals for which its lea- ders and members are expected to stand. Beliefs are deeply held and slow to change, so it is quite useful to recognize them, as they can either help or hinder an organi- zation’s attempt to achieve its vision.

• By including the organization’s culture, the mission statement instructs members to act in the desired manner.

• By including the primary business areas, everyone will know in what business the organization wishes to engage.

• By identifying the primary customers, everyone will understand which groups of people need to be satisfied and who is counting on the organization. The mission needs to be specific enough in describing the business areas and customers to set direction, but not so specific that the organization lacks imagination. An example of a vision and mission statement from Cincinnati Children’s Hospital Medical Center is shown in Exhibit 2.3.

EXHIBIT 2.3 CINCINNATI CHILDREN ’S HOSPITAL MEDICAL CENTER VISION AND MISSION

Vision Cincinnati Children’s Hospital Medical Center will be the leader in improving child health. Mission Statement Cincinnati Children’s will improve child health and transform delivery of care through fully integrated, globally recognized research, education and innovation. For patients from our community, the nation and the world, the care we provide will achieve the best: • Medical and quality of life outcomes • Patient and family experiences and • Value today and in the future.

Source: Cincinnati Children’s Hospital Medical Center, http://www.cincinnatichildrens.org/about/mission/, accessed May 22, 2013.

30 Part 1 Organizing Projects

2-1c Strategic Objectives With the strategic analysis, mission, and vision in place, leaders turn to setting strategic objectives, which should be means of achieving the mission and vision. For most organi- zations, this strategic alignment of objective setting occurs annually, but some organiza- tions may review objectives and make minor revisions at three- or six-month intervals. While the planning is normally performed annually, many of the strategic objectives identified will take well over one year to achieve. The objectives describe both short- and long-term results that are desired along with measures to determine achievement. Orga- nizations that embrace a triple bottom line in their guiding values will have objectives promoting each bottom line, and projects that are selected will contribute toward each. These objectives should provide focus on decisions regarding which projects to select and how to prioritize them, since they are an expression of the organizational focus. Many writers have stated that for objectives to be effective, they should be “SMART—that is specific, measurable, achievable, results-based, and time-specific.”4 An example of strate- gic objectives from The Internet Society is shown in Exhibit 2.4.

2-1d Flow-Down Objectives Once an organization’s strategic objectives are identified, they must be enforced. Some objectives may be implemented by work in ongoing operations. However, projects tend to be the primary method for implementing many objectives. If the organization is rela- tively small, leaders may proceed directly to selecting projects at this point. Larger orga- nizations may elect a different route. If the organization is so large that it is impractical for the overall leaders to make all project selection decisions, they might delegate those decisions to various divisions or functions with the stipulation that the decisions should be aligned with all of the organization’s strategic planning that has taken place to this point. Regardless of whether the organization is small and the top leaders make all proj- ect selection decisions or whether the organization is large and some of the decisions are cascaded one or more levels down, several methods of project selection may be used.

2-2 Portfolio Management Companies that use a strategic project selection process to carefully align projects with their organizational goals will find they tend to be more successful at completing their projects and deriving the expected benefits from them. Portfolio management “aligns with organi- zational strategies by selecting the right projects, prioritizing work, and providing needed resources.”5 “The goal of portfolio management is to achieve the maximum benefit toward the strategic goals of the company. To accomplish this, executives need to identify, select, prioritize, resource, and govern an appropriate portfolio of projects and other work.”6

Governing will be covered in Chapter 14, and all other portfolio management topics will be

EXHIBIT 2.4 INTERNET SOCIETY STRATEGIC OBJECTIVES FOR 2012–2014 PLANNING CYCLE

1. Foster an open, innovative, and trusted Internet worldwide. 2. Advance policies and strategies that strengthen the Internet’s growth and evolution. 3. Enable a vibrant organization and vital global community to enhance the Internet’s future. 4. Empower people to achieve human potential through unencumbered Internet use.

Source: http://www.internetsociety.org/who-we-are/mission, accessed May 22, 2013.

Chapter 2 Project Selection and Prioritization 31

covered here. Project success at these companies is measured by how much the project con- tributes to the organization’s objectives (business needs) as well as the traditional measures of staying within budget and schedule and achieving the specific technical goals promised at the start of the project so as to obtain a desired return on investment.

For ease of understanding how various work is related, many organizations utilize an approach of classifying portfolios, programs, projects, and subprojects. Not all companies use all four classifications, but understanding how they are related helps one see where any particular portion of work fits in the organization.

2-2a Portfolios Organizations require many work activities to be performed, including both ongoing operational work and temporary project work. Large organizations often have many pro- jects underway at the same time. A portfolio is “projects, programs, subportfolios, and operations managed as a group to achieve strategic business objectives.”7 Project portfo- lios are similar to financial portfolios. In a financial portfolio, efforts are made to diver- sify investments as a means of limiting risk. However, every investment is selected with the hope that it will yield a positive return. The returns on each investment are evaluated individually, and the entire portfolio is evaluated as a whole.

Each project in the portfolio should have a direct impact on the organization. Put another way, an organization’s leaders should identify the organization’s future direction through strategic planning. Then multiple possible initiatives (or projects) can be identi- fied that might help further the organization’s goals. The leaders need to sort through the various possible projects and prioritize them. Projects with the highest priority should be undertaken first. Organizations typically try to have a sense of balance in their portfolios. That is, an organization includes in its portfolio:

• Some large and some small projects • Some high-risk, high-reward projects, and some low-risk projects • Some projects that can be completed quickly and some that take substantial time to

finish

2-2b Programs A program is “a group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually.”8

Programs often last as long as the organization lasts, even though specific projects within a program are of limited duration. For example, the U.S. Air Force has an engine pro- curement program. As long as the Air Force intends to fly aircraft, it will need to acquire engines. Within the engine program are many individual projects. Some of these projects are for basic research, some are for development of engines, and others are for purchas- ing engines. Each project has a project manager, and the entire program has a program manager. While the project managers are primarily concerned with the tradeoffs of cost, schedule, scope, and quality on their individual projects, the program manager is con- cerned with making tradeoffs between projects for the maximum benefit of the entire program. To avoid confusion, programs deal with a specific group of related projects, while a portfolio deals with all of an organization’s projects. A portfolio can include mul- tiple programs as well as multiple projects.

While the leadership group of a company may make portfolio decisions and delegate the program management decisions to a program manager, both portfolios and programs are managed at a level above the typical project manager. For practical purposes, project managers should attempt to understand how both portfolio and program decisions impact their projects and then spend most of their efforts focused on their project.

32 Part 1 Organizing Projects

2-2c Projects and Subprojects Just as a program is made up of multiple projects, a large project may be composed of multiple subprojects. A subproject is “a smaller portion of the overall project created when a project is subdivided into more manageable components or pieces.”9 If the proj- ect is quite large, individuals may be assigned as subproject managers and asked to man- age their subproject as a project. Some of those subproject managers may even work for another company. The project manager needs to coordinate the various subprojects and make decisions that are best for the overall project. Sometimes this may require that a particular subproject be sacrificed for the greater project good. The relationships among a portfolio, programs, projects, and subprojects are illustrated in Exhibit 2.5.

Because projects are frequently performed in a fast-paced environment, it is helpful if they can be guided by organizational priorities. Some of the most typical reasons for project failure are:

• Not enough resources • Not enough time • Unclear expectations • Changes to the project • Disagreement about expectations

The first step in overcoming these problems is to carefully align potential projects with the parent organization’s goals. While many companies are motivated to align projects with organizational goals for these benefits, an additional reason for companies that sell to the government is that the Federal CIO Roadmap “ensures IT projects align to agency mission and business need.”10 This was introduced in the Sarbanes-Oxley requirements. All publicly traded companies must now follow certain guidelines that require some sort of financial decision model to be made in deciding to do a project.

When managers assess the organization’s ability to perform projects and then iden- tify, select, prioritize, resource, and govern a portfolio of projects and other work that they believe will help the organization achieve its strategic goals, they are performing portfolio management. While the majority of the portfolio management activities may be conducted by a team of senior executives, project managers should understand how

EXHIBIT 2.5 PORTFOLIO, PROGRAM, PROJECT, AND SUBPROJECT RELATIONSHIPS

Company Portfolio

Program Alpha Program Beta

Project A1

Project A2

Project 3

Subproject 3.1

Subproject 3.2

Chapter 2 Project Selection and Prioritization 33

their specific projects are aligned with the organization’s objectives since they will need to either make or provide input on many decisions.

When companies consider their entire portfolio of work, they sometimes envision projects as means of developing knowledge that can be capitalized upon in ongoing work processes to provide profit, as shown in Exhibit 2.6.

In times when the economy is poor, many companies straggle to get enough business. In such an environment, some firms might accept almost any work they can get. Even during bleak economic times, however, one should be careful how internal projects are selected, since selecting one project limits resources (money, people, etc.) available to other projects. During good or bad economic times, people should take the same care with external projects—ensure that they are consistent with the organization’s goals.

2-2d Assessing an Organization’s Ability to Perform Projects Assessing an organization’s strengths and weaknesses is an essential part of aligning projects with the organization; if an organization does not have the right capabilities, a project that may otherwise support organizational goals may be too difficult to successfully complete. Some questions to ask regarding a firm’s ability to support projects are as follows:

• Do we have a teamwork attitude, free and open communication, creativity, and empowered decision making?

• Do we have a clearly defined project management process? • Do our associates have the right attitudes, skills, and competencies to use the project

management process? • Are our leaders at each level willing to take appropriate personal risk? • Does senior leadership establish a strong leadership foundation? • Do individuals and teams exhibit leadership at their respective levels? • Do we monitor and understand our external environment?

EXHIBIT 2.6 PORTFOLIO OF PROJECTS AND OPERATIONAL WORK PROCESSES

Kn to $SKn to $SLittle Kn Reliable Kn Knowledge ContinuumKnowledge Continuum

Examples: Basic R&D; Customer Research; M&A Due Diligence

Examples: Competitive Strategy; Product Development; Market Entry; Channel Strategy

In cr

em en

ta l P

ro ce

ss Im

pr ov

em en

ts

Option Execution Projects

Radical Process

Improvements

Implementation Projects

Knowledge Building Projects

Options Development

Projects Inbound Logistics

Operations

Outbound Logistics

Sales and Marketing

Customer Service

Manufacturing

Procurement

Human Resources

Processes

Projects PortfolioNew Kn

Current Kn

Both projects and processes are intertwined to create sustainable value.

Source: Chinta, Ravi and Timothy J. Kloppenborg, Projects and Processes for Sustainable Organizational Growth, SAM Advanced Management Journal 75 (3) (Spring 2010), p. 24.

34 Part 1 Organizing Projects

2-2e Identifying Potential Projects The second part of aligning projects with the firm’s goals is to identify potential projects. These potential projects can be in response to a market demand, strategic opportunity, social need, environmental consideration, customer request, legal requirement, or tech- nological advance.11 Ideally, this is accomplished in a systematic manner—not just by chance. Some opportunities will present themselves to the organization. Other good opportunities will need to be discovered. All parts of the organization should be involved. This means people at all levels, from front-line workers to senior executives, and people from all functional areas need to help identify potential projects. For example, sales- people can uncover many opportunities by maintaining open discussions with existing and potential customers, and operations staff may identify potential productivity-enhancing pro- jects. Everyone in the firm should be aware of industry trends. Many industries have trade journals such as Elevator World or Aviation Week and Space Technology that can be read regularly for potential project ideas. One reasonable goal is to identify approximately twice as many potential projects as the organization has time and resources to perform. Under close examination, some potential projects may not be a good fit. Any company that accepts practically every potential project will probably waste some of its resources on pro- jects that do not support its organizational goals.

Once potential projects are identified, the next step is to develop a brief description of each. The leadership team that will select and prioritize projects needs to understand the nature of the projects they are considering. While the level of documentation different firms require varies greatly, a bare minimum can be called the elevator pitch. This is when a person meets another waiting for an elevator and asks, “I hear you are on XYZ Project. What is it all about?” The responder may have only a brief time to give a reply before the elevator arrives and must be prepared to answer quickly with simple state- ments about the project work and why it is important to the organization. The work is often summarized in a brief statement of work, which is a “narrative description of pro- ducts, services, or results to be provided by the project.”12 Why the project is important is often summarized as a business case, which “describes the necessary information from a business standpoint to determine if the project is worth the required investment.”13

The business case generally includes both why the project is needed and, if the firm uses financial justification as part of project selection, an estimate of costs and benefits. Armed with this elevator pitch, the series of processes that collectively are used to select, prioritize, and initiate projects begins as shown in Exhibit 2.7. The rectangles represent

EXHIBIT 2.7 PROJECT SELECTION, PRIORITIZATION, AND INITIATION

Elevator Pitch

Select & Prioritize Projects (Ch. 2)

Develop Project Charter (Ch. 4)

Identify Stakeholders (Ch. 5)

Plan Stakeholder Management & Communications Management (Ch. 5)

Draft Scope Overview & Business Case, Project Priority

Signed Project Charter

Stakeholder Register Stakeholders

Management Plan & Communication Management Plan

Chapter 2 Project Selection and Prioritization 35

work processes, and the documents represent inputs into and deliverables out of the work processes. Some of this work will be described in Chapters 4 and 5.

2-2f Methods for Selecting Projects The people in charge of selecting projects need to ensure overall organizational priorities are understood, agreed upon, and communicated. Once this common understanding is in place, it is much easier to prioritize potential projects. The degree of formality used in selecting projects varies widely. In a small company, it can be straightforward. The prioritization should include asking questions such as these:

• What value does each potential project bring to the organization? • Are the demands of performing each project understood? • Are the resources needed to perform the project available? • Is there enthusiastic support both from external customers and from one or more

internal champions? • Which projects will best help the organization achieve its goals?

There are several different methods of systematically selecting projects. The methods include both financial and scoring models. The primary reason for including financial analysis—either to make the project selection decisions directly or to at least assist in the decision making—is that, from management’s perspective, projects are investments. Therefore, proper selection should yield a portfolio of projects that collectively contribute to organizational success.

Three different approaches are commonly used to ensure both financial and non- financial factors are considered when selecting projects. First, some organizations use financial analysis as the primary means of determining which projects are selected, and management merely tempers this with informal inclusion of nonfinancial factors. Second, some organizations use financial models as screening devices to qualify pro- jects or even just to offer perspective; qualified projects then go through a selection process using a scoring model. Third, at still other organizations, financial justifica- tion is one factor used in a multifactor scoring model. The common thread in all three of these approaches is that both financial and nonfinancial factors are considered when selecting projects. Let us consider both financial and scoring models. Financial models will be covered in concept, but the calculations will not be shown since they are explained in depth in most required finance courses. Scoring models will be covered in both concept and calculation since many students might not have them in another course.

2-2g Using a Cost-Benefit Analysis Model to Select Projects Cost-benefit analysis is “a financial analysis tool used to determine the benefits provided by a project against its costs.”14 These models compare expected project costs to expected project benefits. Several models can be used in making project selection decisions.

NET PRESENT VALUE (NPV) Net present value (NPV) is the most widely accepted model and will be covered first. When using net present value, the analyst first discounts the expected future value of both the project costs and benefits, recognizing that a dollar in the future is worth less than a dollar today. Then the analyst subtracts the stream of discounted project costs from the stream of discounted project benefits. The result is the net present value of the potential project. If the net present value is positive, then the organization can expect to make money from the project. Higher net present values pre- dict higher profits. See the summary in Exhibit 2.8.

36 Part 1 Organizing Projects

BENEFIT-COST RATIO (BCR) A second financial model sometimes used is benefit-cost ratio (BCR). The ratio is obtained by dividing the cash flow by the initial cash outlay. A ratio above 1.0 means the project expects to make a profit, and a higher ratio than 1.0 is better.

INTERNAL RATE OF RETURN (IRR) The third financial model is internal rate of return (IRR). In this model, the analyst calculates the percentage return expected on the project investment. A ratio above the current cost of capital is considered positive, and a higher expected return is more favorable.

PAYBACK PERIOD (PP) The fourth financial model that is sometimes used is the pay- back period (PP). In this analysis, a person calculates how many years would be required to pay back the initial project investment. The organization would normally have a stated period that projects should be paid back within, and shorter payback periods are more desirable.

ADVANTAGES AND DISADVANTAGES OF EACH METHOD Financial models are useful in ensuring that selected projects make sense from a cost and return perspective. Several models have weaknesses that need to be understood before they are used. For example, payback period models do not consider the amount of profit that may be gen- erated after the costs are paid. Thus, two projects with a similar payback period could look equal, but if one has substantially higher revenue after the payback period, it would clearly be superior. BCR would not be acceptable unless all costs and benefits were cal- culated in present dollars (in which case it is similar to NPV except it is a ratio of ben- efits to cost instead of the difference between revenue and cost). IRR and BCRs have problems if used for choosing between mutually exclusive projects because they can favor smaller projects that create less total value for the firm but have high percentage returns. For example, a huge project with a medium rate of return would create a lot of value for a firm but might not be picked over a smaller project with a higher return if only one can be chosen. Additionally, it is sometimes quite difficult to calculate an IRR if a project has nonconventional cash flows. For the most part, the finance field recommends using net present value. The other measures can be calculated to provide perspective on whether a project passes a minimum financial return threshold or to communicate with people who might not understand NPV.

EXHIBIT 2.8 FINANCIAL MODELS FOR PROJECT SELECTION

NET PRESENT VALUE (NPV)

BENEFIT-COST RATIO (BCR)

INTERNAL RATE OF RETURN (IRR)

PAYBACK PERIOD (PP)

Calculation PV revenue – PV cost Cash flow/Project investment

Percentage return on project investment

Project costs/Annual cash flows

Neutral Result NPV = $0 Ratio = 1.0 IRR = Cost of capital Payback period = Accepted length

If used to screen pro- jects or to select pro- jects outright

NPV > Acceptable amount

Ratio > Acceptable amount

IRR > Acceptable amount Payback period < Acceptable length

If used to compare projects

Higher NPV better Higher ratio better Higher IRR better Shorter payback period better

Chapter 2 Project Selection and Prioritization 37

However, none of the financial models ensure alignment with an organization’s strategic goals. Therefore, financial analysis, while very useful, is normally not enough.

2-2h Using a Scoring Model to Select Projects In addition to ensuring that selected projects make sense financially, other criteria often need to be considered. A tool called a scoring model helps to select and prioritize potential pro- jects. It is useful whenever there are multiple projects and several criteria to be considered.

IDENTIFYING POTENTIAL CRITERIA These criteria should include how well each potential project fits with the organization’s strategic planning. The criteria may also include such items as risk, timing, resources needed, and so on. A normal practice is for the company’s leadership team to jointly determine what criteria will be used to select projects. A list of questions executives may use to develop their list of criteria is shown in Exhibit 2.9.

DETERMINING MANDATORY CRITERIA Once the leadership team agrees on a list of criteria that are important, the next step is to determine whether any of the criteria are mandatory. That is, are there any situations that dictate a project must be chosen regard- less of any other considerations? Examples of this include government mandates and clear safety or security situations. This list of “must do” projects should be kept as small as possible since these projects automatically get selected and can crowd out other worthwhile projects.

WEIGHTING CRITERIA Next, the leadership team determines the relative importance or weight of each decision criteria. While more complex methods of determining criteria weights and project evaluations have been used in the past, many firms now use the sim- ple methods described here for determining criteria weights. See Exhibit 2.10 for an example of project evaluations. First, executives determine which criterion is most important and give that a weight of 10. Then they ask how important in comparison each of the other criteria is. For example, if the executives in a consumer products com- pany thought development of new products was most important, it would be assigned a weight of 10. If the customer relations factor was deemed almost as important as new product development, maybe it would be assigned 8. If the factors of supplier relations and probability of project success were each deemed to be half as important as new product development, each would be assigned 5. Perhaps other criteria such as cost

EXHIBIT 2.9 EXAMPLES OF PROJECT SELECTION CRITERIA

• How well does this project fit with at least one organizational objective? • How many customers are there for the expected results? • How competitively can the company price the project results? • What unique advantages will this project provide? • Does the company have the resources needed? • What is the probability of success? • Are the data needed to perform the project available or easily collected? • Do the key stakeholders agree that the project is needed? • What is the expected return on investment? • How sustainable will the project results be? • How does this project promote (or hinder) our corporate social responsibility? • What risks are there if we do not perform this project?

38 Part 1 Organizing Projects

reduction, safely, and so forth were also considered but determined to not be as impor- tant. The resulting criteria with weights are shown in Exhibit 2.10 in the top row of the selection and prioritization matrix. Most organizations will decide to use about three to five criteria. Lesser-rated criteria can be used as tie breakers if needed.

EVALUATING PROJECTS BASED ON CRITERIA Now the leadership team evaluates each project on each criterion. The most efficient and accurate method is to concentrate on one criterion at a time, going down each column in turn. An easy method for this is to rate each project on that particular criterion with scores ranging from 1 (potential project has very little or even negative impact on this criterion) to 5 (project has excel- lent impact on this criterion). The upper left portion of each cell in the matrix can dis- play the rating, representing how well that project satisfies that criterion.

Once a project has been rated on a particular criterion, that rating should be multi- plied by the weight assigned to that criterion and displayed as the weighted score in the main body of each cell. The total for each project should be added across the row. The highest-scoring projects would ordinarily be selected. If several projects have close scores (virtual ties), other criteria or discussion can be used to break the tie. For example, in Exhibit 2.11, there is a virtual tie between Projects A and B.

SENSITIVITY ANALYSES Scoring models allow leadership teams to perform sensitivity analyses—that is, to examine what would happen to the decision if factors affecting it were to change. Selection criteria may be added or altered. Participants may decide that some criteria are more important than others and weight them accordingly. Missing cri- teria or new alternatives can be added and the decision revisited. For example, if the executive team evaluating the projects in Exhibit 2.11 had a bad experience with an unsuccessful project and decided to reevaluate their decisions with success probability now weighted a 9 for very important, the new project selection and priority matrix would be calculated as shown in Exhibit 2.12.

Decision makers can ensure that they use very solid ratings for each potential project. For example, if one criterion was the number of customers, the marketing department could interview some potential customers to gauge their level of interest.

A company might want to select several projects. If so, the scores from the selection matrix could serve as one method of prioritizing the projects.

EXHIBIT 2.10 PROJECT SELECTION AND PRIORITIZATION MATRIX

Project A

Project B

Project C

Project D

Weighted Total Score

New Products

Customer Relations

Supplier RelationsProject\Criteria

& Weight

Success Probability

55810

Chapter 2 Project Selection and Prioritization 39

2-2i Prioritizing Projects Once all projects have been selected, they will need to be prioritized—that is, the deci- sion makers will need to determine which ones will get assigned resources and be sched- uled to begin first. If a company selects a number of projects for a year (or even for a fiscal quarter), it cannot expect to start all of them at the same time. The scoring models are useful in providing input into the starting order of projects. Most leadership teams will consider the weighted scores of each project as a starting point in assigning resources to projects and determining their start dates. The leadership team members, however, also generally discuss other issues such as:

• The urgency of each project • The cost of delaying the expected benefits from various projects • Practical details concerning the timing

EXHIBIT 2.12 REVISED PROJECT SELECTION AND PRIORITIZATION MATRIX

Project A

Project B

Project C

Project D

Total New

Products Customer Relations

Supplier RelationsProject\Criteria

& Weight

Success Probability

95810

45151650

18252450

27154010

1853220

5

5

1

2

2

3

5

4

3

5

3

1

5

2

3

2

126

117

92

75

Source: Chris Bridges.

EXHIBIT 2.11 COMPLETED PROJECT SELECTION AND PRIORITIZATION MATRIX

Project A

Project B

Project C

Project D

Total New

Products Customer Relations

Supplier RelationsProject\Criteria

& Weight

Success Probability

55810

10252450

25151650

15154010

1053220

5

5

1

2

3

2

5

4

5

3

3

1

2

5

3

2

109

106

80

67

40 Part 1 Organizing Projects

For example, an important process improvement project may be far less disruptive to perform when the factory is shut down for routine maintenance. One more discussion frequently occurs in the prioritizing process—if there is a conflict between resource needs for two projects, which one gets the needed resources first? Often, this is left to the proj- ect sponsors to iron out; for especially important projects, it may be formally decided by the leadership team. In that way, the probability of the critical project being held up by a misunderstanding is greatly decreased.

Exhibit 2.13 shows how the Alternative Breaks (AB) planning committee at a univer- sity ranked spring break projects. This exhibit shows four of the twenty-six projects that were selected for trips. This book will include multiple examples of the AB project to illustrate how various project planning tools work together. Each trip is a small project while the combination of all twenty-six trips form the overall project.

2-2j Resourcing Projects Once all projects have been prioritized, it is time to assign resources to each. Resources can include key personnel such as sponsors, project managers, core teammembers, and subject mat- ter experts. It can also include money, space, and equipment that may be in short supply. The easiest way is to use a resource assignment matrix and begin by assigning resources to the high- est priority projects. Once an individual resource is no longer available, the organization is limited in the number of projects that it can take on during a particular time. Assigning resources like this requires a prioritized project list such as shown in Exhibit 2.12, a list of resources and how much of each is available, and an estimate of how much of each key resource each project will need. For simplicity’s sake, companies often plan for a fiscal quarter. Exhibit 2.14 shows the same four projects and choices of project managers, team members, and money for each. Note, while there is enough project manager time to start all four projects, there is not enough teammember time nor enough cash. Therefore, only three projects can be started.

2-3 Securing Projects The discussion above pertains to projects that are internal to an organization. This sec- tion deals with projects a company (called the client) wants performed, but for which it may hire external resources (called contractors) to execute significant parts or all of the work. External projects can be viewed either from the perspective of the client company that wants the project to be executed or from the perspective of the contractor company that wants to perform the work. Client companies may first put prospective external

EXHIBIT 2.13 ALTERNATIVE BREAKS PROJECT SELECTION AND PRIORITIZATION MATRIX

PROJECT/SELECTION CRITERIA

ACTIVE SERVICE OPPORTUNITY ISSUE ITSELF

ORGANIZATION TO WORK WITH COST

9 10 6 5 Total

New York Vegan Farm 5 45

4 40

3 18

4 20

123

West Virginia Sustainability 4 36

3 30

4 24

5 25

115

Chicago Halfway House 2 18

4 40

4 24

4 20

102

El Salvador Cultural Immersion 1 9

5 50

5 30

1 5

94

Chapter 2 Project Selection and Prioritization 41

projects through a selection and prioritization process as described above and, if selected, then decide whether to perform the work internally (make) or hire the project to be per- formed by others (buy). If the decision is to buy, then the client company needs to plan and conduct the procurement.

Contractor companies need to identify potential project opportunities, determine which they will pursue, submit proposals, and be prepared to either bid or negotiate to secure the work. We consider the client company’s perspective in Chapter 12, Project Supply Chain Management. We consider the contractor’s perspective next.

2-3a Identify Potential Project Opportunities Contractors seeking external projects to perform should pursue this in a fashion similar to that of any company considering internal projects, as described earlier in this chapter in the portfolio alignment section on identifying potential projects. Additionally, since they need to look externally, contractor companies should have representatives at trade shows, professional conferences, and anywhere information on the intentions of poten- tial customers and competitors may surface. Contractor companies should also actively practice customer relationship management by establishing and nurturing personal con- tacts at various levels and functions. Contractor companies can also practice customer relationship management by linking information systems to the extent practical so as to identify any useful information concerning potential future projects and improve man- agement of current projects.

2-3b Determine Which Opportunities to Pursue Just as all companies should decide which internal projects to select, as previously described in the methods for selecting projects, most contractor companies are best served by targeting the projects they wish to pursue. Some companies have a policy that they will bid on every potential project, knowing that if they do not bid, they will not be awarded the project. More companies find that if they target their opportunities, their “hit rate” or probability of securing the work on any given proposal increases. It

EXHIBIT 2.14 RESOURCE ASSIGNMENT MATRIX

PROJECT/ RESOURCE PM/ DEJI PM/ BUD

PM/ CORY

TEAM/ BRADLEY

TEAM/ RAJEEV

TEAM/ LARRY MONEY

Maximum Availability 200 400 300 300 150 150 $30 million

Project List

Project B: PM 240, Team 200, $5M

240 200 $5M

Project A: PM 200, Team 150, $10M

200 150 $10M

Project C: PM 300, Team 150, $14M

300 150 $14M

Project D: PM 150, Team 180, $4M

Remaining Availability 0 160 0 100 0 0 $1M

42 Part 1 Organizing Projects

takes time and resources to put together a good proposal, so it makes sense to increase the acceptance rate by developing a bid/no-bid decision strategy.

Each company has strengths and weaknesses compared to its competitors. Hence, a quick SWOT analysis could be used to decide whether to pursue a potential project, just as a more involved version of SWOT analysis was described earlier and depicted in Exhibit 2.2. Decision makers can also ask how well a potential project will help achieve their objectives. If they determine a project will help achieve their objectives, the next considerations are the cost to pursue the work and the probability of successfully secur- ing the project given the likely competition. A company frequently considers risks both of pursuing and not pursuing a potential project. Finally, does the company have the capability to perform the work if it is awarded?

2-3c Prepare and Submit a Project Proposal When a firm prepares to submit a proposal, it is really conducting a small project with the primary deliverable of the project being a compelling and complete proposal. The contractor should understand the project’s source selection criteria, the “set of attributes desired by the buyer which a seller is required to meet or exceed to be selected for a contract.”14 While criteria will vary extensively from one project to another, generally a client will likely want to be convinced that the potential contractor is technically, managerially, financially, and operationally competent. Successful project managers try hard to convince potential clients that they are capable on all four dimensions. A short list of these factors is shown in Exhibit 2.15.

Many companies find that targeting their opportunities is a better use of their time and resources than bidding on every potential project.

EXHIBIT 2.15 TYPICAL SOURCE SELECTION CRITERIA

TECHNICAL MANAGEMENT FINANCIAL OPERATIONAL

Technical experience Management experience Financial capacity Production capacity

Needs understanding Project charter Life cycle cost Business size and type

Technical approach Planning and scheduling Cost basis and assumptions Past performance

Risk mitigation Project control Warranties References

© vg st ud io /S hu tte rs to ck .c om

Chapter 2 Project Selection and Prioritization 43

2-3d Negotiate to Secure the Project Once all proposals have been delivered and evaluated, the client company may elect to either award the project or enter into negotiations with one or more potential contrac- tors. On more routine projects, the contract may be awarded at this point. Further clar- ifications and negotiations may follow for complex projects.

A client company and a contractor company may negotiate the amount of money to be paid for a project. They may also negotiate the contractual terms, schedule, specific personnel to be assigned to work on the contract, quality standards, reporting mechan- isms, and various other items. A project manager may need to make arrangements with potential suppliers to secure the products and services needed to perform the project. All of these considerations will be covered in subsequent chapters.

Successful project managers understand that they need to prepare well for negotia- tions. This starts with a clear understanding of what is most important to their manage- ment. Often, it includes fact-finding with the client company to understand its needs and abilities. Armed with understanding of both perspectives, a project manager attempts to find a solution that allows the organization to secure the project work with enough profit potential and with the start of a good working relationship with the client. In the end, the client company will select the contractor(s) and award the contract(s).

Summary Project selection does not occur in isolation. Ideally, it begins with the organization’s strategic planning. This planning begins with a strategic analysis of the organiza- tion’s internal strengths and weaknesses as well as the external threats and opportunities it faces. The organiza- tion should then develop its guiding principles such as mission and vision statements. Most companies will have an annual planning session in which strategic objec- tives are developed. Larger organizations will continue this effort with one or more levels of planning in which the overall objectives are flowed down to determine objectives that are appropriate for each organizational level.

Once the strategic planning is accomplished, the organization’s leadership team engages in portfolio management. The first part is an open and honest assessment of the organization’s ability to perform pro- jects. The decision makers need to understand how many resources are available, the organization’s overall capabilities, and the capabilities of the individuals who will be assigned to projects. An ongoing portfolio man- agement activity is for everyone in the firm to identify possible opportunities that they feel might help the organization achieve its goals. Each potential project should be described at least by stating in a sentence or two what work is involved and how it would help the organization achieve one or more of its goals.

Once potential projects are identified and briefly described with statements of work and business cases, they should be put through a process to determine which will be selected and what their relative priori- ties are. Both financial and scoring models are fre- quently used to evaluate potential projects. Net present value is the preferred financial method, although others are sometimes used. Financial analy- sis tells the leadership team how much each potential project is worth from a benefits-versus-cost compari- son, but does not tell how each potential project may help to achieve the organization’s goals. Scoring mod- els can incorporate various goals and should also be used. Once a project list is selected, the projects need to be prioritized so some can start right away and others can start later.

Contractor companies need to be constantly on the lookout for potential project opportunities. Once potential projects are identified, companies need to decide which ones they pursue. Just as for internal projects, some external projects will be bet- ter at helping an organization reach its goals because they are a better fit. The contractor needs to prepare and submit proposals for desired projects and be prepared to follow up and often negotiate in order to secure them.

44 Part 1 Organizing Projects

Key Terms from the PMBOK® Guide portfolio management, 31 portfolio, 32 program, 32 subproject, 33

statement of work, 35 business case, 35 source selection criteria, 43

Chapter Review Questions 1. List and describe each step in the strategic plan-

ning process. 2. Name at least four things that a mission state-

ment should include. 3. What does the strategic analysis acronym SWOT

stand for? 4. What is the most widely accepted financial model

for selecting projects? 5. What are some advantages and disadvantages

of using a financial model for selecting projects?

6. What are some advantages and disadvantages of using a scoring model for selecting projects?

7. What are some common reasons for project failure?

8. Who should be involved in the second part of aligning projects with the firm’s goals, which is identifying potential projects?

9. If there is a conflict between resource needs for two projects, who decides which one gets the needed resources first?

10. In a project scoring model, why is each decision criteria given a weight?

11. What purpose do sensitivity analyses serve in using scoring models to choose projects?

12. If several projects have close scores as the result of a scoring model, what can be done to break the virtual tie?

13. Why might a contractor company perform a SWOT analysis prior to bidding on a potential project?

14. Why is it important for a contractor to under- stand the source selection criteria a client uses to decide to whom they will award a project?

15. Name five things that may be negotiated between a client company and a contractor company. 1.

Discussion Questions 1. How might the internal and external parts of a

SWOT analysis affect one another? 2. Describe the interaction between vision and

mission statements. 3. How is a company’s portfolio similar to and

different from a financial portfolio? 4. What is the best way for an organization to

prioritize among selected projects? Does it vary among organizations?

5. Describe three different ways decision makers might select projects while considering both financial and nonfinancial factors.

6. Why is aligning potential projects with the parent organization’s goals the first step in avoiding project failure?

7. Why is it a good practice for organizations to identify twice as many potential projects as they plan to implement?

8. Suppose you are purchasing a new car, and you decide to use a scoring model to decide among four options. What would be your top three cri- teria, and what would be each criterion’s relative weight?

9. Under what circumstances should a selected project take precedence over other selected projects?

10. If you are a contractor looking for project work, why might you decide not to pursue a particular project opportunity?

11. What are the four main areas of competency a client company is looking for in a project manager? How can you best demonstrate these competencies to a potential client?

Chapter 2 Project Selection and Prioritization 45

PMBOK® Guide Questions 1. A collection of projects, programs, and opera-

tions managed as a group to achieve strategic objectives is called a: a. process b. portfolio c. subprogram d. life cycle

2. Projects may be undertaken as a result of any of the following strategic reasons except: a. social need b. market demand c. executive discretion d. environmental considerations

3. A narrative description of products, services, or results to be delivered by the project is a: a. request for information b. business case c. project statement of work d. elevator pitch

4. Program management helps determine the optimal approach for managing interdependent projects in order to achieve benefits and control. Program management activities might include all of the following except: a. aligning organizational and strategic direction b. managing shared client relationships c. resolving issues and change management d. resolving resource constraints

5. A project statement of work (SOW) would use or include information from each of the following sources except: a. project charter b. strategic plan c. business need d. product scope description

6. All projects should be aligned with their organization’s strategic plan, which includes the organization’s vision, goals, and objectives. Which of these is the definition of a vision statement? a. Conveys a larger sense of organizational pur-

pose, and is both inspiring and guiding.

b. Describes short- and long-term results along with measures to determine if they have been achieved.

c. Includes the organization’s core purpose, core values, beliefs, culture, primary business, and primary customers.

d. Is SMART: specific, measurable, achievable, results-based, and time-specific.

7. Which group within the organization is respon- sible for integrating data and information from corporate strategic projects, and using corporate measurement systems to evaluate how strategic objectives are being fulfilled? a. Chief Information Officer b. Project Management Office c. Project Sponsors d. Operations Management

8. The document that includes the necessary infor- mation to determine whether a project is worth the required investment, and is used for decision making by upper management, is called the: a. project scope statement b. project charter c. business case d. case study

9. The author notes that contractors seeking external customers should also use a project selection/ portfolio alignment process. Once an external customer and contractor have reached a consen- sus on the initial intentions for the contracted work, their understanding is documented in: a. a statement of work (SOW) b. a business case c. an agreement d. a strategic alliance

10. A business case typically contains information regarding the business need and a financial analysis. Which financial model divides the cash flow by the initial cash outlay? a. Benefit-cost ratio (BCR) b. Internal rate of return (IRR) c. Net present value (NPV) d. Payback period (PP)

Exercises 1. Complete the following scoring model. Show all

your work. Tell which project you would pick first, second, third, and last. How confident are

you with each choice? If you lack confidence regarding any of your choices, what would you prefer to do about it?

46 Part 1 Organizing Projects

2. Complete the following scoring model. Show all your work. Tell which project you would pick first, second, third, and last. How confident are you with each choice? If you lack confidence regarding any of your choices, what would you prefer to do about it?

3. Pretend you are on the leadership team for a pharmaceutical company that is in a difficult financial situation due to patents that have died

on two of your most profitable drugs. Brainstorm a list of criteria by which you would select and prioritize projects. Weight the criteria.

4. Pretend you are on the leadership team of a manufacturing company that is currently chal- lenged by low-cost competition. Brainstorm a list of criteria by which you would select and prior- itize projects. Weight the criteria.

Example Project Instructions Your instructor will probably bring example projects to class and facilitate the assignment of students to the various project teams. Therefore, you will proba- bly not be involved in the project selection. However, one of the first things you should do when assigned to a project is to learn about the company or other organization that wants the project to be completed. Why did they select this project? Is it a “must do”

project or did it get picked over other competing projects? By understanding what makes the project so important, you will make better decisions and will be more motivated through the term. If your project is a “must do” project, explain why. If it is not a “must do” project, explain how it was selected. Explain where it fits in priority with other work of the organization.

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Barclay, Colane, and Kweku-Muata Osei-Bryson, “Toward a More Practical Approach to Evaluating Programs: The Multi-Objective Realization Approach,” Project Management Journal 40 (4) (December 2009): 74–93.

Brache, Alan P., and Sam Bodley-Scott, “Which Imperatives Should You Implement?” Harvard Man- agement Update, Article reprint no. U0904B (2009).

Cannella, Cara, “Sustainability: A Green Formula,” 2008 Leadership in Project Management 4: 34–40.

Caron, Franco, Mauro Fumagalli, and Alvaro Riga- monti, “Engineering and Contracting Projects: A Value at Risk Based Approach to Portfolio Balanc- ing,” International Journal of Project Management 25 (2007): 569–578.

Chinta, Ravi, and Timothy J. Kloppenborg, “Projects and Processes for Sustainable Organizational Growth,” SAM Advanced Management Journal 75 (2) (Spring 2010): 22–28.

Project A

Project B

Project C

Project D

Weighted Total Score

Criteria 1 Criteria 2 Criteria 3 Project\

Criteria & Weight 4610

4

3

2

1

3

2

4

3

5

3

3

4

Project A

Project B

Project C

Project D

Weighted Total Score

Criteria 1 Criteria 2 Criteria 3 Project\

Criteria & Weight 3710

1

3

5

2

3

5

4

3

4

3

3

1

Chapter 2 Project Selection and Prioritization 47

Cooper, Robert G., “Winning at New Products: Path- ways to Profitable Innovation,” Proceedings of PMl Research Conference 2006 (Newtown Square, PA: Project Management Institute, 2006).

Daft, Richard L., Management, 9th ed. (Mason, OH: South-Western Cengage Learning, 2010).

Eager, Amanda, “Designing a Best-in-Class Innovation Scoreboard,” Technology Management (January– February 2010): 11–13.

Evans, R. James and William M. Lindsay, Managing for Quality and Performance Excellence, 8th ed. (Mason, OH: South-Western Cengage Learning, 2011).

Kenny, John, “Effective Project Management for Stra- tegic Innovation and Change in an Organizational Context,” Project Management Journal 34 (1) (March 2003): 43–53.

Kloppenborg, Timothy J., Arthur Shriberg, and Jayashree Venkatraman, Project Leadership (Vienna, VA: Management Concepts, 2003).

Kloppenborg, Timothy J., and Laurence J. Laning, Strategic Leadership of Portfolio and Project Management (New York: Business Expert Press, 2012).

Labuschagne, Les, and Carl Marnewick, “A Structured Approach to Derive Projects from the Organiza- tional Vision,” Proceedings of PMI Research Conference 2006 (Newtown Square, PA: Project Management Institute, 2006).

Milosevic, Dragan Z., and Sabin Srivinnaboon, “A Theoretical Framework for Aligning Project Management with Business Strategy,” Project Management Journal 37 (3) (August 2006): 98–110.

Organizational Project Management Maturity Model Knowledge Foundation, 2nd ed. (Newtown Square, PA: Project Management Institute, 2008).

Reginato, Justin, and C. William Ibbs, “Employing Business Models for Making Project Go/No Go Decisions,” Proceedings of PMI Research Conference 2006 (Newtown Square, PA: Project Management Institute, 2006).

Senge, Peter, Bryan Smith, Nina Kruschwitz, Joe Laur, and Sara Schley, The Necessary Revolution: How Individuals and Organizations Are Working Together to Create a Sustainable World (New York: Broadway Books, 2008).

Smallwood, Deb, and Karen Furtado, “Strategy Meets the Right Projects at the Right Time,” Bank Systems & Technolgy 46 (4) (June–July 2009): 34.

The Standard for Portfolio Management, 2nd ed. (Newtown Square, PA: Project Management Institute, 2008).

Wheatley, Malcolm, “Beyond the Numbers” PMNet- work 23 (8) (August 2009): 38–43.

Zhang, Weiyong, Arthur V. Hill, Roger G. Schroeder, and Keyin W. Linderman, “Project Management Infrastructure: The Key to Operational Performance Improvement,” Operations Management Research 1 (1) (September 2008): 40–52.

http://en.wikipedia.org/wiki/Triple_bottom_line, accessed February 2, 2010.

http://www.gcbl.org/about, accessed March 12, 2013. http://www.bia.ca/vision.htm, accessed March 5, 2013. http://ocio.os.doc.gov/s/groups/public/@doc/@os/

@ocio/@oitpp/documents/content/prod01_00208 2.pdf, accessed March 6, 2013.

Endnotes 1. http://www.bia.ca/vision.htm, accessed March 5,

2013. 2. http://www.gcbl.org/about, accessed March 12,

2013. 3. Lussier, Robert N., and Christopher F. Achua, Lead-

ership: Theory, Application, Skill Development, 4th ed. (Mason, OH: Thomson South-Western, 2010): 425.

4. Ibid., 426. 5. PMBOK® Guide 7. 6. Kloppenborg, Timothy J., and Laurence J. Laning,

Strategic Leadership of Portfolio and Project Manage- ment (New York: Business Expert Press, 2012): 21.

7. PMBOK® Guide 551. 8. PMBOK® Guide 553. 9. PMBOK® Guide 564.

10. http://ocio.os.doc.gov/s/groups/public/@doc/@os/ @ocio/@oitpp/documents/content/ prod01_002082.pdf, accessed May 22, 2013.

11. PMBOK® Guide105. 12. PMBOK® Guide 68. 13. PMBOK® Guide 69. 14. PMBOK® Guide 535. 15. PMBOK® Guide 563.

48 Part 1 Organizing Projects

PROJECT MANAGEMENT I N ACT I ON

Prioritizing Projects at D. D. Williamson

One of the most difficult, yet most important, lessons we have learned at D. D. Williamson surrounds project prioritization. We took three years and two iterations of our prioritization process to finally settle on an approach that dramatically increased our success rate on critical projects (now called VIPs, or “Vision Impact Projects”).

Knowing that one of the keys to project management success is key management support, our first approach at prioritization was a process where our entire senior management team worked through a set of criteria and resource estimations to select a maximum of two projects per senior management sponsor—16 projects in total. Additionally, we hired a continuous improvement manager to serve as both our project office and a key resource for project facilitation. This was a great move forward (the year before we had been attempting to monitor well over 60 continuous improvement projects of varying importance). Our success rate improved to over 60 percent of projects finishing close to the expected dates, financial investment, and results.

What was the problem? The projects that were not moving forward tended to be the most critical—the heavy-investment “game changing” projects. A review of our results the next year determined we left significant money in opportunity “on the table” with projects that were behind and over budget!

This diagnosis led us to seek an additional process change. While the criteria rating was sound, the number of projects for a company our size was still too many to track robustly at a senior level and have resources to push for completion. Hence, we elevated a subset of projects to highest status—our “VIPs.” We simplified the criteria ratings—rating projects on the level of expected impact on corporate objectives, the cross-functional nature of the team, and the perceived likelihood that the project would encounter barriers which required senior level support to overcome.

The results? Much better success rates on the big projects, such as design and implementation of new equipment and expansion plans into new markets. But why?

The Global Operating Team (GOT) now has laser focus on the five VIPs, reviewing the project plans progress and next steps with our continuous improvement manager in every weekly meeting. If a project is going off plan, we see it quickly and can move to reallocate resources, provide negotiation help, or change priorities within and outside the organization to manage it back on track. Certainly, the unanticipated barriers still occur, but we can put the strength of the entire team toward removing them as soon as they happen.

A couple of fun side benefits—it is now a development opportunity for project managers to take on a VIP. With only four to six projects on the docket, they come with tremendous senior management interaction and focus. Additionally, we have moved our prioritization process into our functional groups, using matrices with criteria and resource estimations to prioritize customer and R&D projects with our sales, marketing, and science and innovation teams, as well as IT projects throughout the company. The prioritization process has become a foundation of our cross-functional success!

Following are excerpts from the spreadsheet D. D. Williamson used to select and prioritize our VIP projects last year. Exhibit 2.16 shows the five criteria used to prioritize the projects. Exhibit 2.17 shows how associate time when assigned to a project is not available for other projects. Note all executives agreed to spend up to 120 hours this quarter on projects and Brian is overallocated—meaning either he will need to do extra work, something needs to be assigned to another person, or one less project can be completed.

Chapter 2 Project Selection and Prioritization 49

EXHIBIT 2.17 ASSOCIATE TIME ASSIGNED TO PROJECTS

TED MARGE ELAINE BRIAN ANN GRAHAM EDIE

Available hours for quarter 120 120 120 120 120 120 120

Project List

Product X expansion 80 120 60

New process equipment 60 40

Environmental scrubbers 60

Powder packaging equipment 60 60

Total hours committed 80 120 60 180 0 60 40

Total hours exceeding available 40 0 60 -60 120 60 80

Source: Elaine Gravatte, Chief People Officer and North American President, D. D. Williamson.

EXHIBIT 2.16 PROJECT SELECTION AND PRIORITIZATION FOR D. D. WILLIAMSON

PROJECT/ SELECTION CRITERIA

ACHIEVE SALES REVENUE 10

ADD NATURAL COLORS 9

RETURN ON CAPITAL 8

REPEATABILITY 6

PROBABILITY OF SUCCESS 5 TOTAL

Implement product X expansion

5

50

5

45

4

32

4

24

4

20

171

Design new process equipment

4

40

1

9

5

40

5

30

5

25

144

Install environmental scrubbers

2

20

2

18

5

40

5

30

5

25

133

Install powder packaging equipment

4

40

1

9

5

40

2

12

2

10

111

50 Part 1 Organizing Projects

CHA P T E R 3 Organizational Capability: Structure, Culture, and Roles

Over the last 15 years, my company (Atos Origin) has been through three significant mergers/acquisitions and has seen good growth. As new lines of businesses and employees have been added, we have become truly a global company, where people from many countries where our businesses operate come together to present the best solution to our clients. An excellent example is the work we do for the Olympics games (Atos Origin has been the worldwide IT partner for the Olympics for several years).

The overall project life cycle for most of the projects in the company follows the typical IT project management approach. What has evolved over time is the use of employees from different regions of the world to service a client need. For instance, we have onsite operations for a client in the United States and in Europe. The development and testing work is done offshore in India. The onsite team members are primarily the program manager, project managers (who deal with the client), business analysts, and technical architects. The offshore team members include designers, developers, and

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Compare and contrast the advantages and disadvantages of the functional, project, strongmatrix, balanced matrix, andweakmatrix methodsoforganization; describe how each operates andwhen to use each.

• Describe organizational culture elements that are helpful in planning andmanaging projects and demonstrate how to overcome organizational culture elements that hinder project success.

• Given a project situation, describe ethical behavior consistent with PMI’sCodeofEthicsand Professional Conduct.

• Describe different project life cyclemodels and distinguishwheneach is appropriate.

• Describe the duties, motivations, and challenges of each of the executive, managerial, and team roles in projects and list important attributes for selecting each.

© Ko ns ta nt in Ch ag in /S hu tte rs to ck .c om

52

Topics:

• Organizational culture

• Organizational structure

• Project stakeholders

• Role of project manager

• Plan human resource management

• Project management office

• Project life cycle

testers. There are also project managers who lead the team in India and interact with their onsite counterpart on a regular basis.

The entire operation is managed through a program management office (PMO) that is responsible for identifying, prioritizing, and ensuring delivery of all the projects. It is a matrix structure where the team members report into the PMO as well as their functional heads in their countries. The PMO has its own culture of hard work, striving toward goals in a step-by-step manner, and promoting team spirit. It fits right into our overall organization culture of getting things done for the client, promoting innovation and conviviality, and never compromising on ethical behavior.

I have observed that adaptability and empathy are helpful strengths for project managers in this environment. Adaptability because the different locations bring with them a set of challenges, including the ability to hold the global team together. Empathy is extremely useful as well. Although the project manager may not agree with the choices made by team members, he or she must respect them.

Recently we had a team member from India absent from work for over two weeks because his father was seriously ill. Typically in the United States that would not be the case. Most people live away from their parents here and are not able to take so much time off for their illness. In India, parents often live with and are cared for by their children. The project manager from the United States understood the Indian culture well enough to know that until the team member’s father was well enough, he would have to arrange for a different resource to perform on the project. Fortunately, because of his traits of adaptability and empathy, he had recognized this up front and was able to achieve his project timeline.

It is important for you, as a student of project management, to understand and appreciate that organizations are different and are continuously evolving. Entities in an organization in different parts of the world are different. Team members have different strengths and weaknesses. Clients have different expectations from a global company. As a project manager, you will need to use your strengths to ensure that all your stakeholders are happy before, during, and after project delivery.

Rachana Sampat (Thariani), Atos Origin

PMBOK® Guide

53

SelectingPhase:

Approval:

To Proceed

CharterSelection Kickoff

Planning Executing Closing Initiating Realizing

Project

Result

Administrative

Closure

Benefits

Realized

3-1 Types of Organizational Structures Contemporary companies choose among various methods for establishing their organi- zational structure. Organizational structure can be considered to include work assign- ments, reporting relationships, and decision-making responsibility. Each method of structuring organizations has strengths and weaknesses. In this section, we will investi- gate various organizational methods and the impact of each on managing projects. The advantages and disadvantages of each organizational form are discussed in the following sections and then summarized in Exhibit 3.5.

3-1a Functional A functional organization is “a hierarchical organization where each employee has one clear superior, staff are grouped by areas of specialization, and managed by a person with expertise in that area.”1 This is the traditional approach when there are clear lines of authority according to type of work. For example, all accountants might report to a head of accounting, all marketers report to a head of marketing, and so on. An organi- zational chart for a functional organization is shown in Exhibit 3.1. Note that everyone in the organization reports up through one and only one supervisor. That supervisor is the head of a discipline or function (such as marketing).

The functional manager generally controls the project budget, makes most project decisions, and is the primary person who coordinates project communications outside of the functional areas by contacting his or her peer functional managers.

ADVANTAGES One advantage of the functional form of organization is called unity of command—all workers understand clearly what they need to do because only one “boss” is giving them instructions. Another advantage is that since all workers in a discipline report to the same supervisor, they can learn readily from each other and keep their technical skills sharp. A third advantage is that workers know that when they finish work on a project they will still have a job because they will continue to report to the same functional manager. For small projects that require most of the work from one

EXHIBIT 3.1 FUNCTIONAL ORGANIZATION

Marketing VP Operations VP Finance VP Services VP

President

54 Part 1 Organizing Projects

department, the functional organization often works well both because of the advantages already stated and because the functional manager can share resources among various small projects and centrally control the work.

DISADVANTAGES However, the functional form of organization can make for slow communications when multiple functions need to have input. It also can be challeng- ing from a technical standpoint if input is required from multiple disciplines. The functional manager is probably quite good within his or her domain, but may have less understanding of other disciplines. In small organizations where most people have been forced to understand multiple areas, this may be less of an issue. Coordi- nation between departments is frequently conducted at the manager level as the functional managers have a great deal of decision-making authority. This often means communication needs to first travel up from worker to manager, then across from one functional manager to another manager, then down from manager to worker. These long communication channels often make for slow decision making and slow response to change. For these reasons, some organizations choose other forms of organization.

3-1b Projectized The exact opposite form of organization is the projectized organization, which is defined as “any organizational structure in which the project manager has full authority to assign priorities, apply resources, and direct work of persons assigned to the project.”2

In this organizational form, the larger organization is broken down into self-contained units that support large projects, geographies, or customers. Most people in the organi- zation are assigned to a project and report upward through the project manager, as can be seen in Exhibit 3.2. While the structure of the two organizational charts appears similar, the reporting manager is a project manager instead of a functional manager. The project manager has extensive authority for budgets, personnel, and other decision making in this organizational structure.

EXHIBIT 3.2 PROJECTIZED ORGANIZATION

Project Manager 1 Project Manager 2 Project Manager 3 Project Manager 4

President

Chapter 3 Organizational Capability: Structure, Culture, and Roles 55

ADVANTAGES The advantages of the projectized organizational form are very different from the advantages of the functional form. Because people from different functions now report to the same project manager, traditional department barriers are reduced. Since the project manager is responsible for communications, response times and decision making tend to be swift. All workers understand clearly what they need to do because only one “boss”—the project manager—is giving them instructions.

Projectized organizational structures often utilize the technique of co-location, which is “an organizational placement strategy where the project team members are physically located close to one another to improve communication, working relationships, and productivity.”3 This co-location often results in enhanced project team identity, strong customer focus, and effective integration of effort on the project.

DISADVANTAGES However, this organizational form also has disadvantages. Team members are often assigned to just one project, even if the project only needs part of their time. This can be costly. Since the project manager is in charge and the team may be physically located onsite rather than with the rest of the organization, some projects tend to develop their own work methods and disregard those of the parent organization. While some of the new methods may be quite useful, project teams not watched closely can fail to practice important organizational norms and sometimes do not pass the lessons they learn on to other project teams. Team members who are co-located, while learning more about the broader project issues, often do not keep up their discipline- specific competence as well. Team members sometimes worry about what they will do when the project is completed.

3-1c Matrix Each of the extreme strategies already described (extreme in the sense that either the functional manager or the project manager has a great deal of authority) has great advantages, yet significant weaknesses. In an attempt to capture many of the advantages of both, and to hopefully not have too many of the weaknesses of either, many organiza- tions use an intermediate organizational strategy in which both the project manager and the functional manager have some authority and share other authority.

This intermediate strategy is the matrix organization, which is “any organizational structure in which the project manager shares responsibility with the functional man- agers for assigning priorities and directing work of persons assigned to the project.”4

A matrix organization is shown in Exhibit 3.3. Note that project team members report to both functional and project managers. This is a clear violation of the unity- of-command principle; however, it is necessary to enjoy the benefits of a matrix organi- zation. In short, the hoped-for benefit of a matrix structure is a combination of the task focus of the projectized organizational structure with the technical capability of the functional structure.

ADVANTAGES Matrix organizations have many advantages, which is why an increas- ing number of companies are using some variation of them today. One advantage is that because both project and functional managers are involved, there is good visibility into who is working where, and resources can be shared between departments and pro- jects. This reduces possible duplication—a major advantage in this age of lean thinking in business. Since both types of managers are involved, cooperation between departments can be quite good. There is more input, so decisions tend to be high quality and are better accepted. This is a major issue since enthusiastic support for controversial decisions often helps a project team work through challenges. Since people still report to their functional manager, they are able to develop and retain discipline-specific

56 Part 1 Organizing Projects

knowledge. Since the various disciplines report to the same project manager, effective integration is still possible. Because people report to both the project manager, who is responsible for capturing lessons learned, and to the functional manager, who is responsible for how the work in a function is performed, lessons learned can be shared effectively between projects.

Yet another advantage of the matrix form is its flexibility. The amount of decision- making authority can be shared equally in whatever manner is desired. When the functional managers have relatively more power, it is almost like a functional organiza- tion. This is how many organizations start evolving—by giving project managers a bit more decision-making authority. This is called a weak matrix since the project managers have less authority than the functional managers. The next step in the progression is a balanced matrix in which project managers and functional managers have about equal power. Finally, a strong matrix is one where the project managers have more power than functional managers. This is more similar to a projectized organizational form. The progression of forms is shown in Exhibit 3.4.

DISADVANTAGES The matrix organizational form has drawbacks as well. Some people claim that having two bosses (both a functional manager and a project manager) is a disadvantage. This problem certainly needs to be managed because the two managers may each try to do what they think is best for their project or department and may give

EXHIBIT 3.3 MATRIX ORGANIZATION

Marketing VP Operations VP Finance VP Services VP

President

Manager of Project Managers

Project Manager 1

Project Manager 2

Project Manager 3

Project Manager 4

EXHIBIT 3.4 PROGRESSION OF ORGANIZATIONAL FORMS

ORGANIZATIONAL FORM FUNCTIONAL WEAK MATRIX

BALANCED MATRIX

STRONG MATRIX PROJECTIZED

Who has power? FM almost all FM more Equally shared PM more PM almost all

Chapter 3 Organizational Capability: Structure, Culture, and Roles 57

conflicting advice. However, this is common territory for most people. Most students take multiple classes per term. Most companies have multiple customers. Having to bal- ance competing demands can be difficult, but it is very normal for most people. Since more people are providing the necessary input, there are more sources of conflict, more meetings, and more challenges to control. Decisions may not get made as fast.

Firms need to consider which organizational structure is best for them in the sense that they can capitalize on its advantages and mitigate its disadvantages. These decisions can change over time. Exhibit 3.5 summarizes a comparison of organizational structures.

Note that in a matrix organization a new role is inserted in the organizational chart—that of manager of project managers. Sometimes this person leads an office called the project management office (PMO). In some organizations, an additional manager will be in the reporting chain between the project managers and the person in charge (shown as the presi- dent). In other matrix organizations, the project managers report directly to the person in charge. For simplicity, this chart shows each function with four workers and each project with four team members. In actuality, some functions may have more workers than others, and some projects may have more team members than others. In fact, some people may only report to a functional manager since they are not currently assigned to a project, and others may report to more than one project manager since they are assigned on a part-time basis to multiple projects. Those people will have more than two supervisors.

While both project managers and functional managers have certain authority in any matrix organization, the extent of this authority can vary substantially. Often, the project manager has authority to determine what work needs to be accomplished and by when. The functional manager often retains authority to determine how the work is

EXHIBIT 3.5 ORGANIZATIONAL STRUCTURE COMPARISON

FUNCTIONAL MATRIX PROJECTIZED

Who makes most project decisions?

Functional manager Shared Project manager

Advantages • Good discipline-specific knowledge

• Easy for central control • Effective for shared resources • One “boss” • Clear career path for professionals

• Flexible • Easy to share resources • Good cooperation between departments

• More input for decisions • Wide acceptance of decisions • Good discipline-specific knowledge

• Effective integration on project • Increased knowledge transfer between projects

• Break down department barriers • Shorter response time • Quicker decisions • One “boss” • Enhanced project team identity • Customer focus • Effective integration on project

Disadvantages • Slow communication between departments

• Slow response to change • Slow decision making

• Two “bosses” • Many sources of conflict • More meetings • Slow reaction time • Hard to monitor and control

• Duplication of resources • Rules not always respected • Potential lessons learned can be lost

• Discipline-specific knowledge can slip

• Less career continuity for project team members

Source: Adapted from Richard L. Daft,Management, 9th ed. (Mason, OH: South-Western Cengage Learning, 2010): 250–255; and PMBOK® Guide, 21-26.

58 Part 1 Organizing Projects

accomplished. Sometimes, the two managers will negotiate to determine which workers will be assigned to the project. While both hopefully want the best for the overall orga- nization, each has specific responsibilities. For example, the functional manager with sev- eral workers reporting to her wants each employee to have enough work but not be overloaded. She also wants all workers to grow in expertise. The project manager, on the other hand, wants the best workers for the project so she can be more assured of delivering good results. In a case like this, when they negotiate, the project manager may want the best resource (who is already busy) and the functional manager may offer the least experienced resource (who is available).

One other source of potential conflict between the project and functional managers deals with performance reviews. Often, the functional manager is tasked with writing performance reviews, yet some workers may spend a great deal of their time on projects. If the project managers are not allowed to provide input into the performance reviews, some project team members will work harder to please their functional managers and the projects can suffer. One project manager offers ideas regarding performance reviews in Exhibit 3.6.

Closely related to the organizational structure is another organizational decision that needs to be made—that of organizational culture. Project managers are not often part of the executive group that decides on organizational structure or organizational culture, but they certainly need to understand how these decisions impact reporting relation- ships, decision-making methods, and commitment for their projects.

3-2 Organizational Culture and Its Impact on Projects Just as project managers need to understand the structure of the parent organization, they also need to understand the culture of the parent organization if they are to com- municate effectively. Organizational culture is comprised of values, social rituals, and symbols that are shared among members of the organization and are taught to new members. “Values serve as a moral compass to guide us and provide a frame of reference to set priorities and determine right or wrong”.5 Values are implemented through social rituals such as meetings, training, and ceremonies along with symbols such as work layout and dress code.6 Collectively these can informally:

• Motivate the ethical actions and communications of managers and subordinates; • Determine how people are treated, controlled, and rewarded; • Establish how cooperation, competition, conflict, and decision making are handled; and • Encourage personal commitment to the organization and justification for its

behavior.7

EXHIBIT 3.6 360-DEGREE PERFORMANCE REVIEWS

In some organizations, the functional manager performs a 360-degree evaluation. This appraisal style requires that the functional manager seek feedback from a representative sample of the staff that have worked with that project team member to provide feedback on a 360-degree form. Being appraised by your peers or team members on a given project is considered best practice because they’ve observed the individual in action “in the trenches.” Many large organizations use this appraisal technique, since in large and/or complex organizations some staff rarely see their direct supervisor or manager, depending upon their function in that organization.

Source: Naomi J. Kinney, CPLP, principle consultant, Multilingual Learning Services.

Chapter 3 Organizational Capability: Structure, Culture, and Roles 59

Once a project manager understands the culture of the parent organization, he can determine how to best develop the culture within his project. Many projects are completed cooperatively between two or more parent organizations, or one organization (a contractor) will perform the project for the other organization (a client). Whenever more than one parent organization is involved, the project manager needs to understand the culture of each well enough to facilitate effective project communications and decision making.

3-2a Culture of the Parent Organization When a project manager studies the culture of the parent organization, she needs to ask the following questions:

• What is the orientation of the corporate culture in general? • What are the ascribed values? • How is the organization viewed by others in terms of living the values? • How does the organization like to communicate internally and externally? • How well does the organization support project management specifically?

TYPES OF POWER One framework that is helpful in understanding a corporate culture distinguishes the following four types of culture according to what is the most powerful motivator:

1. Power culture 2. Role culture 3. Task culture 4. Personal culture

Power cultures exist when the supervisor exerts a great deal of economic and political power and everyone tries to please the boss. Those in formal authority control competi- tion, conflict resolution, and communication.

Role cultures motivate everyone to understand and closely follow their appointed roles. Reliable workers follow formal designations of responsibility with utmost respect for regulations and laws.

In task cultures, it is more important to get the job done than to worry about who does the work or who gets credit. Hallmarks of task cultures are skill-based assignments, self-motivated workers, and more deference paid to knowledge than to formal authority.

In personal cultures, people show genuine interest in the needs of workers, consider worker development as critical to the organization’s success, and display an attitude that collaboration is satisfying and stimulating.8

Many organizations will have one dominant culture modified by at least one of the other types. An astute person will look not only for what people say when trying to understand the culture, but also actions, decisions, symbols, and stories that guide behavior.

A variety of organizational culture characteristics make project success more likely. These characteristics include appreciation for project management; collabora- tion to meet organizational goals; engagement of stakeholders; desire to provide value to customers; teamwork across cultures; integrity, trust, and transparency; insistence on continual learning; and provision of appropriate rewards and recognition.

MIDLAND INSURANCE COMPANY Midland Insurance Company espouses its values by giving every employee the “One Pager” that lists the organization’s mission, strategic

60 Part 1 Organizing Projects

imperatives, and core values. The CEO, John Hayden, will often pull his “One Pager” out at meetings and expects everyone else to do likewise. In talk and in action, Midland tries to live out the core values that comprise its organizational culture. Exhibit 3.7 shows Midland’s culture.

3-2b Project Cultural Norms While some of the project’s culture is dictated by that of the parent organization, effective sponsors and project managers can do many things to promote a good working cultural norms within the project. Many times, participants on a project have not worked together previously and may even come from parts of the organi- zation (or outside organizations) that have historically been rivals. The sponsor and project manager need to understand organizational politics and work to develop cooperation both within the core project team and among the various groups of project stakeholders.

When the project sponsor and manager are determining how to create the project culture, ethics should be an important consideration. One aspect of an ethical project culture is to determine how people should act. Project sponsors and managers learn that they need to act in the best interests of three constituencies: the project itself— attempting to deliver what is promised; the project team—encouraging and developing all team members; and the other project stakeholders—satisfying their needs and wants. Ethical project managers make decisions so that one of the three constituencies does not suffer unfairly when satisfying the other two. One list of behaviors adapted from the PMI Code of Ethics and Professional Conduct tells project managers to exhibit the following:

• Responsibility—take ownership for decisions. • Respect—show high regard for ourselves, others, and resources. • Fairness—make decisions and act impartially. • Honesty—understand the truth and act in a truthful manner.9

The other aspect of an ethical culture is how people actually act. Every project has difficult periods, and the measure of project ethics is how people act at those times. The project manager needs to show courage both in personally making the right decisions and in creating an atmosphere in which others are encouraged to make the right decisions. An ethical project culture in which people know how to act and have the courage to do so yields better ideas; when a spirit of mutual trust prevails, everyone participates with their ideas and effective partnering relationships within and beyond the project team.

EXHIBIT 3.7 MIDLAND INSURANCE COMPANY VALUES

• Integrity Win/Win • Creativity • Team • Propriety • Humility • Sharing/Caring • Strong Work Ethic • Personal Growth

Source: Martin J. Novakov, American Modern Insurance Group.

Chapter 3 Organizational Capability: Structure, Culture, and Roles 61

3-3 Project Life Cycles All projects go through a predictable pattern of activity, or project life cycle. Project planning teams use project life cycle models because various types of projects have differing demands. A research and development project may require a certain test to be performed before management approves the expenditure of large amounts of cash, while the manager of a quality improvement project may need to document how the work is currently performed before it makes sense to experiment with a new method. The major types of project life cycle models, while differing in details, have some things in common.

• They all have definite starting and ending points. • They involve a series of phases that need to be completed and approved before

proceeding to the next phase. • The phases generally include at least one initiating, one planning, one closing, and

one or more executing phases. • The various life cycle models are all frequently adapted by the companies, where

they are used to better fit with the organizational culture and language.

We will now look at several models that represent the variety used in improvement, research, construction, and agile projects. We introduce the agile approach to project management immediately after its life cycle model. In the remainder of the book, we will deal with the generic, plan-driven model that includes selecting and initiating, plan- ning, executing, and closing and realizing benefits, as shown in Exhibit 3.8. We will post an agile icon in the margin wherever we highlight how the agile or adaptive approach is different.

3-3a Define-Measure-Analyze-lmprove-Control (DMAIC) Model Many firms use projects to plan and manage quality and productivity improvement efforts. Various models are used for these improvement efforts. While these models appear to be somewhat different, they all strive to use facts to make logical decisions and to ensure that the results are as desired. The Six Sigma approach to quality improve- ment (a popular current approach explained in Chapter 11) uses the DMAIC model. A simple version of this model is shown in Exhibit 3.9.

3-3b Research and Development (R&D) Project Life Cycle Model Many organizations use project management techniques to organize, plan, and manage research and development efforts. These can vary in length from as much as a decade for taking a new pharmaceutical from idea to successful market introduction to as little as a few weeks to reformat an existing food product and deliver it to a client. Some R&D project models are complex and have many phases because of huge risks and demanding

EXHIBIT 3.8 GENERIC PROJECT LIFE CYCLE MODEL

Phase Selecting & Initiating

Approval to proceed

Charter Kickoff Project result

Administrative closure

Planning Executing Closing & Realizing

62 Part 1 Organizing Projects

oversight, yet some are much simpler. One simple R&D model adapted from defense development projects is shown in Exhibit 3.10.

3-3c Construction Project Life Cycle Model Just as in other project applications, since construction projects differ greatly in size and complexity, a variety of project life cycle models are in use. A generic construction proj- ect life cycle model is shown in Exhibit 3.11.

3-3d Agile Project Life Cycle Model One type of model increasingly used in information systems and some other projects allows for incremental plans and benefits. These approaches have been variously called iterative, incremental, adaptive, or change-driven. While agile is the umbrella name, some of the specific approaches are called SCRUM, XP, Crystal, EVO, phased delivery,

EXHIBIT 3.9 DMAIC MODEL

Phase Define Measure Analyze Improve Control

Approval to proceed

Problem statement

Fact gathering defined and facts collected

Root causes identified and statistically proven

Solution implemented

Methods in place to maintain improvements

EXHIBIT 3.10 R&D PROJECT LIFE CYCLE MODEL

Phase Idea Generation

Idea Screening

Concept Development Validation Transition

Approval to proceed

Opportunity analysis

Business case Proven concept Prototype First lot and hand-off

EXHIBIT 3.11 CONSTRUCTION PROJECT LIFE CYCLE MODEL

Phase Pre-Planning Design Procurement Construction Start Up

Approval to proceed

Scope definition and execution strategy

Procurement and construction documents

Materials and services

Facilities and processes

Production attainment

Source: Adapted from James D. Stevens, Timothy J. Kloppenborg, and Charles R. Glagola, Quality Performance Measurements of the EPC Process: The Blue- print (Austin, TX: Construction Industry Institute, 1994): 16.

A G I L E

Chapter 3 Organizational Capability: Structure, Culture, and Roles 63

rapid prototyping, and evolutionary. While these models may start like other project life cycle models, they provide short bursts of planning and delivery of benefits in multiple increments during project execution. A generic agile project life cycle model is shown in Exhibit 3.12.

3-4 Agile Project Management Traditional plan-driven project management works well in many situations, but if the scope is hard to define early in the project and/or when much change is expected, a change-driven or agile approach often works better. In many situations, project managers find the most useful method takes good practice from both plan- and change-driven approaches, just as the matrix form of organizing takes good ideas from both functional and projectized organizations. In this section, we intro- duce several basic ideas from agile. In subsequent chapters, we will explain them in more detail.

At the start of an agile project, overall planning is at a high level, and the only part that is planned in detail is the work that will be done soon. As people learn from the early work, the next portion of the project is planned in detail. The majority of the proj- ect work is conducted in iterations (sometimes called sprints) that are normally a set length of time such as two or four weeks. The project team agrees to deliver something of value at the end of each iteration. The fixed time and amount of committed resources for each iteration dictate how big that deliverable will be, and the team agrees with the customer how the deliverable will be considered complete and useful. Each iteration has initial planning, a brief daily planning meeting, a demonstration of the value at the end of the iteration, and a retrospective meeting at the end to learn and apply the learnings to the next iteration. Documentation is minimal early in the project but becomes progressively more complete. Within an iteration, change is rarely permitted, but it is expected from one iteration to the next.

Sponsors, customers, project managers, and team members need to be actively engaged. The sponsor and customer may be the same or two different people. The customer prioritizes work from a business needs standpoint, making tradeoffs between value, quality, and constraints. The project manager is sometimes called a scrum master to emphasize the need to facilitate and remove obstacles rather than to command and control. The team needs to be self-directed with high trust. All of the roles are more collaborative than confrontational.

EXHIBIT 3.12 AGILE PROJECT LIFE CYCLE MODEL

Production release

Product backlog

Incremental Implementation

Charter

Project Envisioning

Requirements Gathering

Plan Replan Test

Develop Close

Sprint

Plan Replan Test

Develop Close

Sprint

Plan Replan Test

Develop Close

Sprint

Phase

Approval to proceed

64 Part 1 Organizing Projects

3-5 Project Executive Roles Projects do not exist in a vacuum. They exist in organizations where they require resources and executive attention. Projects are the primary method that organizations use to reach their strategic goals. As such, a variety of players need to be involved at the executive, managerial, and associate levels, as shown in Exhibit 3.13. Especially in small organizations, one person may perform more than one role. For example, a spon- sor may perform some or all of the activities normally expected from the customer. The four project executive roles are the steering team (ST), the sponsor, the customer, and the chief projects officer (CPO).

3-5a Steering Team In small to medium-sized organizations, the steering team (sometimes known as the executive team, management team, leadership team, operating team, or other titles) often consists of the top person in the organization and his or her direct reports. They should collectively represent all of the major functions of the organization. In larger organizations, there may be steering teams at more than one level. When that occurs, the steering teams at lower levels are directed and constrained by decisions the top- level steering team makes. Some organizations divide the duties of the steering team by creating project review committees and delegating tasks to them. In any event, the duties of the steering team revolve around the following five activities:

1. Overall priority setting 2. Project selection and prioritization 3. Sponsor selection 4. General guidance 5. Encouragement

The steering team generally sets overall organizational priorities with the CEO. This is a normal part of strategic planning, as described in Chapter 2. Once the overall organi- zational goals have been set, the steering team agrees on the criteria for selecting projects and then selects the projects the organization plans to execute during the year. Once the overall project list is complete, they determine the relative priorities of the projects to determine which will start first.

Simultaneously, the steering team often helps the CEO decide who will sponsor potential upcoming projects. In turn, the steering team often helps the sponsor select the project leader. In some cases, the steering team even gets involved in deciding which critical team members will be on the project. This is especially true if very few people in the organization have highly demanded skills. The steering team can decide which project these people will work on as part of the prioritizing effort.

EXHIBIT 3.13 PROJECT EXECUTIVE, MANAGERIAL, AND ASSOCIATE ROLES

EXECUTIVE LEVEL MANAGERIAL LEVEL ASSOCIATE LEVEL

Steering Team (ST) Functional Manager (FM) Core Team Member

Sponsor Project Manager (PM) Subject Matter Expert (SME)

Customer Scrum master

Chief Projects Officer (CPO) Facilitator

Chapter 3 Organizational Capability: Structure, Culture, and Roles 65

Guidance from the steering team includes feedback during formal reviews as well as informal suggestions at other times. Since steering teams understand how important project success is in achieving organizational objectives, they normally demand to have formal project reviews. These can occur either at set calendar times or at a projectmilestone,which is “a significant point or event in the project.”10 At these formal reviews, the steering team can tell the project team to continue as is, to redirect their efforts in a specific manner, or to stop the project altogether.

In terms of informal suggestions, it is very empowering to project participants if the steering team members ask how the project is going and offer encouragement when they run into each other in the normal course of work. It shows project participants that their work is important and has high visibility in the organization.

3-5b Sponsor PMI defines a sponsor as “the person or group who provides resources and support for the project and is accountable for enabling success for the project.”11 In this sense, the sponsor is normally an individual who has a major stake in the project outcome. Spon- sors often perform a variety of different tasks that help a project, both in public and behind the scenes. Major sponsor responsibilities are shown by project stage in Exhibit 3.14. The sponsor for major projects is often a member of the steering team. On smaller projects, the sponsor may hold a lower position in the organization.

As a member of the steering team, the sponsor should understand the corporate strat- egy and be prepared to help with project selection and prioritization. Sponsors should pick the project manager and core team (sometimes with help from the project manager and/or others). Sponsors should mentor the project manager to ensure that person understands his role and has the skills, information, and desire to successfully manage the project.

In the next chapter, we discuss chartering. Sponsors ideally take an active role in chartering the project by creating a first draft of the business case and scope overview statements for the project. If a sponsor does not take time for this, the project manager needs to ask questions to elicit this business case and scope overview information. Then the sponsor should insist that a milestone schedule, preliminary budget, risk identifica- tion, assessment criteria, communication plan, and lessons learned be developed by the project manager and team. The sponsor then either personally approves the charter or takes the charter to the steering team for approval.

EXHIBIT 3.14 SPONSOR RESPONSIBILITIES BY STAGE

STAGE SPONSOR RESPONSIBILITIES

Overarching Provide resources, manage stakeholder relationships, deliver results

Selecting Identify, select, prioritize projects

Initiating Mentor project manager, charter project

Planning Meet key stakeholders, ensure planning

Executing Nurture key stakeholders, ensure communications, ensure quality

Closing Ensure stakeholder satisfaction, closure, and knowledge management

Realizing Ensure benefits are achieved and capability is increased

Source: Adapted from Timothy J. Kloppenborg and Laurend J. Laning, Strategic Leadership of Portfolio and Project Management (Business Expert Press, New York 2012): p. 47.

66 Part 1 Organizing Projects

As the project progresses, the sponsor helps behind the scenes by obtaining resources, removing roadblocks, making high-level decisions, and interfacing between the project core team and the executive team. Sponsors often share their vision for the project with various stakeholders. When providing staff, sponsors ensure they are adequate in number and skill. This may include training. It may also include negotiating for staff. Sponsors often let their project managers arrange this training and negotiate for resources. However, the sponsor needs to make sure that both are satisfactorily completed.

Once again, sponsors with experienced project managers may merely need to ensure their project managers have the means in place to monitor and control their projects. Large projects with many stakeholders often have formal kickoff meetings. The sponsor’s presence demonstrates corporate commitment. Sponsors represent the customer to the project team. The sponsor must ensure that several important customer-related tasks are performed as follows:

• All customers (stakeholders) have been identified. • Their desires have been uncovered and prioritized. • The project delivers what the customers need. • The customers accept the project deliverables.

Again, the project manager should do much of this, but the sponsor is also responsi- ble for its completion. While sponsors represent their projects, they also represent the larger organization. As such, they often should be one of the first persons to determine the need to stop a project that is no longer needed or is not performing adequately. Finally, after the project results have been used for a period of time, the sponsor should make sure the expected results have happened.

3-5c Customer While the specific demands of the customer role are spelled out here, understand that some or all of this role may be carried out by the sponsor—particularly for projects internal to a company. When a busy customer buys something, it may be tempting to just place an order and have it delivered. That process is fine for an off-the-shelf item or for a transactional service. However, when it is a one-of-a-kind project, hands-off ordering does not work. The question then becomes: What does a customer need to do to ensure the desired results? Exhibit 3.15 shows a list of seven tasks a customer can do before and during a project to enhance the probability of success. The customer performs three of these tasks independently and the other four jointly with the project contractor. The three customer-only project tasks are prioritizing the project need, carefully selecting a good contractor, and killing the project if necessary. The four joint tasks are writing and signing the project charter, developing clear and detailed requirements, setting up and using project control systems, and conducting a great project kickoff meeting.

EXHIBIT 3.15 CUSTOMER TASKS ON PROJECTS

INDEPENDENT TASKS JOINT TASKS WITH CONTRACTOR

1. Prioritize project 1. Write and sign charter

2. Select good contractor 2. Develop clear requirements

3. Kill project if needed 3. Use control system

4. Conduct kickoff meeting

Chapter 3 Organizational Capability: Structure, Culture, and Roles 67

INDEPENDENT TASKS The first requirement is to prioritize each project. The knowl- edge that one particular project is the highest priority for a company should be commu- nicated, and that project should be tackled by the “A team.” A related prioritization question is: Do we need this project so badly right now that we are willing to start it even without the skilled personnel, resources, or technology on hand that would improve the probability of successful completion? If so, ensure this particular project gets top billing. If not, consider delaying it.

The second customer task is to carefully select a competent and honest contractor to perform the project. All of the important joint tasks are much easier with the right contractor, the probability of success goes up, and everyone’s stress level goes down.

The third customer task is to determine whether to pull the plug on a troubled project. This could happen right at the start if the project appears to be impractical. It could happen during detailed planning when the requirements, schedule, budget, risks, or other aspects indicate trouble. More often, it occurs during project execution when the project progress does not live up to the plan. A customer needs to decide when to stop throwing good money after bad.

JOINT TASKS WITH CONTRACTOR The first joint task for customers and contractors is to create and ratify the project charter. The charter (as explained more fully in Chapter 4) is a broad agreement concerning the project goals, rationale, risks, timeline, budget, approach, and roles—even though all of the details have yet to be determined. The charter should help to identify projects that appear risky or otherwise impractical from the outset. These projects should either be scrapped, or a different approach should be used. If the project looks promising, both the contractor and the customer normally sign the charter and feel morally bound to its spirit.

Once the charter is signed, the contractor and customer need to develop detailed requirements. Some of the challenges many customer companies face are differing proj- ect expectations among the members of the organization. Somehow the conflicting desires of multiple people in the customer’s organization must be combined into one set of requirements that will be provided to the people who will perform the project work. Senior customer representatives and project managers frequently work together to determine the requirements.

The customer and the contractor often collaborate on the set up and use of several project control systems. One of these is a communications plan (which is explained in Chapter 5). Since the customer is often the recipient of communications, he needs to tell the contractor what he needs to know, when he needs to know it, and what format will be most convenient. This should include regular progress reports. Second is a change control system (also explained in Chapter 5). Most projects will have multiple changes. A method must be created to approve potential changes, document their impact, and ensure that they are carried out as agreed. Third is a risk management system (explained in Chapter 10). Customers should work with developers to brainstorm possible risks, consider how likely each risk is to occur, measure a risk’s impact should it happen, and develop contingency plans. The customer needs to ensure that effective communications, change management, and risk management systems are used.

Customers must help plan and participate in a project kickoff meeting. This meeting should be widely attended, give everyone involved in the project a chance to ask ques- tions, and be used to build excitement for the project.

Customers get what they pay for on projects, but only when actively involved in key activities. Customers have the sole responsibility of prioritizing their own needs, selecting a contractor to perform their project, and terminating a project that is not working.

68 Part 1 Organizing Projects

Customers and contractors share the responsibility for crafting and agreeing to a project charter, articulating requirements, developing and using project control systems, and conducting an informative and energetic project kickoff.

In agile projects the customer (who may be the sponsor) is responsible for the return on investment earned by the project; prioritizing scope; and accepting or rejecting acceptance of deliverables at the end of each iteration.

3-5d Chief Projects Officer/Project Management Office Organizations need to have one person who “owns” their project management system and is responsible for all the people who work on projects. While different companies use different titles for this position (such as project director or manager of project managers), we will use the title chief projects officer (CPO). Just as companies’ size and complexity vary greatly, so does the role of CPO. Large companies frequently have a project management office (PMO). The PMO performs the CPO role. At small compa- nies, the CPO role may be performed informally by the CEO, who also juggles many other time demands. Companies in the medium-size range may find it useful to appoint an executive who already has other responsibilities as the CPO. Ensuring projects are planned and managed well is so central to the success of most companies that a highly capable individual is normally assigned this responsibility.

So, what are the responsibilities of the chief projects officer? They include ensuring that the company’s steering team:

• Identifies potential projects during strategic planning • Selects a manageable set of projects to be implemented • Prioritizes effectively within that set • Ensures enough resources (people, money, and other resources) are available to

perform the projects • Selects appropriate project sponsors and teams • Charters the project teams • Monitors and controls the implementation of the projects • Rewards the participants • Enjoys the results of successful projects!

If that is not enough, the CPO also ensures that each individual serving on a project:

• Receives the training he or she needs • Captures lessons learned from completed projects • Uses lessons learned from previous projects on new projects • Uses templates and standards when appropriate

3-6 Project Management Roles The manager-level roles in projects include the functional manager, project manager, scrum manager, and facilitator.

3-6a Functional Manager Functional managers are often department heads. Projects come and go, but departments generally remain. Functional managers have a large role in deciding how the project work in their functional area is done. Functional managers and project managers may negotiate who will be assigned to work on the project.

A G I L E

Chapter 3 Organizational Capability: Structure, Culture, and Roles 69

Generally, top management in an organization needs to decide how the relative decision-making power in the organization is divided between project managers and functional managers. Organizations that are new to formalized project mana- gement often start with functional managers having more power. Often, this changes over time until project managers for big projects have relatively more power.

3-6b Project Manager The project manager is the focal point of the project. He or she spends a large amount of time communicating with everyone who is interested in the project. The project manager leads the planning, execution, and closing of the project. This person ideally should be a flexible, facilitating leader. Since project managers are responsible for the project sched- ule, they have a large role in deciding when project activities need to be accomplished. Project managers are trusted with delivering project results needed by their parent orga- nizations. As such, project managers need to be worthy of that trust by possessing both integrity and necessary skills.

DESIRED BEHAVIORS Exhibit 3.16 shows a few of the behaviors project managers can develop first in regard to integrity and then in regard to each of the 10 project management knowledge areas needed to successfully plan and manage projects. This book describes some of the factual knowledge project managers need to acquire to become proficient. Project managers also need to acquire experiential knowledge by practicing these behaviors on projects. Not all project managers will become equally adept at each behavior, but an understanding of the behaviors exhibited by excellent project managers is a great way to start. Remaining chapters in this book elaborate on these behaviors. Collectively, all of these skills make for a great, well-rounded project manager.

COMMUNICATION CHANNELS Envision a bicycle wheel, as shown in Exhibit 3.17. The project manager is like the hub, and the spokes are like the many communication channels the project manager needs to establish and use with project stakeholders. While there are many project manager requirements, some of the technical needs can probably be delegated, but every project manager needs integrity, leadership, and communications skills.

CHALLENGES Project managers deal with several challenges. One is that they often have more responsibility than authority. This means they need to persuade people to accomplish some tasks rather than order them to do so. Project managers can create interesting and challenging work assignments for their team members. Many people find this stimulating. Project managers can more effectively attract followers when they display high integrity and the ability to get the job done. This includes both technical ability and communications ability. Project managers primarily deal with networks of people both within and outside their parent company. An effective project manager knows how to get to the source of the networks. A challenge for project managers is determining how networks function within certain organizational cultures. This is why organizational culture is so important. What are the networks within the organization? How do people work, communicate, and problem solve beneath the function of their job titles?

70 Part 1 Organizing Projects

EXHIBIT 3.16 DESIRED PROJECT MANAGER BEHAVIORS

INTEGRITY: A PM demonstrates integrity by making honest decisions, protecting people, defending core values, leading major change, honoring trust, showing respect, establishing a culture of honesty, and displaying total commitment to project and people.

INTEGRATION: A PM is an effective integrator by leading the chartering process, coordinating assembly of a detailed and unified project plan, balancing the needs of all stakeholders, making logical tradeoff decisions, and keeping focus on primary objectives.

SCOPE: A PM deftly handles project scope by obtaining a deep understanding of stakeholder wants and needs, determining true requirements, learning if proposed changes are essential, stopping un- necessary scope creep, and demonstrating needed flexibility.

TIME: A PM is an effective scheduler by leading schedule development, understanding resource and logic limitations, understanding the project life cycle, focusing on key milestones, and making schedule decisions while being aware of cost and scope issues.

COST: A PM maintains cost control by developing an accurate understanding of project scope, determining reliable cost estimates, controlling all project costs, and calculating and honestly reporting all variances in a timely and transparent manner.

QUALITY: A PM achieves project quality by learning customer expectations and how they relate to organizational objectives, insisting project decisions are based upon facts, utilizing lessons learned, ensuring effective work processes are used, and leading testing.

HUMAN RESOURCES: A PM effectively handles human resource issues by leading in a facilitating manner when possible and forcefully when needed, attracting and retaining good workers, developing a self-directed project team, and creating a sense of urgency.

COMMUNICATIONS: A PM displays good communications by listening and speaking well, advocating the project vision, maintaining enthusiasm, focusing attention on key issues, establishing order, working through conflict, seeking support, and openly sharing.

RISK: A PM effectively deals with project risk by openly identifying risks and opportunities, honestly evaluating each, developing avoidance strategies when practical and mitigation strategies when needed, and courageously recommending needed actions.

PROCUREMENT: A PM effectively procures needed goods and services by accurately documenting all requirements, identifying and fairly considering all potential sellers, proactively managing contracts and relationships, and ensuring all deliveries.

STAKEHOLDER: A PM deals effectively with stakeholders by robustly identifying all who are interested in the project, asking probing questions to understand their desires, and ensuring someone on the project team maintains effective relationships with each.

EXHIBIT 3.17 PROJECT MANAGER COMMUNICATION CHANNELS

Project Manager Stakeholders

Chapter 3 Organizational Capability: Structure, Culture, and Roles 71

A rookie project sponsor and rookie project manager should not be assigned to the same project. While the sponsor normally mentors the project manager, when a sponsor is new, some of the mentoring may go the other way—just as a master sergeant may help a new lieutenant learn about leading troops.

JUDGMENT CALLS Due to the very nature of projects—each one having a unique set of stakeholders, output, and project team—project managers cannot always follow a cookbook approach in how they manage. They must develop judgment. Exhibit 3.18 lists some judgment calls that project managers need to be prepared to make on a frequent basis.

COMPETENCIES BY PROJECT STAGE Just as sponsor demands vary by project life cycle stage, so do those of project managers, as shown in Exhibit 3.19.

3-6c Scrum Master In agile projects, a new title is introduced—the scrum master. In effect, this is a project manager who serves and leads in a collaborative, facilitating manner. This is totally consistent with contemporary project management since many individuals do much better work when they actively plan it rather than have it assigned to them. The scrum master guides team members as they prioritize tasks and removes obsta- cles to their progress. In this book we consider the scrum master to be the project manager.

3-6d Facilitator Some project management situations require facilitation because the situation is so com- plex and/or because the opinions are so varied. Sometimes, the workers on a project need to expand their thinking by considering the many possibilities (possible projects, approaches, risks, personnel, and other issues). Other times, the workers on the project need to focus their thinking by selecting from many options (a project, an approach, a

EXHIBIT 3.18 PROJECT MANAGER JUDGMENT CALLS

A few general questions project managers need to ask themselves is when to:

• Act vs. analyze • Lead vs. follow • Lead vs. administer • Repeat vs. change • Change expectations vs. accept them • Take over vs. let the team perform • Focus on the big picture vs. focus on details • Focus on technical vs. focus on behavioral • Focus on short term vs. focus on long term • Promote order (control) vs. promote innovation (freedom) • Allow (constructive) conflict vs. discourage (destructive) conflict • Focus communications inside the project vs. focus communications outside • Demonstrate optimism vs. demonstrate pessimism • Advocate for the project vs. accept termination • Focus on project goals vs. organizational, personal, or team member goals • Enhance, maintain, or accept changes in scope, quality, cost, and schedule

A G I L E

72 Part 1 Organizing Projects

contractor, or a mitigation strategy). Most project managers and sponsors can and do fa- cilitate many meetings. However, the project manager may prefer to focus on the content of a meeting and enlist a facilitator to help focus on the process of the meeting. In these situations, an outside facilitator may be useful. Often, a disinterested sponsor or project manager (one who works on other projects, but not on this one) is used when a facilitator is needed. Sometimes, the chief projects officer or an outside consultant is used to facilitate.

3-7 Project Team Roles The team- or associate-level roles in projects are core team members and subject matter experts (SMEs).

3-7a Core Team Members Core team members are the small group of people who are on the project from start to finish and who jointly with the project manager make many decisions and carry out many project activities. If the project work expands for a period of time, the core team members may supervise the work of SMEs who are brought in on an as-needed basis. Ideally, the core team is as small as practical. It collectively represents and understands the entire range of project stakeholders and the technologies the proj- ect will use. It is generally neither necessary nor useful to have every single function represented on the core team, since that would make communication and scheduling meetings more difficult. Also, if every function is represented directly, team members tend to fight for turf.

The ideal type of core team member is one who is more concerned with completing the project (on time, with good quality, and on budget if possible) than with either per- sonal glory or with only doing work in his or her own discipline. He or she does what it takes to get the project done.

EXHIBIT 3.19 PROJECT MANAGER COMPETENCIES BY PROJECT LIFE CYCLE STAGE

STAGE COMPETENCY

Initiation Effective questioning/generating feedback Persuasiveness/marketing/selling Listening skills Vision oriented/articulate the business problem Consensus building

Planning Project management skills and knowledge Consensus building Technical skills/theoretical knowledge

Implementation Ability to get along/team player Results oriented Truthful/honest

Close Writing skills Share information and credit Pride in workmanship/quality Truthful/honest

Source: Gregory J. Skulmoski and Francis T. Hartman, “Information Systems Project Manager Soft Competencies: A Project-Phase Investigation,” Project Management Journal (March 2010): 61–77.

Chapter 3 Organizational Capability: Structure, Culture, and Roles 73

Core teams on agile projects are ideally self-directed. They organize themselves and exhibit significant maturity. They create their own estimates and report to each other daily. The same members should be on the team for an entire iteration, although the team can change from one iteration to the next. The members should be co-located and assigned to the project full time for the duration of the iteration.

3-7b Subject Matter Experts While core team members are typically assigned to the project from start to finish, many projects also have a specific and temporary need for additional help. The necessary help may be an expert who can help make a decision. It may be extra workers who are needed at a busy time during the life of the project. Some extra help may be needed for as little as one meeting; other extra help may be needed for weeks or months. These extra helpers are often called subject matter experts (SMEs) since they are usually needed for their specific expertise.

SMEs are brought in for meetings and for performing specific project activities when necessary. A project could have almost any number of SMEs, depending on its size and complexity.

SMEs are not on the core team but still are essential to the project. SMEs may be on a project for a long time and thus be almost indistinguishable from core team members.

However, SMEs may spend only a little time on a particular project and, there- fore, may not relate strongly to it. At times, it is a struggle to get them scheduled and committed. Typically, a project manager would have a newly assigned SME read the project charter and the minutes from the last couple of meetings before discussing the project with him. It is a balancing act to ensure that the SME under- stands what she needs to do and how important it is, without spending a great deal of time in the process.

Summary Projects are accomplished either within an organiza- tion or between multiple organizations when differ- ent firms work together. Project managers are more effective if they understand the impact the organiza-

tion has on the project. In contemporary society, different organizations choose different organiza- tional structures because they feel there is an advan- tage in their unique circumstances. While many are

Core team members understand all aspects of the project and stay with the project through completion.

A G I L E

© Fl as hS tu di o/ Sh ut te rs to ck .c om

74 Part 1 Organizing Projects

still officially organized in a traditional functional manner, an increasing number of organizations have at least informal matrix relationships. The days of having only one boss are gone for many workers—and especially for many project managers. Each form of organization has strengths and chal- lenges with respect to projects.

Organizations also have a culture—the formal and informal manner in which people relate to each other and decisions are made. The hierarchical approach with the boss having supreme authority has long van- ished in many places. Many organizations today use a more collaborative approach—some much more than others. Whatever the approach, project managers need to understand it and the impact it creates on their project. Project managers and sponsors need to create a culture in their project that is consistent with, or at

least can work effectively with, that of the parent orga- nization. Both organizational structure and culture can become more complicated if more than one organiza- tion is involved in the project and if they differ in these respects.

Projects follow a predictable pattern or project life cycle. Many industries have typical project life cycles, but they vary greatly. A project manager needs to at least understand what project life cycle model is used at her organization and often needs to select or modify the project life cycle to the specific demands of the project.

Multiple executive-, managerial-, and associate-level roles need to be performed in projects. The project manager is a central role and the subject of this book. Project managers need to understand the other roles and relate effectively to them.

Key Terms from the PMBOK® Guide functional organization, 54 projectized organization, 55 co-location, 56

matrix organization, 56 milestone, 66 sponsor, 66

Chapter Review Questions 1. Describe how a strong (project) matrix is differ-

ent from a weak (functional) matrix . 2. Which organizational structure is often used for

small projects that require most of their work from a single department?

3. List advantages and disadvantages of func- tional, projectized, and matrix forms of organization.

4. What is co-location, and why is it used? 5. What are organizational values, and what can a

project manager accomplish with them? 6. List and describe four different types of corporate

culture. 7. If more than one parent company is involved

in a project, why is it important for the project manager to understand the culture of each?

8. The project manager and sponsor need to act in the best interest of which three constituencies?

9. According to the PMI Code of Ethics and Pro- fessional Conduct, project managers need to exhibit which four behaviors?

10. In your own words, describe an ethical project culture.

11. What are some characteristics of almost all project life cycles?

12. What does the DMAIC model acronym stand for? When is this type of model used?

13. What distinguishes an agile project life cycle model different from other types of life cycle models?

14. For what five activities is the project steering team responsible? What additional role may a steering team member sometimes play?

15. Who should select the project manager and the core team?

16. Who is responsible for ensuring that the steering team completes its tasks?

17. What types of control systems should a customer and contractor work together to set up and utilize?

Chapter 3 Organizational Capability: Structure, Culture, and Roles 75

Discussion Questions 1. Marissa Mayer, CEO of Yahoo, sparked a

national debate when she insisted that all her employees be physically present for work. Debate the merits of co-location, including its advan- tages and disadvantages.

2. Identify each of the four organizational culture types with respect to power, and briefly describe what is the strongest motivator for each type.

3. List and describe at least four organizational culture characteristics that increase the likelihood of project success, and tell why each is helpful.

4. Explain multiple methods through which project managers can lead by example.

5. Define your personal project code of ethics.

6. Identify qualities that effective project leaders can use to resolve ethical conflicts on projects.

7. You work for a software company. What benefits do you achieve by utilizing an Information Sys- tems project life cycle model as opposed to other project life cycle models?

8. If a project will be divided into many phases, which life cycle model would you recommend using to plan it? Why?

9. Describe a possible imbalance between a project manager’s authority and responsibility. What impact might it have on a project?

10. Is it important to choose a member from every impacted function of a project for the core team? Explain the impact of your decision.

PMBOK ® Guide Questions 1. All of the following are characteristics of a pro-

jectized organization EXCEPT: a. decision making is streamlined b. coordination is the responsibility of project

managers c. functional managers have the majority of

authority d. focus is on the customer

2. Characteristics of an organizational culture can have a major impact on a project’s success. All of these are attributes of an organizational culture EXCEPT: a. motivation and reward systems b. risk tolerance c. code of conduct d. financial control procedures

3. organization structures can be classified as weak, balanced, or strong, depending on the relative level of influence between the functional manager and the project manager. a. Silo b. Matrix c. Composite d. Projectized

4. A hierarchical organization where each employee has one clear superior, staff are grouped by areas of specialization and managed by a person with expertise in that area is known as a: a. composite organization b. functional organization

c. projectized organization d. weak matrix organization

5. In an agile life cycle model . a. the scrum master controls the team b. detailed planning precedes execution c. customer requirements are gathered early in

the project d. the team is self-directed

6. The project sponsor’s responsibilities during the executing stage include: a. reviewing and signing the project charter b. signing off on the detailed project plan c. ensuring communications with key stakeholders d. producing project status reports

7. Group phenomena that evolve over time and include established approaches to initiating and planning projects, the acceptable means for getting the work done, and recognized decision- making authorities are referred to as: a. organization structures b. roles and responsibilities c. project culture (norms) d. vision and mission

8. Customer responsibilities on a project might include all of the following EXCEPT: a. perform the work of the project to achieve its

objectives b. advise on project requirements c. review and accept project deliverables d. participate in status or kickoff meetings

76 Part 1 Organizing Projects

9. The Chief Projects Officer or PMO’s responsi- bilities might include: a. signing the project charter b. ensuring enough resources are available to

perform the project c. working with the team to create a project

schedule and budget d. promoting the project at the executive level of

the organization

10. PMI’s Code of Ethics and Professional Conduct is a guide for project management practitioners that describes the expectations that they should hold for themselves and others. Which of these is not one of the desired behaviors and basic obli- gations referenced by the code of conduct? a. fairness b. honesty c. authority d. respect

Exercises 1. Given a scenario, select a preferred organiza-

tional structure and justify your selection. 2. Describe examples of ethical (or non ethical)

behavior as outlined in PMI’s Code of Ethics and Professional Conduct exhibited on a project in the news.

3. Describe, with examples, how a project manager on a project you have observed did or did not exhibit desirable project manager behaviors as described in Exhibit 3.16.

4. Briefly describe how the sponsor of your project is or is not displaying appropriate life cycle– specific behaviors as described in Exhibit 3.14.

Example Project Instructions For your example project, describe the organizational structure of the agency or company for which you are planning the project. Describe as many of the organi- zational culture attributes as you can. List, by name, as many of the project executive, management, and team roles as you can identify. Be sure to assign roles to yourself and your classmates if you are doing the proj-

ect as a team. How do you anticipate that the organi- zational structure, culture, and role assignments help or hurt your ability to successfully plan this project? Describe the project life cycle model that is used in the organization—and if one is not currently used, describe the life cycle model you plan to use and tell why it is appropriate.

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Aldag, Ramon J. and Loren W. Kuzuhara, Mastering Management Skills (Mason, OH: Thomson South- Western, 2005).

Andersen, Erling S., “Understand Your Project’s Character,” Project Management Journal (December 2003): 4–11.

Aronson, Zvi H., Aaron J. Shenhar, and Peerasit Pata- nakul, “Managing the Intangible Aspects of a Project: The Affect of Vision, Artifacts, and Leader Values on Project Spirit and Success in Technology- Driven Projects,” Project Management Journal (February 2013): 35–58.

Blomquist, Tomas, and Ralph Muller, “Practices, Roles and Responsibilities of Middle Managers in Program

and Portfolio Management,” Project Management Journal (March 2006): 52–66.

Cobb, Charles G., “At Odds?” PMNetwork (May 2012): 26–27.

Collyer, Simon, Clive Warren, Bronwyn Hemsley, and Chris Stevens, “Aim, Fire, Aim—Project Planning Styles in Dynamic Environments,” Project Management Journal (September 2010): 106–121.

Crawford, Lynn, “Developing Organizational Project Management Capability: Theory and Practice,” Project Management Journal (August 2006): 74–86.

Daft, Richard L., Management, 9th ed. (Mason, OH: South-Western Cengage Learning, 2010).

Gale, Sarah F. “The Evolution of Agile,” PMNetwork (January 2012): 28–33.

Chapter 3 Organizational Capability: Structure, Culture, and Roles 77

Johnson, Craig E., Meeting the Ethical Challenges of Leadership: Casting Light or Shadow, 3rd ed. (Thousand Oaks, CA: Sage Publications, Inc., 2009).

Kloppenborg, Timothy J., Chris Manolis, and Debbie Tesch, “Investigation of the Sponsor’s Role in Project Planning,”Journal of Managerial Issues, in press. 2011 34(4): pp 400–416.

Kloppenborg, Timothy J., Chris Manolis, and Debbie Tesch, “Successful Project Sponsor Behavior During Project Initiation: An Empirical Investigation,” Journal of Managerial Issues (Spring 2009): 140–159.

Kloppenborg, Timothy J., Deborah Tesch, Chris Man- olis, and Mark Heitkamp, “An Empirical Investiga- tion of the Sponsor’s Role in Project Initiation,” Project Management Journal (August 2006): 16–25.

Lussier, Robert N., and Christopher F. Achua, Leadership: Theory, Application, and Skill Development, 4th ed. (Mason, OH: South-Western Cengage Learning, 2010).

Rath, Tom, and Barry Conchie, Strengths Based Lead- ership: Great Leaders, Teams, and Why People Follow (New York: Gallup Press, 2008).

Skulmoski, Gregory J., and Francis T. Hartman, “Information Systems Project Manager Soft

Competencies: A Project-Phase Investigation,” Project Management Journal (March 2010): 61–77.

Stevens, James D., Timothy J. Kloppenborg, and Charles R Glagola, Quality Performance Measure- ments of the EPC Process: The Blueprint (Austin, TX: Construction Industry Institute, 1994): 16.

Wikipedia, http://en.wikipedia.org/wiki/New_product_ development, accessed May 28, 2010.

http://www.pmi.org/About-Us/Ethics/~/media/PDF/ Ethics/ap_pmicodeofethics.ashx, Project Manage- ment Institute Code of Ethics and Professional Conduct, accessed May 22, 2013.

Agile Project Management For PMPs – VersionOne http://www.versionone.com/Webcasts/Agile_PM_ for_PMPs.asp, accessed May 22, 2013

http://www.internetsociety.org/who-we-are/mission/ strategic-objectives, Internet Society: Who We Are, accessed May 22, 2013.

http://www.slideshare.net/bkappe/agile-requirements- writing, Slideshare Aglie Requirements Writing accessed May 22, 2013.

Endnotes 1. PMBOK® Guide 541. 2. PMBOK® Guide 556. 3. PMBOK® Guide 532. 4. PMBOK® Guide 546. 5. Johnson, Craig E., Meeting the Ethical Challenges of

Leadership: Casting Light or Shadow, 3rd ed. (Thou- sand Oaks, CA: Sage Publications, Inc., 2009): 89.

6. Aronson, Zvi H., Aaron J. Shenhar, and Peerasit Pata- nakul, “Managing the Intangible Aspects of a Project: The Affect of Vision, Artifacts, and Leader Values on Project Spirit and Success in Technology-Driven Pro- jects,”ProjectManagement Journal (February 2013): 51.

7. Adapted from Erling S. Andersen, “Understand Your Project’s Character,” Project Management

Journal (December 2003): 4–11; and Ramon J. Aldag and Loren W. Kuzuhara, Mastering Manage- ment Skills (Mason, OH: Thomson South-Western, 2005).

8. Adapted from Erling S. Andersen, “Understand Your Project’s Character,” Project Management Journal (December 2003): 4–11.

9. PM1 Code of Ethics and Professional Conduct, http:// www.pmi.org/About-Us/Ethics/~/media/PDF/ Ethics/ap_pmicodeofethics.ashx, accessed May 22, 2013 (Newtown Square, PA: Project Management Institute, 2006): 12–13.

10. PMBOK® Guide 546. 11. PMBOK® Guide 563.

78 Part 1 Organizing Projects

PROJECT MANAGEMENT I N ACT I ON

Project Leadership Roles at TriHealth

TriHealth is a company that manages several large hospitals and a variety of other health organizations, such as physical fitness facilities and nursing services. Due to the company’s increasing size and complexity, TriHealth leadership decided they needed to formally define roles of project executive sponsor, project leader, performance improvement consultant, core team member, and subject matter expert. These roles are shown below.

Project Executive Sponsor Initiating Stage • Empower project leader with well-defined charter,

which is the overarching guide

• Clearly define expected outcomes

• Demonstrate commitment to and prioritization of project

• Define decision-making methods and responsibility— sponsor/project leader/team

• Partner with project leader to identify obstacles, barriers, and silos to overcome

Planning Stage • Ensure Project Leader understands business context

for organization

• Ensure Project Leader develops overall project plan

• Assist Project leader in developing vertical and hori- zontal communication plan

• Demonstrate personal interest in project by invest- ing time and energy needed

• Secure necessary resources and organizational support

Executing Stage • Communicate and manage organizational politics

• Visibly empower and support Project Leader verti- cally and horizontally

• Build relationships with key stakeholders

• Actively listen to and promote team and project to stakeholders

• Remove obstacles and ensure progress of project

• Ensure goals are met and stakeholders are satisfied

Closing Stage

• Ensure closure; planned completion or termination

• Ensure results and lessons learned are captured and shared

• Ensure assessment of related applications or opportunities

• Ensure any necessary next steps are assigned and resourced

• Recognize contributions and celebrate completion

• Negotiate follow-up date(s) to assess project status

Project Leader All of the roles listed are the ultimate responsibility

of the project leader. However, in the development of the charter, the Sponsor and the Project Leader will have a discussion about the Project Leader role. At that time, the individuals will determine if the Project Leader needs additional assistance or skills to facilitate the project success and which of these responsibilities need to be delegated to others with expertise in those areas.

• Leads negotiation with Sponsor for charter definition.

• Collaborates with Sponsor to clarify expectations.

• Provides direction to the team with integrity, leader- ship, and communication skills.

• Facilitates productive meetings and supports the team’s decisions.

• Prepares the high-level work plan and timeline.

• Champions the project on the management level and with the staff.

• Leads the implementation of the project.

• Manages project flow, including agenda setting, meeting documentation, and coordination of team assignments.

• Develops implementation, education, and commu- nication plans for the project.

• Responsible for the team and project progress and proactively intervenes to promote team and project success.

• Identifies, communicates, and facilitates the removal of barriers to enable successful project completion.

Chapter 3 Organizational Capability: Structure, Culture, and Roles 79

• Supports the team with tools and methodologies to accomplish goals.

• Facilitates collection and analysis of data.

• Leads the team in developing a plan to sustain the change and monitor effectiveness.

• Leads team in developing recommended next steps.

• Closes project with Sponsor and ensures lessons learned are captured.

• Establish with Sponsor the dates for post-project checkup and overall measurable effectiveness of project.

Performance Improvement Consultant

If the Sponsor and the Project Leader determine additional support/expertise is needed, a Performance Improvement Consultant can provide the following expertise:

• Provides direction to the Project Leader in establi- shing targets and a measurement and monitoring system.

• Mentors the Project Leader on leading the team through the project management process.

• Collaborates with the Project Leader to prepare a work plan and timeline for the project.

• Proactively intervenes to promote team and project success based on teamwork and interactions.

• Assists the Project Leader in identifying, communi- cating, and removing barriers to enable successful project completion.

• Assists in the researching of research, best prac- tices, and benchmarking.

• Coaches the Project Leader on the development and implementation of a comprehensive communication, education, and change management plan.

• Provides the Project Leader support in ensuring regular communication with the Sponsor and Stakeholders.

• Offers expertise to the team with tools and method- ologies to accomplish goals.

• Collaborates with the Project Leader on the collec- tion and analysis of data.

• Ensures a system-wide perspective is considered and downstream effects analyzed.

• Provides change management education and assists the Project Leader in developing key strate- gies for successful change management.

• Provides coaching to the Project Leader on key strat- egies for successful planning, implementation, and sustainability of the project.

Core Team Member • Takes responsibility for the success of the team.

• Attends meetings for duration of the project.

• Actively participates in team meetings.

• Understands the entire range of the project.

• Actively participates in the decision-making process.

• Supports the team’s decisions.

• Completes outside assignments.

• Carries out many of the project activities; produces deliverables on time.

• Provides testing or validation of decisions being made by the team.

• Provides data collection and reporting.

• Participates in the communication, education, implementation, and evaluation of the project.

• Gathers input from the areas they represent, if appropriate.

• Shares team decisions and plans throughout the project.

• May work directly with Stakeholders or Subject Mat- ter Experts.

Subject Matter Expert • Not a core team member of the team.

• Participates in demonstrations/presentations and/or team meetings, as needed.

• Carries out project activities as assigned; produces deliverables.

• Responsible for supplying requirements.

• Provides input to the team or complete activities based on a specific expertise he or she possesses that is essential to the project.

Source: TriHealth.

80 Part 1 Organizing Projects

CHA P T E R 4 Chartering Projects

Planning a project is similar to putting together a large puzzle. If you were to dump a 1000-piece puzzle on a table, you would probably not start the detailed “planning” right away by comparing two pieces randomly to see if they fit. You would likely take several preliminary steps. Some of these steps might include turning the pieces so the picture side was visible on each, sorting outside pieces so you could form the boundaries, studying the picture on the box, and sorting by color so you could match pieces more easily. These preliminary steps make the detailed planning of the puzzle much easier and more efficient. If completing projects is analogous to putting puzzles together, then project charters are the initial steps. Initiating a project requires some preliminary actions, including understanding the needs and concerns of stakeholders, most critically the project sponsor.

Ball Aerospace & Technologies Corp., Systems Engineering Solutions provides a wide range of air, space, and counterspace engineering and profes- sional analytic services. At Ball, we increase stakeholder buy-in by addressing

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Describe what a project charter is and why it is critical to project success. List the various elements of a charter and tell why each is used.

• Create each section of a charter for a small sample project using given project information.

• Work with a team to create a complete charter for a real project and present it to a sponsor for ratification.

• Initialize a project in MicrosoftProject and set up a milestone schedule.

© Pr es sm

as te r/S

hu tte rs to ck .c om

82

83

Topics:

• Develop project charter

• Develop schedule

• Identify risks

• Perform qualitative risk analysis

• Plan risk responses

• Identify stakeholders

PMBOK® Guide and thinking about things up front; with an agreed-upon charter, this gives the project team some guidance to effectively plan and execute the effort. In addition, by going through the chartering process, stakeholders take ownership in the project.

At Ball, our project sponsors are typically U.S. government customers, and we provide work for them on a contractual basis. They provide funding and broad direction for our efforts, and we go through a formal proposal process for all our projects. Project sponsors provide initial statements of work or objectives defining their goals for the task and then select among several proposals from interested companies such as Ball to fulfill their requirements. The chosen company is then under an official formal contract to complete the project. This is in effect a pre-chartering process.

Typically, after an effort is under contract, a kickoff meeting is scheduled to review the objectives of the project between the project sponsor and the chosen company. This is part of the initiating stage, where stakeholders review and approve the following as part of the project’s charter:

• Overall project objectives • Contrast between technical approach as written in the company’s

proposal for execution and sponsor expectations • Milestones, checkpoints, and potential payment plans • Success criteria and schedule • Identification of key stakeholders and risks • Processes for executing, monitoring, controlling, and overall manage-

ment of the project

There are a number of things to consider when initiating a project and generating a project charter. These serve as pieces of the overall puzzle of managing and executing a project. A little pre-work in initiating the project goes a long way, with increased goodwill and understanding from the project sponsor, clear tasks and goals for the project team, and a single way forward towards achieving the products and services of the project.

This chapter describes what a project sponsor, manager, and team need to understand to quickly initiate a project. The project then proceeds into planning, and the elements of a charter are planned in as much detail as needed. Chapters 5 through 11 describe project planning.

SelectingPhase:

Approval:

To Proceed

CharterSelection Kickoff

Planning Executing Closing Initiating Realizing

Project

Result

Administrative

Closure

Benefits

Realized

Lydia Lavigne, Ball Aerospace

4-1 What Is a Project Charter? For a project manager, team member, or project sponsor, one of the first and most important project management concerns is a project charter. This short document (usually about three pages) serves as an informal contract between the project team and the sponsor (who represents both senior management of the organization and the outside customer, if there is one). Since a charter is like a contract, it is helpful to remember what a contract is. First, it is an agreement entered into freely by two or more parties. Second, one party cannot arbitrarily change it. Third, there is something of value in it for each party. Finally, it is a living document that can evolve with changing conditions if both parties agree and receive something of value for making the change. The charter signing represents the transition from the high-level project initiation stage into the more detailed project planning stage. See Exhibit 4.1 for a review of the project life cycle.

The project charter is the deliverable that grants a project team (that is, the project manager and the core team) the right to continue into the more detailed planning stage of a project. This may include only permission to plan the project, permission to make decisions that would slow the project if delayed (such as ordering long-lead materials or hiring special workers), or permission to plan and perform the entire project in the case of a small, simple project. While either party (the sponsor or the project team) can write the rough draft, more often than not the team writes the draft charter. Ideally, then, the project team and the sponsor candidly discuss each part of the charter. Like a contract, the people who sign a charter are wise to ensure that they understand and agree to all of it. Unlike a contract, however, both parties feel obligated to the spirit (as opposed to the letter) of the charter since the project details have not yet been worked out and specifics will certainly change.

Thinking of a charter like a contract means that both the team and the sponsor sign the charter willingly and strive to make the project successful. If the team feels bullied into making a change, it is not a free choice. However, the sponsor may legit- imately need to insist on receiving the project results more quickly or make some other change to the project. In the spirit that one party cannot arbitrarily change a contract, the sponsor would not just tell the project team, “I need the project a month sooner and you get no more resources and no relief from any other work responsibilities.” Rather, if the project must change, the sponsor needs to consider herself or himself to be a partner with the project team in determining how to accomplish the change.

EXHIBIT 4.1 PROJECT LIFE CYCLE

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative closure

Planning Executing Closing RealizingInitiating

realizedresultTo proceed

84 Part 1 Organizing Projects

4-2 Why Is a Project Charter Used? The four major purposes for a charter are to:

1. Authorize the project manager to proceed 2. Help the project team and sponsor develop a common understanding 3. Help the project team and sponsor commit 4. Quickly screen out obviously poor projects

First, a project charter “formally authorizes the project… provides the project man- ager with authority and documents the business and customer’s needs… the new prod- uct, service, or result is intended to satisfy.”1 Many project managers do not have the authority to commit resources without a charter. This gives the project and the project manager official status within the parent organization.

Second, everyone involved in the upcoming project needs to develop a common un- derstanding of what the project entails. This includes at least the broad justification for the project, including how it aligns with goals of the parent organization, determination of what is included and excluded, rough schedule, success measures, major risks, rough estimate of resource needs, and stakeholders. On larger and more complex projects, ad- ditional understanding may be required at this point. Once everyone has a common un- derstanding of clear project goals, several additional benefits occur:

• Teamwork develops. • Agreement, trust, communication, and commitment between the sponsor, project

manager, and project team develop. • The project team does not worry if management will accept a decision. • The sponsor is less likely to unilaterally change the original agreement.2

Third, each person needs to personally and formally commit to doing their level best to achieve the agreed-upon project results—even when things do not go as planned. It is a moral duty of project team members to commit to the shared goals articulated in the charter. This formal commitment often helps a person decide to keep working hard on a project when things are not going well.

Fourth, a charter is used to quickly screen potential projects to determine which appear to be poor choices. A charter is much quicker to put together than a full, detailed project plan and schedule. If by constructing a charter it is determined that the project is likely to fail, much planning time (and therefore money) will be saved.

Remember, the charter helps all project stakeholders. Charters are often publicly shown to many individuals beyond the project team and sponsor for communication. The culture of some companies is more trusting, competitive, focused on time, preoccu- pied with details, and so on than at other companies. Therefore, charters used in differ- ent industries and companies have somewhat different elements and formats.

4-3 When Is a Charter Needed? Project methods can be scaled from very simple to very detailed. A project manager wants to use just enough detail. TriHealth has developed both full and mini charters, for large and small projects respectively. They have also developed the decision matrix shown in Exhibit 4.2 to help people determine if a full charter, mini charter, or no char- ter is needed.

Chapter 4 Chartering Projects 85

EXHIBIT 4.2 PROJECT CHARTER DECISION MATRIX

Project Name Date

When an improvement, change, or new program is going to be implemented, it is important to first determine whether or not it is a project. If it is a project, TriHealth has specific tools that should be used to guide the planning and implementation.

In general, a project is “a temporary endeavor undertaken to create a unique product, service, or result.” If your project impacts more than one department, requires expertise or resources beyond your own department, or could affect the operations in another area, the standardized templates should be used. Answering the questions below with a check will help you determine what types of tools are needed for your project. Evaluate where the majority of your checks lie and use the tools best indicated.

Resources & Little or no monies, supplies, or change in resources

& Requires moderate resources

& Requires significant and/ or additional FTEs

Multidisciplinary & 1 discipline involved/ impacted

& 2–3 disciplines involved/ impacted or more than one site

& More than 3 disciplines involved/impacted

Complexity & Little complexity & Moderate complexity; affects care delivery

& Very complex

Technology Involvement

& No technology changes

& IS consult needed & IS resources assigned

Approvals & None needed & Approval by immediate supervisor

& Executive level approval

Potential Risk Level & Minimal impact on customer

& Moderate impact on customer

& Significant impact on customer

Staff Commitment & Involvement of 2–3 people for solution

& Small team needed to generate solutions

& Requires large team of multiple departments for improvement

Communication and Education

& Simple communi- cation plan or unit based education only

& Moderate communica- tion plan; requires education across departments

& Complex communica- tion/education plan with various media

Metrics & Requires at least a one-time follow up check

& Improvement will be tracked

& Baseline and ongoing tracking of data

If the majority of your checks lie in this area:

& No charter needed & Complete a mini charter

& Complete a full project charter

Source: TriHealth.

86 Part 1 Organizing Projects

4-4 Typical Elements in a Project Charter The following sections list some of the typical key elements in a project charter. While the intent of most of these sections is included in many charters, some project teams combine sections or leave out one or two of them. Furthermore, while the term charter is a widely used standard, some organizations use other names such as project request, project submission form, or project preplanning form. As long as the four purposes of a charter (authorization, understanding, commitment, and screening) are accomplished, the exact format and title are negotiable. Typical charter elements and the question each answers are shown in Exhibit 4.3.

The charter should be short enough so that the project team and sponsor (and any other interested stakeholder) can examine it carefully to ensure they understand and agree. Two to four pages in total is generally about the right length.

4-4a Title The existence of a meaningful project title is critical. In an organization with a number of projects, the title can be used to quickly identify which project is being referenced.

4-4b Scope Overview The scope overview and business case sections are the high-level “what and why” of the project. They are sometimes considered to be the “elevator speech” that a person would use if given a very short amount of time, such as a one-floor elevator ride, to describe their project. Sometimes an additional background statement is helpful.

The scope overview is the project in a nutshell: a high-level description of what needs to be accomplished and how it will be done. What needs to be accomplished can be described as the product scope, the “features and functions that characterize a product,

EXHIBIT 4.3 CHARTER ELEMENTS AND QUESTIONS ANSWERED

CHARTER ELEMENT ANSWERS THE QUESTION

Scope overview What?

Business case Why?

Background Why?

Milestone schedule When?

Success criteria What?

Risks, assumptions, and constraints Whoa!

Resources How much?

Stakeholders Who?

Team operating principles How?

Lessons learned How?

Signatures and commitment Who?

Chapter 4 Chartering Projects 87

service or result,”3 or as requirements, each of which is a “condition or capability that is required to be present in a product, service, or result to satisfy a contract or other for- mally imposed specification.”4 How it will be done is the project scope, “work that must be performed to deliver a product, service, or result.”5 The scope overview quickly describes the project work and results. The scope overview is used to distinguish between what the project will and will not do. It is used to help prevent scope creep, which is “uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.”6 The scope overview can be considered to be the project boundaries. It states what is included and what is not—at least at a fairly high level.

Quantifying the scope, such as “15 touch points will be included,” helps everyone to better understand the project’s size. If a project could be compared to an animal, the scope overview briefly describes both the size and features so one can tell if it is a rabbit or an elephant. By understanding what is included and what is not, the project team is more likely to accurately estimate cost, resource, and schedule needs and to understand and handle project risks.

4-4c Business Case The business case is the project purpose or justification statement. It answers the ques- tion “why?” and helps all parties understand the purpose of the project. A business case is used to justify the necessity of the project. It should clearly tie the project to the orga- nization’s strategy and explain the benefits the organization hopes to achieve by autho- rizing the project. Depending on the organization, a business case can either be just the rationale for the project, or it can also include high-level estimates of the costs and ben- efits of the project. A business case may also include emotional and/or ethical reasons for performing the project. A well-written business case should persuade decision makers to support the project and inspire team members to work hard on it.

4-4d Background Many people are quite busy and prefer short statements that can be quickly read. Some project stakeholders will know enough about the project that short scope overview and business case statements will provide all of the information they need. Some other stake- holders may need more detail to understand the background behind these statements. A more detailed background statement may be helpful in these cases. Unlike the first two statements, which should be limited to about two to four sentences each, the background statement can be any length. The background statement is purely optional—only develop one if necessary.

4-4e Milestone Schedule with Acceptance Criteria The milestone schedule is “a summary-level schedule that identifies the major schedule milestones or significant points or events in the project.”7 It divides the project into a few (about three to eight) intermediate points or milestones whose completion can be verified. The team estimates a date when they expect to complete each milestone. A milestone schedule should list major milestones and deliverables that the project team especially wants to ensure are completed both on time and to the satisfaction of key de- cision makers.

A deliverable is “any unique and verifiable product, result, or capability to perform a ser- vice that is required to be produced to complete a process, phase, or project.”8 Sometimes, milestones occur right before the approval of a large expenditure. At other times, they occur at completion of a critical design. It is helpful to identify the relatively few milestones and key deliverables in the project that the team and sponsor wish to check closely.

88 Part 1 Organizing Projects

Adding a column for acceptance criteria factors to the milestone schedule helps the project team understand who will judge the quality of the deliverable associated with each milestone and what criteria will be used for that determination. Acceptance criteria are “standards, rules, or tests… by which a product, service, result, or process can be evaluated.”9

Acceptance criteria are like the project’s vital signs. A paramedic would check pulse, breathing, maybe skin color, and body temperature immediately when answering a 911 call. Other tests are not as critical and may be performed, just not immediately. It is important to identify the vital signs for the project. Project success is easy to measure after the project is complete. The equally important, but often more challenging, decision is how to measure it while the project is progressing so there is still time to make changes if necessary.

Another way to understand acceptance criteria is to understand how a key stakeholder such as the sponsor or customer is going to determine if the deliverables created are of good enough quality to accept. Since some of the milestones are often preliminary (drafts, prototypes, concepts, outlines, etc.), it is helpful to have the same person who will judge the final project deliverables judge them at the intermediate milestones. By doing this, the decision maker is much less likely to state at the end of the project, “No, that is not what I meant.” Including advance understanding of criteria is similar to the old saying that a trial lawyer never asks a question without knowing how the witness will answer. An astute proj- ect manager never turns in a deliverable without knowing how it will be judged.

One key concept in agile projects is that something of value will be delivered at each iteration. An agreement is reached during iteration planning on the “definition of done”—meaning exactly how each feature and function must perform. This is compara- ble to deliverables with acceptance criteria for each milestone as just described.

4-4f Risks, Assumptions, and Constraints A risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.”10 Assumptions are “factors in the planning purposes, that are considered to be true, real, or certain without proof or demonstration.”11 Project teams frequently identify, document, and validate assumptions as part of their planning process. Assumptions generally involve a degree of risk. A constraint is “a limiting factor that affects the execution of a project.”12

Taken together, risks, assumptions, and constraints are what could cause a project problems. They are included so that all of the key participants—sponsor, project manager, and core team—are aware in advance of what could prevent them from successfully com- pleting the project. While it is unrealistic to believe that the team can think of every single thing that could go wrong, the more comprehensive this section is, the more likely the team is to uncover problems before they occur while there is time to easily deal with them.

If an assumption turns out to be false, it becomes a risk. A constraint that limits the amount of money, time, or resources needed to successfully complete a project is also a risk. Some organizations group all risks, assumptions, and constraints together, while others handle each as a separate charter section. The most important point is not how each is handled, but that each is handled.

Project managers and teams should look at risks for three reasons. First, any negative risk that is a threat that may inhibit successful project completion (to the satisfaction of stakeholders, on time, and on budget) needs to be identified. and, if it is a major risk, a plan must be developed to overcome it. Second, a positive risk is an opportunity to complete the project better, faster, and/or at lower cost or to capitalize upon the project in additional ways, and a plan should be developed to capitalize upon it. Third, some- times there is more risk to the organization if the project is not undertaken—and this provides additional rationale for doing the project.

A G I L E

Chapter 4 Chartering Projects 89

For each major negative risk identified, an “owner” is assigned responsibility. Then one or more response plans are normally developed to either lessen the probability of the risk event from happening in the first place and/or to reduce the impact if the risk event should materialize. The goal is not to eliminate all risk, but to reduce the risk to a level that decision makers deem acceptable.

4-4g Resource Estimates Resources are “skilled human resources, equipment, services, supplies … or funds.”13

Since executives consider projects to be investments of resources, they will want a rough estimate. This can be an estimate of the amount of staff time, equipment, or materials that are in short supply, and/or the amount of money that is required. Since there is only very general understanding of the project at this point, any budget will also be ap- proximate and should be stated as such by calling it a preliminary budget and including the level of confidence one has in the estimate. This could be expressed in percentage terms (such as plus or minus 50 percent).

On some internal projects, the pay for the associates who work on the project often comprises much of the expense. Frequently, however, at least a few expenses are incurred. It is helpful to identify which expenses the project manager can authorize and which the sponsor needs to control.

4-4h Stakeholder List Project success is partially dictated by identifying and prioritizing stakeholders, man- aging robust relationships with them, and making decisions that satisfy stakeholder objectives. Therefore it is good practice to identify and prioritize stakeholders early in a project.

4-4i Team Operating Principles Team operating rules or principles are sometimes established to enhance team function- ing. The goal is to increase team effectiveness and ensure that all parties are aware of what is expected. Team operating principles that are especially useful are those that deal with conducting meetings, making decisions, accomplishing work, and treating each other with respect.

The key players of a project show their commitment to the project by signing the commitment section of the charter.

© N un o Si lv a/ iS to ck ph ot o. co m

90 Part 1 Organizing Projects

4-4j Lessons Learned While every project is unique, a great deal can be learned from the successes and failures of previous projects and turned into practical advice. Lessons learned are “the knowl- edge gained during a project which shows how project events were addressed or should be addressed in the future with the purpose of improving performance.”14 To ensure that lessons learned are used, a sponsor should only sign a charter authorizing the project to begin when at least one or two good, specific lessons from the successes and/or failures of recently completed projects are included. This essentially forces the new project man- ager and team to look at the organization’s lessons learned knowledge base to find appli- cable learnings. A lessons learned knowledge base is “a store of historical information and lessons learned about both the outcomes of previous project selection decisions and previous project performance.”15 These lessons could be stored in a dedicated database, on a shared drive, or in a less formal manner. It is important for new project teams to learn together; otherwise, they risk repeating mistakes from previous projects.

4-4k Signatures and Commitment The commitment section of the charter lists who is involved and sometimes describes the extent to which each person can make decisions and/or the expected time commitment for each person. This is where the project sponsor, project manager, and core team members publicly and personally show their commitment to the project by signing the charter. By formally committing to the project, the key players are more likely to keep working hard during difficult periods and see the project through to a successful conclusion.

4-5 Constructing a Project Charter It is wonderful if the sponsor can work with the team in constructing the charter. The sponsor, however, as a busy executive, often does not have time to be present for the entire chartering period. In that case, it is very helpful if the sponsor can create the first draft—however crude—of the scope overview and business case. A sponsor’s ability to tell the project manager and core team concisely what the project is and why it is impor- tant gets the team off to a good start. If the sponsor wants the team to consider any important constraints, assumptions, risks, or other factors, she can help the team by pointing that out up front.

Sometimes, on an especially important project, the organization’s leadership team may draft more than just the business case and scope overview statements. If the leader- ship team feels something is very important, they can save everyone time by just stating it up front. Likewise, if the sponsor knows he or she will only approve a charter with one of the elements written a particular way, he or she should tell the team that up front. Otherwise, the team most frequently writes much of the rough draft themselves.

4-5a Scope Overview and Business Case Instructions When possible, the first draft of these two sections should be provided by the sponsor or the leadership team. One to four sentences for each is enough—but it needs to be in writing. Many teams find that, because these are the “what and why” of the project, it is easier to work on them at the same time. Teams often brainstorm key ideas and then craft the parts they agree upon into smooth-flowing statements. If the sponsor provides a first draft of these sections, the project manager and core team carefully dissect it to ensure they both understand and agree. The project manager and team frequently propose refinements on the original draft.

Scope overview and business case examples are depicted in Exhibit 4.4.

Chapter 4 Chartering Projects 91

4-5b Background Instructions The project manager and team decide whether this optional section is necessary for their project as they construct the scope overview and business case. If the scope overview and business case seem detailed enough for all important stakeholders, an extra background section may not be needed. If necessary, the team probably brainstorms ideas and then combines them into a single smooth statement. An example of a background statement for a project to start a new co-op business is shown in Exhibit 4.5.

4-5c Milestone Schedule with Acceptance Criteria Instructions This section of the charter can be developed most effectively by focusing on why you are doing a project before diving into all of the details. A method of depicting all of this

EXHIBIT 4.4 SCOPE OVERVIEW AND BUSINESS CASE EXAMPLES

PHASE II MULTI-CENTER TRIAL SCOPE OVERVIEW

This project will initiate a Phase II multi-center clinical trial at Cincinnati Children’s Hospital Medical Center (CCHMC). The trial will be conducted at five medical centers in the United States to investigate the safety and efficacy of an investigational drug’s ability to improve cognitive functioning and quality of life in pediatric patients with Tuberous Sclerosis Complex. The project is a follow-up study of a Phase I clinical trial conducted at CCHMC.

ONLINE TUITION REIMBURSEMENT PROJECT SCOPE OVERVIEW

This project will design, develop, and implement an online tuition reimbursement system that will provide employees with a self- service tool to submit a request for tuition reimbursement payment. This project will incorporate a workflow process that will:

Move the request to the appropriate personnel for approval, Alert the employee of any additional items necessary for processing the request, Upon approval, send the request to payroll for final processing, and Notify the employee of payment processing.

DEVELOPMENT OF A BIOLOGICAL RESEARCH SPECIMEN SHIPPING CENTER PROJECT BUSINESS CASE

The purpose of this shipping center is to provide professional shipping services and supplies for CCHMC employees who are responsible for shipping biological specimens as part of research. This shipping center will improve compliance, streamline ship- ping processes, enhance research productivity, reduce time and money invested in employee training, and reduce potential liabil- ity for noncompliance.

ESTABLISHING A SECOND PULMONARY FUNCTION TESTING (PTF) LAB PROJECT BUSINESS CASE

An additional PTF lab will enhance patient access by:

Decreasing wait times and Providing a convenient location close to primary care appointments.

It will also improve patient outcomes by assisting in:

Diagnosis, Accurate assessment, and Chronic management of pediatric lung disease.

In addition, establishing a PFT lab will increase revenue by:

Increasing availability of PTF and Increasing community referrals for PFT.

Source: Cincinnati Children’s Hospital Medical Center.

92 Part 1 Organizing Projects

information so it is simple to understand is to set up a four-column table with Milestone, Completion Date, Stakeholder Judge, and Acceptance Criteria heading the columns. An example of a milestone schedule with acceptance criteria for a project converting to a centralized electronic record system for a major research hospital is shown in Exhibit 4.6.

SIX STEPS IN CONSTRUCTING A MILESTONE SCHEDULE The most effective way to construct the milestone schedule with acceptance criteria is to use the six-step procedure described below. Identifying the end points first (steps 1 and 2) helps project teams avoid the problem of sinking into too much detail too quickly. Note that dates are the final item to be identified. It is unethical for a project manager to agree to unrealistic dates. Even though the milestone schedule is not very detailed, it is the first time a team thinks through how the project will be performed and how long it will take at each point. This allows a bit of realism in the schedule.

Step 1 The first task is to briefly describe (in three or four words) the current situation that requires the project and place this description in the first row of the milestone column. The cur- rent state may be a shortened version of the business case. Keep it very short, and it will form an effective starting place. In Exhibit 4.6, the problem was paper records that were not centralized.

Step 2 Once the current state is agreed upon by the project manager and team, skip to the desired future state. Describe the project (or phase if there will be future phases) at its successful completion in three or four words. Put this description in the last row of the milestone column. It is hard for many core teams to distill this to the ideal three or four words, but keeping it concise helps the team develop a better understanding of what is truly most important. If the current project is a phase of a larger project, also write briefly what the final successful result of the last future stage will be. In Exhibit 4.6, the desired future state is to have records centralized and available in electronic form, and the ultimate goal is for seamless information flow throughout the organization. More work will need to be completed beyond this project to reach that ultimate goal.

Step 3 Next, describe the acceptance criteria for the final project deliverables (at the future state). What stakeholder(s) will judge the deliverables, and on what basis? Exactly how will they become confident that the project results will work as desired? These sta- keholders will almost always demand a demonstration of project results. The project team wants to understand what that demonstration will be at this early point so they can plan to achieve it. Note that there very well could be multiple stakeholders and mul- tiple methods of ensuring the project results are satisfactory. At this point, strive to iden- tify the most important stakeholders and acceptance criteria. Place these in the bottom row of the third and fourth columns. In Exhibit 4.6, the sponsor wants a representative from each department to show they can enter and retrieve pertinent data.

EXHIBIT 4.5 BACKGROUND SECTION EXAMPLE

Interfaith Business Builders is an organization of diverse Cincinnatians that develops and promotes community-based, employee-owned and -operated cooperative businesses (co-ops). Our co-ops create new jobs and ownership opportunities for low-income people in sustainable local businesses. Members of IBB come from a variety of faith and social backgrounds, share a passion for social justice and the empow- erment of people, and value community, cooperation, opportunity and solidarity. Our cooperatives are businesses that follow these seven principles: voluntary and openmembership; democratic member control; members’ economic participation; autonomy and independence; education, training and information; cooperation among cooperatives; and concern for community.

Source: Ray West, Interfaith Business Builders, Inc.

Chapter 4 Chartering Projects 93

EXHIBIT 4.6 MILESTONE SCHEDULE WITH ACCEPTANCE CRITERIA EXAMPLE

MILESTONE COMPLETION DATE STAKEHOLDER JUDGE ACCEPTANCE CRITERIA

Current state: Paper, non-centralized records

Needs assessment 28-Feb Ops management List of needed features

Hardware selection 15-Apr Ops management, CIO Hardware choice with contract

Vendor selection 30-May Ops management Vendor choice with contract

Installation and configuration 15-Jul Application specialist, IS department head

Functional software in test environment

Conversion 31-Aug Application specialist, IS department head

All files converted

Testing 15-Oct Application specialist, IS department head

Sign-off on test

Training 30-Nov Ops management, HR Sign-off on training

Future state: Electronic, centralized records

30-Nov Sponsor Ability to enter and retrieve informa- tion from all departments

;

; Ultimate goal Seamless information flow throughout organization

-- -

Step 4 Now, go back to the milestone column. Determine the few key points where qual- ity needs to be verified. On most small to medium-sized projects, approximately three to eight intermediate points are satisfactory. Start by identifying the three most important intermediate points, and add more if necessary. If you need to identify considerably more major deliverables at this point, you might consider splitting your project into phases and concentrate on the first phase for now. Satisfactory completion of each milestone will be determined by how the sponsor and other stakeholders will judge your performance. They should be in enough detail so stakeholders are comfortable with your progress, yet not so detailed that you feel micromanaged. The project in Exhibit 4.6 has four milestones.

On agile projects the first iteration is planned as a milestone with acceptance criteria just as described above. However, subsequent milestones and acceptance criteria are determined on a just-in-time (JIT) basis.

Step 5 Now for each milestone, determine who the primary stakeholder(s) is and how he or she will judge the resulting deliverable. Remember, these are intermediate deliver- ables, and often it is not as easy to determine desired performance. One idea to keep in mind—if practical, ask the person who will judge the overall project results at the end to judge the intermediate deliverables also to make sure you are on the right track. Quite a few different stakeholders will judge various milestones in the project in Exhibit 4.6.

A G I L E

94 Part 1 Organizing Projects

Step 6 Finally, determine expected completion dates for each milestone. Do not be overly optimistic or pessimistic. You will be at approximately the right level of detail if you have a milestone somewhere between every one and six weeks on many projects. Obviously, there will be exceptions for especially large or small projects. Most of the milestones in the project in Exhibit 4.6 are about six weeks apart.

Some companies that perform many projects use templates to guide their project teams through chartering and other activities. An example of a template for the mile- stone schedule and acceptance criteria for a Six Sigma project is shown in Exhibit 4.7.

4-5d Risks, Assumptions, and Constraints Instructions First, the project manager and team (and sponsor if the sponsor is available) together should brainstorm all the things that could pose a risk to the project schedule, budget, usefulness of any project deliverables, or satisfaction of any project stakeholder. Constraints that limit choices and unproven assumptions can be identified. Assumptions are especially important when a cross-functional team is performing the project because some team members may make vastly different assumptions based upon the manner in which work is normally accomplished in their respective departments. The brainstorming often works very well with each team member writing one risk, constraint, or assumption per Post-it Note. On large, complicated projects, risks, assumptions, and constraints may form separate sections of a charter. However, in this book, we deal with them together. From this point forward, all risks, assumptions, and constraints are simply referred to as risks.

Either the project manager or one of the team members can then act as a facilitator and assess one risk at a time. Risks can be assessed on probability of occurring and impact if realized. Both dimensions can be shown with a simple continuum of low to high using a flip chart or marker board. The team can agree to assess each risk at any point on the continuum. It works best if one dimension is considered at a time. For example, first ask how likely the risk event is to occur. Only after this is answered, ask how big the impact will be if it happens.

EXHIBIT 4.7 SIX SIGMA MILESTONE SCHEDULE AND ACCEPTANCE CRITERIA TEMPLATE

Milestone

Measure

Analyze

Improve

Control Future State

Current Situation Define

Acceptance Criteria

Problem in operational terms Customers and metrics identified Project schedule and assignments

Causal relationships defined Data gathering procedures approved Sufficient data gathered

Potential variables identified; Root causes statistically proven

Problem resolution ideas gathered Solution evaluated and confirmed Solution implemented

Standards, procedures, training in place

Completion Date Stakeholder

Chapter 4 Chartering Projects 95

After all risks are assessed, the team needs to decide which of the risks should be con- sidered major risks. That is, which are important enough to require a formal response plan with someone assigned responsibility? The other, more minor risks are not formally considered further in the charter, but very well may get more attention in the planning and executing stages. The project team constructs a table depicting each major risk, with its contingency plan and “owner.”

Examples of risk assessment and major risk response planning for a hardware upgrade project in an Irish factory are shown in Exhibits 4.8 and 4.9, respectively.

4-5e Resources Needed Instructions Armed with the milestone schedule, the project manager and team may be prepared to make crude estimates of the project budget and other resource needs—such as people, equipment, or space. It is imperative to describe how the estimates were developed and the level of confidence the team has in them, such as “this is a rough order of magnitude estimate only based upon the milestones, and the true project cost could range from

EXHIBIT 4.8 RISK ASSESSMENT EXAMPLE

HI

MED

LOW

LOW MED HI Impact on the project if the risk event happens

Probability that the risk event will happen

Minor risks below the line

Major risks above the line

Hardware inadequate

Associates do not have the skills to

perform key functions

Key resource not available

EXHIBIT 4.9 RISK RESPONSE PLANNING EXAMPLE

RISK EVENT RISK OWNER RISK RESPONSE PLAN(S)

Hardware inadequate Edie 1. Techs revise existing hardware 2. Replace hardware

Associates do not have skills to perform key functions Padraig

1. Train existing associates 2. Hire additional people

Key resource not available Ute 1. Identify external resources to fill need

96 Part 1 Organizing Projects

25 percent below this to 75 percent above it.” On many projects, especially those with customers internal to the organization, a budget is not established. However, a limit of spending authority for the project manager is often developed. An example of resources needed for a project is shown in Exhibit 4.10.

This project is expected to take three months. During that time, estimated resources needed include money, people, and space as shown below.

4-5f Stakeholder List Instructions Stakeholders are all the people who have an interest in a project. They can be internal or external to the organization, be for or against the project, and have an interest in the project process and/or the project results. The project manager and team begin by iden- tifying all stakeholders and determining which are most important. They next ask what interest each stakeholder has in the project. A stakeholder list example for a clinical research project is shown in Exhibit 4.11.

4-5g Team Operating Principles Instructions The project manager and team will decide what project team operating principles they will use. The operating principles establish how meetings will be conducted, how deci- sions will be made, how work will get done, and how everyone will treat each other with respect. Exhibit 4.12 is an example of team operating principles.

EXHIBIT 4.10 RESOURCES NEEDED ESTIMATE

MONEY PEOPLE SPACE

Marketing $10,000 Project Manager 0.5 FTE 1 Dedicated Conference Room

Core Team Members 1.0 FTE

AV and Communications $5,000 Internal Consultant 0.25 FTE

Miscellaneous $5,000 Data Analyst 0.25 FTE

Focus Group Participants 0.1 FTE

Total = $20,000 Full Time Equivalent (FTE) = 2.1 1 Room

EXHIBIT 4.11 STAKEHOLDER LIST EXAMPLE

STAKEHOLDER PRIORITY INTEREST IN PROJECT

Institutional Review Board Key Unexpected problems, progress

Food and Drug Administration Key Serious adverse events, progress

Site Principal Investigators Key Protocol, safety reports, changes

Pharmaceutical Company (Customer) Other Serious adverse events, progress

Research Subjects (Patients) Other Purpose of study, risks and benefits, protocol

Chapter 4 Chartering Projects 97

4-5h Lessons Learned Instructions Each project by definition is at least somewhat different from any other project. That said, there are many commonalities in how projects can be planned and managed. A project manager and team need to consider what has worked well and what has worked poorly on previous projects when starting a new one. A sponsor is wise not to sign a project charter authorizing work until the project manager and team show they have learned lessons from recently completed projects. One easy way to accomplish this is to have each project report lessons learned at key reviews and at project completion and to have the lessons available to all in a lessons learned knowledge base. The project man- ager and team can then look at the lessons until they find at least a couple that can help them on their project. These lessons are included in the charter. The more specific the lessons, the more likely the team will find them useful. Exhibit 4.13 is an example of project lessons learned.

4-5i Signatures and Commitment Instructions The project sponsor, manager, and team members sign the charter to publicly acknowl- edge their commitment. Sometimes other key stakeholders also sign. An example of a charter signature section is shown in Exhibit 4.14.

EXHIBIT 4.12 TEAM OPERATING PRINCIPLES EXAMPLE

ABC Project Team Operating Principles

1. Team members will be prepared with minutes from previous meeting, agenda, and project updates.

2. Meetings will normally last for up to 90 minutes. 3. Team members will rotate the role of recorder. 4. Each team member will be responsible for setting his or her own deadline. 5. In the event that a team member cannot have his or her assignment complete by

the expected date, he or she must notify the team leader prior to the due date. 6. The team leader will be responsible for drafting the minutes from the previous

meeting and the agenda for the next meeting within 48 hours. 7. Decisions will be made by:

Team leader on ____ issues. Consensus on ____ issues. Delegation on ____ issues.

EXHIBIT 4.13 PROJECT LESSONS LEARNED EXAMPLE

All parties are responsible for defining and following the project scope to avoid scope creep. All parties should share good and bad previous experiences. Aligning team roles to sponsor expectations is critical. Keep sponsor informed so sponsor stays committed. Identify any possible changes as soon as possible. Use weekly updates on project progress to avoid unpleasant schedule surprises. Review previous events for specific lessons.

98 Part 1 Organizing Projects

4-6 Ratifying the Project Charter The project manager and team formally present the project charter to the sponsor for approval. In some organizations, the leadership team is also present for this meeting. The sponsor (and leadership team members if present) ideally are supportive, but also ready to ask questions regarding any part of the charter. These questions are for both clarification and agreement. Once all questions are satisfactorily answered—including any agreements regarding changes—the sponsor, project manager, and core team all sign the project charter and feel bound by it.

4-7 Starting a Project using Microsoft Project A useful tool to capture and conveniently display a variety of important project data is Microsoft (MS) Project. A fully functional, 60-day demonstration copy of MS Project 2013 is included in this text. Exhibit 4.15 shows where MS Project is demonstrated in this book. Each process is described in a step-by-step fashion using screen shots from a single integrated project throughout the book.

4-7a MS Project 2013 Introduction This introduction to MS Project 2013 focuses on what is unique to MS Project relative to other Microsoft Office products. That uniqueness is driven in large part by visual and calculation conventions long in use by Project Management Professionals (PMPs). This introduction addresses those features that are visible when MS Project is started, as shown in Exhibit 4.16.

1. Ribbon—The Microsoft Project ribbon is a command bar made up of seven tabs. These tabs contain the controls (or access to controls) that are used to construct, resource, baseline, status, and communicate information about a schedule.

• The File tab includes familiar features such as open and save, but also info and options.

EXHIBIT 4.14 CHARTER SIGNATURE EXAMPLE

Anne E., Sponsor Signature Date

Signature Date

Karen H., Project Leader Signature Date

Jim B., Team Member Signature Date

Charlie H., Team Member Signature Date

Mitch N., Team Member Signature Date

Katie S., Team Member

Chapter 4 Chartering Projects 99

EXHIBIT 4.16 OVERVIEW OF MICROSOFT PROJECT 2013 GUI

Default Task Mode Selector (5)

Timeline View in the Upper Pane (2a)

Ribbon

Quick View Selector (4)

Zoom Slider (3)

Schedule Details— Lower Pane (2b)

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

EXHIBIT 4.15

CHAPTER CHAPTER TITLE MS PROCESS

4 Chartering Projects Introduce MS Project 2010; Initialize the project; Create milestone schedule

6 Scope Planning Set up the work breakdown structure (WBS)

7 Scheduling Projects Understand MS Project 2010 definitions and displays; Build the logical network diagram; Understand the critical path; Display and print schedules

8 Resourcing Projects Define resources Assign resources Identify overallocated resources Deal with overallocated resources

9 Budgeting Projects Develop bottom-up project budget; Develop summary project budget

11 Project Quality Planning and Project Kickoff

Baseline the project plan including quality gates

14 Monitoring and Controlling Projects

Report progress Review and adjust time and cost projections as needed

15 Finishing Projects and Realizing Benefits

Capture final project results

100 Part 1 Organizing Projects

• The Task, Resource, and Project ribbons provide for task, resource, and project data entry and modification.

• The Report ribbon provides standard reports as well as custom options. • The View ribbon allows selection of different views (single and combination

pane) plus tables, filters, groups, and forms. • The Format ribbon selectively displays only the formatting controls that apply to the

current active view. The Format tab header identifies the currently active view.

2. Project Schedule Information window—Below the ribbon are (one or optionally two) horizontal panes that display information about the project schedule. If a two-pane display is selected, a horizontal splitter bar divides the two panes. The bar may be dragged up or down to allocate space between the panes. Only one pane is active. A pane is activated by left clicking anywhere in the inactive pane. The active pane is marked by a bolder blue vertical band at the far left of the application window. Either the view name or the type of data is displayed in that blue band.

Customizable information formats displayed in a pane typically include:

a. Timeline—This graphic consists of a Gantt chart-like bar, which is a high-level representation of the entire duration of the schedule. Key events along the dura- tion may be marked. Parallel events may be shown stacked or as separate bars. The timeline may be displayed singly or combined with a task or resource view. If combined, it is in the upper pane.

b. Schedule Details—This is a presentation that displays the task, resource, and/or assignment data that help form a schedule. Data are entered or calculated. Data can be displayed in a table, a graphic, a timescale, or a combination of two of these. A second pane may be added, displaying either the timeline (upper pane) or a form (lower pane).

c. Zoom Slider—Found in the lower right corner on the status bar, the zoom slider is a control to quickly change the zoom level of graphical task views.

d. Quick View selector—Located in the lower right next to the zoom alider, this control provides quick access to four useful views: Gantt chart, task usage, team planner, and resource sheet.

e. Default Task Mode selector—Displayed near the left side of the status bar, this control reports the default scheduling mode (manual or automatic) for each new task. To change the default, right click the control and click the desired default setting from the list. Changing this setting will only apply to the active schedule.

4-7b Initialize Microsoft Project 2013 for General Use There are two scheduling modes in MS Project 2013: Auto Scheduled and Manually Scheduled. With Auto Scheduled selected, MS Project automatically calculates a schedule as previous versions have, using a set of schedule drivers to calculate the start and finish dates for all tasks and summaries. The Manually Scheduled mode ignores those drivers (as per option settings), instead using manually entered data. Manually Scheduled is the default for all new projects. We will now override that, making Auto Scheduled the default, but allowing individual tasks to be manually scheduled as needed. Set Auto Scheduled as the Default Task Mode, as shown in Exhibit 4.17.

1. On the File tab, Options, click Schedule. 2. On the Schedule page, Scheduling options for this project, enter All New Projects. 3. On the Schedule page, New tasks created, click Auto Scheduled. 4. Click OK.

Chapter 4 Chartering Projects 101

4-7c Initialize a Project Initializing a project has the following three steps:

1. Set the project start date. 2. Enter identifying information. 3. Automatically generate a project summary row.

STEP 1: SET THE PROJECT START DATE Set the project start date as shown in Exhibit 4.18.

1. On the Project tab, Project Information, Start date, enter “Mon 4/7/14.” 2. Click OK.

EXHIBIT 4.17 SET AUTO SCHEDULE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

EXHIBIT 4.18 SET PROJECT START DATE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

102 Part 1 Organizing Projects

STEP 2: ENTER IDENTIFYING INFORMATION Enter identifying information as shown in Exhibit 4.19.

1. On the File tab, Info, Project Information, click Advanced Properties. 2. On the Summary tab, Title box, enter your project’s name. 3. On the Summary tab, enter other information for display on reports. 4. Click OK.

STEP 3: AUTOMATICALLY GENERATE A PROJECT SUMMARY ROW MS Project can automatically generate a project summary row using the contents of the Title field (filled in step 2), as shown in Exhibit 4.20. This row represents the entire project.

1. On the File tab, Options, click Advanced. 2. On the Advanced page, click Show project summary task. 3. Click OK.

EXHIBIT 4.20 AUTOMATICALLY GENERATE SUMMARY ROW

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

EXHIBIT 4.19 ENTER IDENTIFYING INFORMATION

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 4 Chartering Projects 103

4-7d Construct a Milestone Schedule After you have set the scheduling mode to Auto Scheduled and initialized a new project, create a milestone schedule as shown in Exhibit 4.21. This will serve to capture signifi- cant deliverables as milestones in a schedule format.

1. In the Task Name cells below the Project Summary row, enter the milestone names. 2. In the Duration cells, enter a value of zero for each milestone. 3. For each milestone row:

a. Double click a field in the row to activate the Task Information dialog. b. In the Advanced tab, Constraint Type, enter Must Finish On. c. In Constraint date, enter the milestone date. d. Click OK.

The resulting milestone schedule appears as the example in Exhibit 4.22.

EXHIBIT 4.21 TASK INFORMATION DIALOG

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

EXHIBIT 4.22 ALTERNATIVE BREAKS MILESTONE SCHEDULE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

104 Part 1 Organizing Projects

Summary The project charter is a vital document since it enables the project sponsor, project manager, and core team to reach mutual understanding and agreement on the project at a high level. All parties can commit to the intent of the charter with confidence. Charters typically include sections such as a scope overview, business case, milestone schedule, acceptance criteria, risks, and signatures. Many charters include additional sections.

The sponsor or leadership team might write the rough draft of the business case and scope overview, but the project manager and core team typically write the rough draft of the majority of the charter.

Once the draft is written, the sponsor meets with the project manager and core team to go over the charter in detail both to ensure understanding and to reach agreement.

The charter, by signaling commitment on the part of the team and authorization on the part of the sponsor, is the document that completes the project initiating stage. Once the charter is complete, the project team can usually turn their attention to planning the details of the project. The first two detailed planning topics, stakeholder analysis and communication planning, are the subject of the next chapter.

Key Terms from the PMBOK® Guide product scope, 87 requirements, 88 project scope, 88 scope creep, 88 milestone schedule, 88 deliverable, 88 acceptance criteria, 89

risk, 89 assumptions, 89 constraint, 89 resources, 90 lessons learned, 91 lessons learned knowledge base, 91

Chapter Review Questions 1. What is a charter? 2. Describe what an effective charter should

accomplish. 3. How is a charter like a contract? How is it dif-

ferent from a contract? 4. How long should a typical charter be? 5. Signing the charter marks the transition between

which two project stages? 6. Who generally writes the rough draft of a charter? 7. Give three reasons for using a charter. 8. What are some typical elements of a charter? 9. What is scope creep and how can it be

prevented? 10. When would a background section be helpful?

11. On most small to medium-sized projects, how many intermediate milestones should be identi- fied in the charter?

12. What types of resources might be included in a resources needed section of a charter?

13. Name three reasons project managers and teams should look at risk.

14. Why should each contingency plan have an “owner” who is responsible for it?

15. What are the four columns of the milestone schedule?

16. What is the primary difference between “Auto” and “Manually” scheduled settings in Microsoft Project?

Discussion Questions 1. Identify the purpose of each element in a project

charter. 2. Explain how a charter helps secure both formal

and informal commitment. 3. How are risks, assumptions, and constraints

related?

4. If you are a project manager and have the choice of forming your core team before or after charter approval, which would you do and why?

5. List and describe at least four lessons you have learned from previous projects. Relate how each is valuable in planning a new project.

Chapter 4 Chartering Projects 105

6. In your opinion, what are the three most im- portant items in your project charter? How did each help you initiate your project better?

7. Give an example of how an incorrect assumption could become a risk.

8. Briefly summarize the process of creating a milestone schedule.

9. How are project scope and product scope similar and different?

10. What are the greatest advantages to using a computerized scheduling program like Microsoft Project?

PMBOK® Guide Questions 1. Which of the following is NOT a purpose of an

approved project charter? a. formally authorizes the existence of a project b. provides detailed information about financial

resources c. helps the team and sponsor develop a foun-

dational understanding of project requirements

d. provides project manager with authority to apply organizational resources to the project

2. Adding to the project after it has already begun without making adjustments to time, cost, or resources, is known as: a. scope creep b. risk c. milestones d. acceptance criteria

3. “It is inconvenient and time-consuming for employees to walk across campus every day to eat lunch, which is why we need an employee lunch room in our building” is an example of: a. project scope b. business case c. milestone schedule d. constraint

4. What information does the project charter con- tain that signifies how the customer or user of the final product, service, or result will judge the deliverables, in order to determine that they have been completed satisfactorily? a. high-level project risks b. measurable objectives and acceptance criteria c. high level project boundaries d. project assumptions

5. The project charter should include “factors that are considered tobe true, real, or certainwithoutproof or demonstration.” These are known as _____. a. risks b. assumptions c. high level requirements d. objectives

6. The signing of the project charter represents all of these EXCEPT: a. a formal acknowledgement of the sponsor’s

commitment to the project b. the formal approval of the detailed project

schedule c. authorization to transition from high-level

project initiation stage into the more detailed project planning stage

d. the organization’s commitment to apply resources to the project

7. What project charter component documents significant points or events in the project and, per the author, may be developed most effectively when combined with other information such as acceptance criteria? a. network diagram b. Gantt chart c. stakeholder management strategy d. summary milestone schedule

8. Categorize the following: “The project must be completed by November 10th”: a. risk b. assumption c. constraint d. both a constraint and a risk

9. In the project charter, the summary budget is represented as a _____? a. time-phased cost baseline b. rough order of magnitude of –25% to +75%

accuracy (these are per the PMBOK) c. definitive estimate of –5% to +10% accuracy d. management reserve

10. A project charter is _____. a. considered to be a formal contract between the

project team and sponsor b. often used as the project statement of work c. considered to be an informal agreement (con-

tract) between the project team and sponsor d. frequently used as the input to business case

creation

106 Part 1 Organizing Projects

Exercises 1. Consider a major team project for a class. Write

the scope overview and business case sections of a charter.

2. Write the business case and scope overview sections of a project charter for a project in which your com- pany is considering buying out another company.

3. You are part of a student team that is going to host a picnic-style party as a fund raiser event for a deserving local nonprofit. Develop a milestone schedule with acceptance criteria for this event. Include between four and eight milestones.

4. You are part of a student team that has volun- teered to host an alumni event at a recently reopened museum in the downtown part of your city for the twin purposes of establishing contacts with long-lost alumni and raising awareness of the newly reopened museum. Brainstorm the potential risks for this, quantify them both according to probability and impact, assign responsibility for each major risk, and create one or more contingency plans for each major risk.

5. You are part of a student team that is hosting a number of inner-city junior high and high school students from several nearby cities at your campus for a weekend. The primary pur- pose is to encourage them to attend college and secondarily to attend your college. Identify as many stakeholders as possible for this project, prioritize them, and list the interests each has in your project. You have started a project working with your peers at your rival college to create a “cross-town help-out.” You want to encourage many people in the community to contribute a day’s work on a Saturday for var- ious community projects. You have a rather heated rivalry with this other college. Create a comprehensive set of team operating principles to use on this project. Which of these principles is most important and why? Do you expect any of them to be difficult to enforce and why? What do you plan to do if some of them do not work?

Example Project Determine, one member of your student project team to be the primary contact with the project sponsor (the manager or executive who came to class on the night when projects were announced). The sponsor is also the customer representative. This sponsor was encour- aged by your professor to come with a draft of the business case and scope overview sections of the char- ter, but some sponsors probably did a better job than others. You need to ensure that you understand these statements and how they fit with the organization’s goals.

Then your student team needs to draft the remain- der of the charter with as much help as you can get from the sponsor and/or other people at the organi-

zation. Once the charter is in rough draft form, sub- mit it for comments to your professor. Armed with the professor’s suggestions, you can present it to your sponsor and any other people your sponsor chooses. Often, this may involve a leadership team, depart- ment heads (functional managers), and/or project team members. One difference on this project is that your student team will likely do most of the planning and only part of the execution, while members of the company or agency for whom you are planning the project will need to complete the execution. There- fore, you need to consider how you will transition responsibility over to the parent organization near the end of the class.

References A Guide to the Project Management Body of

Knowledge (PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, Inc., 2013).

Altwies, Diane, and Frank Reynolds, Achieve CAPM Exam Success: A Concise Study Guide and Desk Reference (Ft. Lauderdale, FL: J. Ross Publishing, 2010).

Assudani, Rashmi, and Timothy J. Kloppenborg, “Managing Stakeholders for Project Management Success: An Emergent Model of Stakeholders,” Journal of General Management 35 (3) (Spring 2010): 67–80.

Evans, James R., and William M. Lindsay, The Man- agement and Control of Quality, 8th ed. (Mason, OH: Cengage, 2011).

Chapter 4 Chartering Projects 107

Johnson, Craig E., Meeting the Ethical Challenges of Leadership (Los Angeles: Sage, 2009).

Kloppenborg, Timothy J., and Laurence J. Laning, Strategic Leadership of Portfolio and Project Management (New York: Business Expert Press, 2012).

Kloppenborg, Timothy J., and Joseph A. Petrick, Managing Project Quality (Vienna, VA: Manage- ment Concepts, Inc., 2002).

Skilton, Paul F., and Kevin J. Dooley, “The Effects of Repeat Collaboration on Creative Abrasion,” Acad- emy of Management Review 35 (1) (2010): 118–134.

Endnotes 1. PMBOK® Guide 71, 553. 2. Timothy J. Kloppenborg and Joseph A. Petrick,

Managing Project Quality (Vienna, VA: Manage- ment Concepts, Inc., 2002): 39.

3. PMBOK® Guide 553. 4. PMBOK® Guide 558. 5. PMBOK® Guide 555. 6. PMBOK® Guide 562. 7. PMBOK® Guide 546.

8. PMBOK® Guide 537. 9. PMBOK® Guide 536.

10. PMBOK® Guide 559. 11. PMBOK® Guide 529. 12. PMBOK® Guide 533. 13. PMBOK® Guide 558. 14. PMBOK® Guide 544. 15. Ibid.

PROJECT MANAGEMENT I N ACT I ON

Information Systems Enhancement Project Charter

The following charter was used when a nonprofit agency formed a project team to upgrade its information systems. Comments on the left side give advice from a

communications perspective regarding how to write a project charter, and comments on the right side offer suggestions regarding the content of each section.

108 Part 1 Organizing Projects

PROJECT CHARTER: INFORMATION SYSTEMS ENHANCEMENT PLAN

Scope Overview This team will implement a new information system based on a needs assessment of personnel of the agency. The project team will detail technological issues, as well as upward, downward, and lateral communications issues within each department and recommend software package options for each program area. The sponsor will select a vendor and the project team will oversee implementation.

Business Case—Objective The agency needs to overhaul its information systems to increase productivity for staff, and create additional learning opportunities for clients. It is estimated 20% more clients will be served with the new system.

MILESTONE

COMPLE- TION DATE

STAKE- HOLDER JUDGE

ACCEP- TANCE CRITERIA

Outdated facility, poor productivity

Start 1/6/14

Staff survey 1/31/14 Sponsor Discussion with department heads

Software recom- mendations

3/14/14 Operations Manager

All areas included, pilot results

Vendor selected

3/28/14 Sponsor Best meets qualifications

Technology in place

5/9/14 Project Manager

System test demonstration

Updated facility, productivity improved

5/30/14 Sponsor Two-week data reports from department heads

DESIGN PRINCIPLES

Headings:

Headings facilitate scan- ning by identifying infor- mation covered in each section.

Heading descriptions should accurately indicate the information that follows.

Lists:

Listing techniques help readers remember key details of a message.

Numbers, bullets, and other ordering devices promote retention and improve visual design.

Lists are best limited to five points so they do not look overwhelming to readers.

Lists are written in parallel structure, with the first word of each item having the same grammatical form, such as all nouns, all verbs, or all -ing words.

CONTENT PRINCIPLES

Scope Overview:

The scope overview defines the major deliverables. It sets project boundaries by clarifying what is included and, sometimes, what is not included.

Business Case:

The business case defines project objectives and why they are important to the parent organization.

Milestone Schedule:

The milestone schedule shows the project starting point, a few major milestones, and the ending point.

Acceptance Criteria Factors:

These identify which stakeholder will judge the acceptability of each mile- stone and what criteria they will use.

Chapter 4 Chartering Projects 109

DESIGN PRINCIPLES

Tables: Use tables to organize com- plex information into an easy-to-follow column and row format.

Design tables so they make sense when read indepen- dently of the text.

Use table headings that reflect logical groupings of information.

Phrase column language so it is in parallel structure.

Character Formatting: Use character formatting, including boldface, italics, underlines, and centering to highlight headings.

Use character formatting hierarchically. Boldface, underlines, and all caps are best for major headings. Use fewer or less dramatic tech- niques for subheadings.

Type Size and Face: Use 9, 10, 11, or 12 point type for most documents. Near-sighted readers prefer larger type.

Use a conventional typeface, such as Arial, Times Roman, or Palatino.

White Space: Use white space to separate document sections attrac- tively and to improve read- ability.

Page Breaks: When possible, complete entire sections on the same page. Redesign documents where one or two lines of text from a section run onto the next page.

Major Risks

Resources Needed This project will require the project manager to spend 50% of her time and the lead user and 3 core team members 25% of their time for 5 months. The budget estimate is $45,000.

Stakeholder List

STAKEHOLDER INTEREST IN PROJECT

Board Sponsor Department Heads

Overall cost and overall project success Overall project success, resource needs; Impact on their department, resource needs

Lead user New work methods, productivity increases

RISK RISK OWNER RESPONSE PLANS

System may not work properly)

Technical lead Define top defect and focus exclusively on until fixed.

Implementa- tion may cost too much

Accountant Identify areas of cost reduction and added funding.

Lack of sponsor buy-in

Project Manager

1. Conduct staff survey to identify most needed capabilities.

2. Understand sponsor requirements.

CONTENT PRINCIPLES

Project Risks and Assumptions: This section identifies major risks and how the team will either reduce their probabil- ity of happening and/or their impact if they do occur. One person is assigned respon- sibility for each risk.

Resources Needed: This is an estimate of the money, personnel, and other resources expected to be needed.

Stakeholder List: Identifies those individuals and groups who have an interest in either the project process and/or results.

110 Part 1 Organizing Projects

Team Operating Principles

_ Commitment to timetable. The project managementteam members will complete their assigned work on time.

_ Regularly scheduled project team and sponsorshipmeetings. Project team meetings will be held every Saturday at 4:15 p.m. The team will also communicate via e-mail as required. Sponsorship meetings with the agency staff will be held bimonthly and as-needed.

_ Timely communication. The project management teamwill communicate status, issues, and questions with agency via e-mail or conference call weekly. Project actions will be distributed to the team every Monday.

_ Majority rule. The project management team willnegotiate and resolve issues on a majority-rule basis. Lessons Learned

_ Agreeing on project scope is a key preliminary projectplanning activity. _ Maintaining project goals and timeline requires opencommunication and quick issue resolution. _ Understanding roles and responsibilities facilitatessmooth teamwork and timely project completion. Commitment

Sponsor Project Manager

Lead User Core Team Member

Core Team Member Core Team Member

CONTENT PRINCIPLES

Operating Principles: Operating principles indi- cates agreement on dead- lines, meetings, decision making, and how partici- pants will treat each other with respect.

Lessons Learned: This section highlights spe- cific learnings from previous similar projects that will help the team copy good prac- tices and avoid problems.

Commitment: Project principals signal agreement in principle to the project, recognizing that some of the specifics will probably change when the detailed planning is complete.

DESIGN PRINCIPLES

Sentences: To express complex ideas effectively and to make ideas easy for readers to understand, compose most sentences to be 15–25 words long.

Simple Language: So all readers understand your language easily, substitute short, action- oriented, easily under- stood words for long, unfamiliar, and unpro- nounceable words.

Chapter 4 Chartering Projects 111

PART2 PLANNING PROJECTS organize / plan / perform

Chapter 5 Stakeholder Analysis and Communication Planning

Chapter 6 Scope Planning

Chapter 7 Scheduling Projects

Chapter 8 Resourcing Projects

Chapter 9 Budgeting Projects

Chapter 10 Project Risk Planning

Chapter 11 Project Quality Planning and Project Kickoff

113

CHA P T E R 5 Stakeholder Analysis and Communication Planning

Humans are social animals that engage with each other in complex ways, especially in artificial environments such as organizations and projects. Inexperienced project managers can become buried in the control of the project plan’s tactical aspects and miss the more strategic components like stakeholder engagement and effective communication. Ultimately, successful delivery of a project is about both managing the tangible outputs (which are generally easily and objectively measured) and leading others through the more strategic and intangible outcomes. Traditionally, measures of success focus on scope, time, cost, and quality to determine the success of the project as an entity. However, a more accurate measure of success also considers the longer-term outcomes delivered by what your project stimulated to happen after it was complete.

For example, the Sydney Opera House was a disaster as a project, but it made highly significant contributions to the culture, identity, meaning, and belonging of the Australian nation well beyond being a failed project, and there

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Enumerate, describe, and prioritize each set of stakeholders for a project.

• Tell how to build project relationships and why they are important for communications.

• Enumerate each section of a project communications plan and describe the role each plays.

• Develop a project communications management plan for a real project.

• Plan, conduct, and improve project meetings.

• Describe communication challenges of virtual and global project teams.

© M on ke y Bu si ne ss

Im ag es /S hu tte rs to ck .c om

114

Topics:

• Develop project management plan

• Identify stakeholders

• Plan stakeholder management

• Develop project team

• Manage stakeholder engagement

• Plan communications management

• Virtual teams

are many other examples like this in human history. Equally, there are project successes that only make negative contributions to society. This is because your stakeholders have varying perceptions of what the worth of the project.

Stakeholders and your communications with them, are highly subjective aspects of projects and more difficult to manage than the tangibles mentioned earlier. However, these aspects are often not managed with anywhere near the time and thought investment of the tangibles. This does not mean that every

PMBOK® Guide

SelectingPhase:

Approval:

To Proceed

CharterSelection Kickoff

Planning Executing Closing Initiating Realizing

Project

Result

Administrative

Closure

Benefits

Realized

115

© Ar th ur

Sh el le y

© Ar th ur

Sh el le y

projectmanager needs tobecomeaskilledwordsmith andapsychologist (although this would in fact be a very useful set of skills for a PM to have). The PMBOK is now starting to build more content around these aspects of leading and managing projects, and there is increasing literature acknowledging the importance of the “soft skills” required to be a successful project manager. Capable project managers invest effort to create and maintain informed stakeholder engagement matrices and insightful communications plans. They know whom to engage at what stage of the project (including critical stakeholders BEFORE the project starts at times), at what frequency, and through what medium to secure optimal results. They then implement this plan and adjust as circumstances change.

One effective and fun way a PM can accelerate the development of their stakeholder engagement and communication skills is to use metaphor refle- ctions developed by Arthur Shelley. This approach uses animals to represent behaviors and stimulate constructive conversations about interactions between people. The Organizational Zoo describes a set of 27 characters that collectively represent the most common behaviors in the Zoo (that is, your team, project, organization, or community). They are easy to remember (one for each letter of the alphabet, plus one “double”), and the cartoon characters help to make the conversation fun. Team members profile themselves and their stakeholders in order to understand what they are like and how they should engage with them. Because we all have considerable prior knowledge of animals, understanding is intuitive, and the tool makes it easy to quickly assess our behavioral environments. It is clear a mouse does not approach a lion in the same way it would approach dog, and a lion leader is different from an eagle.

In projects, the use of creative tools such as metaphor and reflective conversations is becoming more common and makes a significant contribution to success and the learning experiences of those involved. The free on-line profiler can be used for project team activities and to discover more about your own inner animals.

www.organizationalzoo.com/profiler Copyright Arthur Shelley 2013

Image artist John Szabo

5-1 Develop the Project Management Plan Chapters 2 and 3 of this book discuss organizational issues such as strategic planning, project selection, and roles of key individuals. Chapter 4 details how to initiate a project—usually by composing and ratifying a charter. This chapter bridges initiating and planning. Exhibit 5.1 shows the process flow of getting a project started. Everything through the process “Identify Stakeholders” is part of initiating projects, while “Plan Stakeholder Management and Plan Communications Management” consists of planning processes.

Because each project is unique, a project team needs to plan specifically for each proj- ect. While the details of each plan will differ, projects have many issues in common that must be planned. For example, all projects are undertaken to achieve a purpose. This means that a set of stakeholders wants the project results and that the results have scope of work and quality considerations. All projects are subject to cost and scheduling con- straints and are accomplished with and through people and other resources. The

116 Part 2 Planning Projects

planning for people includes both determination of who will work on the project and how they will develop effective team and stakeholder relationships.

As stated in Chapter 1, project management is integrative, iterative, and collaborative. Project planning must integrate the 10 knowledge areas described in the PMBOK®

Guide into a single project management plan. Develop project management plan is “the process of defining, preparing, and coordinating all subsidiary plans and integrating them into a comprehensive project management plan.”1 Project planning is iterative in that one starts by planning at a high level and then repeats the planning in greater detail as more information becomes available. Project planning is collaborative since there are many stakeholders to be satisfied and a team of workers with various skills and ideas who need to work together. For ease of understanding, in this book planning has been divided into chapters, but a team cannot complete all the planning in a chapter- by-chapter manner. Decisions made in planning one function will often require revisions in another. For example, if the proposed schedule is too slow, perhaps a client will authorize the use of overtime pay, which will probably increase the budget.

Effective project planning lays the groundwork for effective project execution, moni- toring, control, and closeout. Developing effective team and stakeholder relationships leads to a foundation of respect and trust, which, in turn, leads to project success, as dis- played in Exhibit 5.2. Thus, during project planning, details of the various functions need

EXHIBIT 5.2 DETERMINANTS OF PROJECT SUCCESS

Project Success

Relationship Building Activities

Respect and Trust

Project Planning Activities

Effective Execution, Monitoring, Control

and Close-out

EXHIBIT 5.1 PROJECT SELECTION, PRIORITIZATION, AND INITIATION

Elevator Pitch

Select & Prioritize Projects (Ch. 2)

Develop Project Charter (Ch. 4)

Identify Stakeholders (Ch. 5)

Plan Stakeholder Management & Communications Management (Ch. 5)

Draft Scope Overview & Business Case, Project Priority

Signed Project Charter

Stakeholder Register Stakeholders

Management Plan & Communication Management Plan

Chapter 5 Stakeholder Analysis and Communication Planning 117

to be planned, and the groundwork needs to be established for effective team and stake- holder relationships.

Projects vary tremendously in size and complexity. Therefore, project management planning can vary from filling out a few simple templates to completing many detailed forms and hosting multiple facilitated meetings. When a project team is trying to decide how detailed the planning needs to be, the team members need to remember that the purpose of the project management plan is to become a basis for executing, monitoring, controlling, and closing all project work. It is wise to spend $100 in planning to save $1,000 in execution, but not the other way around.

A project team develops a variety of plans for communications, schedules, budgets, and so forth. They need to ensure these various plans all fit together into one unified project plan. Typically, a good way to begin planning is to develop the outline of a proj- ect management plan, which is “the document that describes how the project will be executed, monitored, and controlled.”2 At this point, whatever documentation was devel- oped in the process of initiating the project can be used.

Since both relationship building and detailed planning of the various project functions need to occur simultaneously, our coverage will start with a type of planning that does both. Plan stakeholder management is “the process of developing appropriate manage- ment strategies to effectively engage stakeholders throughout the project life cycle, based on the analysis of their needs, interests, and potential impact on project success.”3 Plan communications management is “the process of developing an appropriate approach and plan for project communications based on stakeholders’ information needs and requirements and available organizational assets.”4

In this book, project management plans include stakeholders, communications, scope, schedule, budget, resources, risks, and quality. While much of the planning is iterative, we first discuss an understanding of project stakeholders—everyone who has an interest in the process of performing the project work; in using the project deliverables; or who can influence the project. Once a team understands who has an interest in or can exert influence over their project, they can develop a communications management plan, which is “a component of the project management plan that describes how, when, and by whom information about the project will be administered and distributed.”5 After the communications management plan, the project team will determine the scope. Once the scope is determined, the project team can plan other aspects of the project, such as:

• Schedule • Budget • Resources needs • Risks • Quality

Some of these issues impact others, so the team develops the project management plan to ensure that all of these subsidiary plans work effectively together. One final and important thing to remember is that the project management plan, once formally approved, can only be updated and revised by formally approved changes. Many projects have changes identified when the project is well underway and require replanning throughout the project life cycle.

Agile and other forms of adaptive planning will not create nearly as much initial plan- ning, but will have much of the planning occur on a just-in-time (JIT) basis.

A G I L E

118 Part 2 Planning Projects

5-2 Identify Stakeholders Projects are undertaken because someone needs the project’s output. A project must sat- isfy its users to be successful. Several things can complicate this. First, there may be mul- tiple users, and each may have different wants and needs. Second, often users do not fully understand what they want because they do not know what alternatives may be available. Third, the customer who pays for the project may not be the actual person or group who uses the result, and the customer may not fully understand the users’ needs. Fourth, when someone else is paying for the project, some users will ask for many proj- ect outcomes that are expensive or time consuming to deliver. Finally, many stakeholders in addition to the users of a project’s outcomes have an interest in the project. Project managers need to first understand their stakeholders, build relationships with them, and then develop a communications management plan for dealing with them.

5-2a Find Stakeholders One way to understand who stakeholders are is to ask, “Who will use or be affected by the result of a project?” The answer includes users of the project results and others who may have some changes forced upon them by the project. Identify stakeholders is “the process of identifying the people, groups, or organizations who could impact or be impacted by a decision, activity, or outcome of the project; and analyzing and document- ing relevant information regarding their interests, involvement, interdependencies, influ- ence, and potential impact on project success.”6 Stakeholders include people who:

• Work on the project • Provide people or resources for the project • Have their routines disrupted by the project

Another way to identify stakeholders is to determine whether they are internal to the organization performing the project or external to it. Examples of project stakeholders based on these categories are shown in Exhibit 5.3. Note that there are potentially more

EXHIBIT 5.3 EXAMPLES OF PROJECT STAKEHOLDERS

INTERNAL EXTERNAL

Affected by Project Process Owner Sponsor Project Manager Functional Managers Competing Projects Financing Source Project Core Team Subject Matter Experts Employees Stockholders

Suppliers Partners Creditors Government Agencies Special Interest Groups Neighbors Client Professional Groups Media Taxpayers Union Competitors

Affected by Project Result Internal Customer Sponsor Users

Client Public Special Interest Groups

Chapter 5 Stakeholder Analysis and Communication Planning 119

types of stakeholders affected by the process of performing the project than by the proj- ect results and more external than internal stakeholders.

Project managers and project core teams (often in consultation with their sponsor) can use the examples in Exhibit 5.3 to find possible project stakeholders. This can be conducted as a brainstorming session. Classic rules of brainstorming apply—initially, the emphasis is on generating a long list of potential stakeholders in the first column of a chart. It may be easiest to construct this chart on a large work surface such as a white board or flip chart. Another suggestion is to be specific; identify stakeholders by name when possible.

For each potential stakeholder, list the various project processes and results in which he or she might have an interest. Consider both financial and emotional interests of potential stakeholders. The project charter can be useful here. Many stakeholders have an interest in multiple aspects of a project. Once the stakeholders and their interests have been listed, they may be combined into like groups with the same interests.

5-2b Analyze Stakeholders Stakeholder analysis is “systematically gathering and analyzing quantitative and qualita- tive information to determine whose interests should be taken into account throughout the project.”7 The first part of stakeholder analysis is to prioritize the stakeholders. Prioritization is important because on many projects there are too many stakeholders to spend a great deal of time with each. While it is important not to ignore any stake- holder, it also makes sense to concentrate on those who are most vital. Stakeholders can be prioritized based upon level of:

1. Authority (power) 2. Concern (interest) 3. Active involvement (interest) 4. Ability to affect changes (impact) 5. Need for immediate influence (urgency) or 6. Appropriateness of their involvement (legitimacy).8

Many project teams will use two or three of these. Each aspect used can be rated on a simple scale of 1 to 3, with 3 representing the highest priority. For the first aspect, power, a stakeholder who could order the project shut down or changed in a major way would be a 3, and a stakeholder who could not change the project much would be a 1. The other aspects can be analyzed in the same way. The scores from the aspects are added to form a total prioritization score. Exhibit 5.4 shows this stakeholder identification and prioritization.

By determining who the stakeholders are and what each group wants, project man- agers effectively:

• Set clear direction for further project planning, negotiating, and execution • Prioritize among competing objectives • Learn to recognize complex tradeoffs and the consequences of each • Make and facilitate necessary decisions • Develop a shared sense of risk • Build a strong relationship with their customers • Lead associates, customers, and suppliers with an empowering style • Serve as good stewards of the resources of both the parent and customer organizations

The project team should next select the top 10 to 15 stakeholders for emphasis in the remainder of their planning. The stakeholders with the highest total scores are often

120 Part 2 Planning Projects

considered to be key influencers for the project. The project manager and core team should also plan to periodically review this prioritized list of stakeholders, as the relative im- portance may change as the project progresses, especially if the project goals are not clear at the outset.

One additional consideration is that various stakeholders often have competing interests. For example, the client may want the work done quickly while the accoun- tant is worried about cash flow. Exhibit 5.5 itemizes how different types of stake- holders frequently define project success. Another consideration is that the project was selected to support a specific business purpose and that purpose should help determine the relative importance of various stakeholders. Typically, when a conflict exists, external paying customers and top management are considered to be highly important stakeholders. If the project team developed the stakeholder identification and prioritization matrix without their sponsor, now would be a good time to share it with the sponsor and ask for feedback. Chances are good the sponsor will want to make some adjustments before the team continues. Sponsors are especially useful in helping to sort out conflicting priorities. The project team primarily considers these top stakeholders while they:

• Develop a communications plan (see next section) • Scope the project (see Chapter 6) • Identify threats and opportunities (see Chapter 10) • Determine quality standards (see Chapter 11) • Prioritize among cost, schedule, scope, and quality objectives (see Chapter 11)

5-2c Document Stakeholders The primary output of the “identify stakeholders” process is a stakeholder register. The stakeholder register is “a project document including the identification, assessment, and

EXHIBIT 5.4 STAKEHOLDER IDENTIFICATION AND PRIORITIZATION MATRIX

STAKEHOLDER: STAKEHOLDER: STAKEHOLDER: STAKEHOLDER:

WHAT IS IMPORTANT TO THIS STAKE-HOLDER

POWER

INTEREST

INFLUENCE

IMPACT

URGENCY

LEGITIMACY

TOTAL:

PRIORITY (KEY OR OTHER):

Chapter 5 Stakeholder Analysis and Communication Planning 121

E X H IB

IT 5 .5

S U C C E S S

C R IT

E R IA

F O R

V A R IO

U S

S T A K E H O L D E R S

ST A K E H O LD

E R /

SU C C E SS

C R IT E R IA

O N

T IM

E O N

B U D G E T

M E E T

R E Q U IR

E -

M E N T S

P A R T N E R

SH IP

P R O FI T

R E A LI Z E D

FO LL

O W -

O N

W O R K

M IN

IM A L

O V E R T IM

E R E C O -

G N IT IO

N C H A LL

E N G E

W E LL

- P A ID

Q U A LI T Y

C us to m er

X X

X X

X

E n d us er

X X

X X

X

C us to m er

m an

ag em

en t

X X

X X

X X

X

P ro je ct

m an

ag er

X X

X X

X X

X X

X X

C on

tr ac to r

m an

ag em

en t

X X

X X

X X

X X

P ro je ct

te am

m em

be r

X X

X X

X X

X X

X

Su bc on

tr ac to r

X X

X X

X X

X X

So ur ce :A

da pt ed

fr om

R al ph

R .Y

ou ng ,S te ve n M .B

ra dy

an d D en ni s C .N

ag le ,J r. ,H

ow to

Sa ve

a Fa

ili ng

Pr oj ec t: C ha os

to C on tr ol (V

ie nn

a, V A :M

an ag em

en tC

on ce pt s, 20 09 ): 14 .©

20 09

by M an ag em

en tC

on ce pt s, In c.

A ll ri gh ts re se rv ed ,w

w w .m

an ag em

en tc on

ce pt s. co m /p ub

s.

122 Part 2 Planning Projects

classification of project stakeholders.”9 Teams use it to develop strategies to either capi- talize upon stakeholder support or to mitigate the impact of their resistance. The stake- holder register serves as input to relationship building with each stakeholder and helps determine their requirements, which is the basis of developing project scope. The stake- holder register is a living document that changes as needed. A stakeholder matrix for the alternative breaks example project is shown in Exhibit 5.6.

5-3 Build Relationships Project managers and teams seek to develop strong working relationships with important stakeholders. This is an ongoing process throughout the life of the project. In fact, the project manager normally continues to nurture the relationship even after the project is completed to increase the chances of securing future project work. In building relationships both within the project core team and with other stakeholders, project managers need to remember that mutual respect and trust greatly enhance the prospect of project success. Therefore, relationship-building activities that lead to respect and trust should be planned and carried out carefully.

A principle idea in agile is that relationships with stakeholders need to be based upon collaboration, communication, and trust. Analyzing stakeholder information helps the team understand them better and leads to effective relationship building.

A G I L E

EXHIBIT 5.6 ALTERNATIVE BREAKS PROJECT STAKEHOLDER MATRIX

STAKEHOLDER INTEREST IN PROJECT PRIORITY

SUPPORT/MITIGATION STRATEGIES

Students Going on trip Key Support and guide through process

VP Student Affairs Success for division Key Share and publicize “wins”

Executive Director of Faith and Justice

Success for faith and justice Key Share and publicize “wins,” keep informed of progress

Board Success for board and students

Key Constant improvement

Families Monetary support, worry about student

Other Help students guide families through process

Community organizations We support them Other Constant communication

Advisor Success for board, students, and advisor

Other Constant improvement

Winter break trip Learn from alternative breaks

Other Remain in contact, share strategies

National Organization Break Away 2-way sharing Other Continue current relationship

Source: Chris Bridges.

Chapter 5 Stakeholder Analysis and Communication Planning 123

Typically, relationship building activities are most effective when they are used in the process of planning a project. Project relationship-building activities that are described more fully below and are especially useful include the following:

• Share individual motives. • Encourage open communication. • Jointly establish agendas. • Use shared learning. • Regularly celebrate success. • Share enjoyment of project. • Use appropriate decision making and problem solving.10

5-3a Relationship Building within the Core Team Project sponsors andmanagers who wish to create highly productive workplaces ensure that core team members understand what is expected of them, have the chance to do work they are well- suited to perform, receive appropriate recognition, have good coworkers, have their opinions con- sidered, and have opportunities to grow and develop.11 The sponsor and the project manager ide- ally begin by asking one another about personal expectations from the project. Each may have project goals such as certain specific capabilities in the project deliverables. Both the project man- ager and sponsor may have individual motives also. It is helpful to acknowledge these personal goals to each other. The project manager, in turn, asks each core team member what he or she personally wants from involvement in the project. These conversations not only help the project manager understand priorities, but also motivations. For example, core teammembers may want to participate in a stimulating experience, gain skill, or earn a promotion. Understanding these motivations will make it easier for the project manager to address them.

The project manager can encourage open communication by keeping people informed, showing that everyone’s input is valued, personally sharing feelings, and respecting confidenti- ality. She should set the expectation that all team members also practice these habits.

Joint establishment of project meeting agendas helps with relationship building because all team members feel their concerns are addressed, and they develop a greater sense of ownership in meetings. When members get to share in meaningful project learning, they feel their judgment is valued. Frequent celebration of small successes helps project team members share the enjoyment of working on a project, which in turn helps them stay committed to successful project completion.

One other key relationship-building activity that needs to start early and continue throughout the project concerns appropriate decision making and problem solving. The project manager and core team need to understand who makes each type of project decision and how each is made. One consideration is that people involved in making decisions tend to better support them. Decisions made by groups tend to take longer, and projects are often pushed for time. Some decisions are best made by a single expert, while others are best made by a group that represents various points of view. Each proj- ect team will need to determine who will make which types of decisions. Exhibit 5.7 gives general advice that can be applied in making this determination.

5-3b Relationship Building with All Other Stakeholders Establishing a positive relationship early on with all key stakeholders is vital for two rea- sons. First, it helps create a desire on the part of stakeholders to give positive support to the project, or at least refrain from disrupting the project. Second, it serves as the com- munications foundation for the project. The remainder of the project planning and exe- cution are greatly enhanced by effective communications channels with key project stakeholders.

124 Part 2 Planning Projects

Project teams create a stakeholder management plan that is “a subsidiary plan of the project management plan that defines the processes, procedures, tools, and techni- ques to effectively engage stakeholders in project decisions and execution based on the analysis of their needs, interests, and potential impact.”12 A primary tool used in this plan is the stakeholder engagement matrix. Engagement levels can be classified as unaware, resistant, neutral, supportive, or leading.13 Exhibit 5.8 is an example showing both where each stakeholder is currently (C) and where the team desires the stake- holder to be (D).

The sponsor, project manager, and core team can establish powerful relationships with key stakeholders by delivering on all promises, always providing fair treatment, creating a sense of pride by association, and even helping the stakeholder develop a passion for the project.14 This starts by learning what motivates each stakeholder. The old saying “What is in it for me?” describes what each stakeholder wants, and that is what the project team needs to understand. Stakeholders who feel threatened can disrupt a project during its process and are less likely to perceive that they receive project benefits in the end. Unhappy stakeholders are a sign of project failure. On the other hand, stakeholders can be treated as partners right from the start of planning by the project team speaking their language and providing them opportu- nity to participate. These stakeholders are more likely to take ownership in the proj- ect by educating the project team about their needs and making timely project decisions and, in turn, are more likely to feel their expectations match the project

EXHIBIT 5.7 PROJECT DECISION-MAKING GUIDE

PERSON/METHOD WHEN

Sponsor decides Critical decision, large monetary stake, “big picture” needed

Project manager decides Time is critical, no need for other input

Functional manager decides “How” functional work is done

Core team discusses and project manager decides Team input is useful

Core team consensus Buy-in is critical

Delegated to one or two team members to recommend Needs to be investigated, team input useful

Delegated to one or two team members to decide Needs to be investigated, team input not needed

EXHIBIT 5.8 STAKEHOLDER ENGAGEMENT ASSESSMENT MATRIX

STAKEHOLDER UNAWARE RESISTANT NEUTRAL SUPPORTIVE LEADING

Volunteers C D

Information Services C D

Referral Center C D

Legal Services C D

Registration Staff C D

Chapter 5 Stakeholder Analysis and Communication Planning 125

team’s plans. They are more likely to go beyond merely inspecting results and writing checks. They may participate early and often when their input is meaningful and they feel that the project is successful. All of the other project relationship-building activi- ties listed previously can be applied in a similar fashion to that described for the core team in the previous section. The important thing for project managers to remember is that developing respect and trust among all project stakeholders is a goal that must be started early and continued throughout the project. This is just as critical to proj- ect success as the more technical planning and should also demand attention from project managers.

5-4 Plan Communications Management The project team should next create the communications management plan. This plan guides the project communications and needs to be a living document that adapts to changing project needs.

5-4a Purposes of a Project Communications Plan Projects have many challenges, including technical, cost, and schedule difficulties. Failure to manage any of these well can throw off a project. Another very common challenge to project success is communication. Many projects require people to work together who have not done so before. Projects may involve people from various functional areas that all have their own unique challenges. People from multiple companies may end up working together on projects. All projects are unique and therefore have different sets of stakeholders. “Communication leads to cooperation, which leads to coordination, which leads to project harmony, which leads to project success.”15

5-4b Communications Plan Considerations A myriad of considerations must be kept in mind when creating a communications plan. A project team can develop a workable com- munications plan, use it, and improve it as the project progresses. Some factors that Fiesta® San Antonio organizers considered when creating a project communication plan are shown in Exhibit 5.9. These factors apply to all project communications. There-

fore, we discuss these factors first and then explain who the project team needs informa- tion from and to whom they need to supply information.

PURPOSE COLUMN The first column in Exhibit 5.10 instructs a project team to con- sider the purpose for each communication. If there is no good use for the communication, it makes no sense to develop it. A project manager must use effective communications to set and manage expectations from all stakeholders as well as to ensure that project work is completed properly and on time. Communications from stakeholders are necessary in authorizing work, determining requirements, uncovering and resolving issues, and receiv- ing feedback on project progress and results. Different stakeholders often have conflicting desires; effective communications are necessary to understand and resolve these differences. Communications to stakeholders are necessary to help them make good decisions (by understanding options and risks), assure them of adequate understanding and progress, enable them to more fully commit to the project, and be ready to accept project

Yearly medals to celebrate Fiesta® San Antonio.

© In st itu te

of Te xa n Cu ltu re s

126 Part 2 Planning Projects

EXHIBIT 5.9 FIESTA SAN ANTONIO COMMUNICATION PLAN NEEDS

In August 2012, the Institute of Texan Cultures, a museum specializing in Texas culture and diversity, forged a partnership with the Fiesta® San Antonio Commission to produce a series of exhibitions showcasing the traditions of Fiesta®, San Antonio’s premiere festival. Fiesta® is an annual 10-day fes- tival of over 100 events and 5 large parades. The festival draws 3.5 million visitors. It is tradition for Fiesta® events to commission new medals each year to give to event-goers to wear and trade through- out the festival.

The museum’s leadership team convened with the Fiesta® San Antonio Commission’s executive director at the end of August to assemble a project management plan. The parties identified stake- holders who would be impacted by the project. They prioritized stakeholders by influence, and divided responsibilities for developing and maintaining relationships with each of those stakeholders.

The following challenges were anticipated:

• It would take time for the 120 Participating Member Organizations (PMOs) to reach their members and assemble a full collection of medals to loan to the museum.

• Some PMOs might be offended if their medals were not displayed more prominently than other PMOs.

• The museum would be engaging the same PMOs to support future exhibitions, so it was critical to maintain positive relationships.

It was clear that a comprehensive communications plan would need to be implemented to establish lines of communication, nurture relationships, and manage the flow of information between stakeholders.

Source: Aaron Parks, Institute of Texan Cultures

EXHIBIT 5.10 PROJECT COMMUNICATIONS PLAN CONSIDERATIONS

PURPOSES STRUCTURES METHODS TIMING

Authorization

Direction setting

Information seeking

Status reporting:

Schedule

Cost

People

Risk

Issues

Quality

Change control

Approval of project outputs

Escalation

Lessons learned

Existing organizational forms (reuse)

Project specific:

Templates (adapt)

Unique (create)

Push methods:

Instant messaging

E-mail

Voice mail

Fax

Pull methods:

Shared document repositories

Intranet

Blog (repository)

Bulletin boards

Interactive methods:

Telephone—teleconferencing

Wikis

VOIP/videoconferencing

Groupware

Project life cycle

Charter

Project plan

Milestones

Output acceptance

Project close-out

Routine time

Daily—member

Weekly—core team

Monthly—sponsor

As needed—others

Chapter 5 Stakeholder Analysis and Communication Planning 127

deliverables. Yet another communication purpose is to plan and manage escalation of is- sues that cannot be handled in a timely manner by the project manager. Wise project managers determine in advance how soon an issue will be raised to the sponsor and/or other decision makers. Finally, communications plans ensure that at project conclusion, meaningful lessons can be documented to benefit future projects.

A project manager develops trust with her core team and other stakeholders partly by using open communications to the extent possible. However, she needs to respect all promises of confidentiality and to use good judgment on what is or is not appropriate to share.

STRUCTURES COLUMN The second column suggests that if there are existing organi- zational communication structures, use them! There is no need to reinvent every docu- ment and, indeed, it would be confusing and costly to do so. Many stakeholders in organizations are accustomed to a particular method of communications, and using that method will make it easier for them to understand you. When no exact organiza- tional model is available to follow for a particular communication, one can use a tem- plate, which is still easier than creating an entirely new type of document.

Using any of the three choices, project teams need to maintain version control on all of their communications. One easy method is to end the file name of every document with six numbers representing year, year, month, month, and day, day. For example, an early version of this chapter was saved on April 4, 2013, and the file name given was “Chapter 5 Stakeholder Analysis and Communication Planning 130404.” The advantage of a simple system is that the files can still be easily found by their descriptive named titles, but they can also be sorted easily by the last date they were updated.

METHODS COLUMN The third column in Exhibit 5.10 deals with methods of commu- nicating. Projects rely on “push” methods in which communications are sent or pushed; “pull” methods where communications are posted either on paper or in electronic form and interested stakeholders need to take the initiative to receive the communication; and interactive methods in which communications flow in multiple directions. A typical proj- ect communication plan will utilize a variety of these methods.

TIMING COLUMN The fourth column is a reminder that a project team needs to con- sider timing issues when developing a project communications plan. Communications typically are delivered according to one of three types of timing schedules. First is the project life cycle, with communications typically needed at the end of each major stage in the project and at the end of each major project deliverable. The second timing sched- ule follows a more formal organizational structure. Project progress is often reported at regularly scheduled meetings. Meetings at the frontline level are usually more frequent than reports to higher levels within the organization. The third timing scheme is an as-needed basis. Many times, a stakeholder wants to know a certain fact about a project and cannot wait until the next formal meeting or report. Project teams need to keep themselves up to date so they can handle the as-needed requests.

5-4c Communications Matrix At this point, project teams will normally assemble a project communications matrix. This matrix lists the following information:

Who does the project team need to learn from?

What does the team need to learn from this stakeholder?

Who does the project team need to share with?

128 Part 2 Planning Projects

What does this stakeholder need to know?

When do they need to know it?

What is the most effective communications method for this stakeholder to understand?

Who on the project team is responsible for this communication? (the owner)

An example of a completed project communications matrix is shown in Exhibit 5.11. The communications needs of each project are unique, and, therefore, the assignment of communications responsibilities will vary widely from project to project.

Stakeholders want to know how much work has been successfully delivered (accep- tance tests passed) and how much work is remaining. Team members use the informa- tion in specific and detailed formats to improve and motivate. Sponsors use the information to strategically understand if the project will complete all work on time and budget. Other stakeholders may share the sponsors’ overall concern, but want details of work that concerns their function. While these communication needs are common on all projects, agile projects have unique reports such as velocity, burn down charts, run- ning tested features, and earned business value.16

5-4d Knowledge Management If a company does extensive project work and uses project management capability as an organizational strength, it is important to keep developing expertise in it. One way to develop and expand expertise is to capture and reuse the knowledge developed. Knowl- edge is “a conclusion drawn from information after it is linked to other information and

A G I L E

EXHIBIT 5.11 ALTERNATIVE BREAKS PROJECT COMMUNICATIONS MATRIX

STAKEHOLDER LEARN FROM SHARE WITH TIMING METHOD OWNER

Student Needs Education, reflection

Bi-weekly and as needed

Meetings, test, e-mail

Board, site coordinators

Families Concerns Plan and study info

At start, before, and during trip

Student AB website

Student and advisor

Community organizations

Education, needs Our plans and needs

At start, before, and during trip

Phone Site coordinators

VP Student Affairs Definition of success

“Wins” At start and at “wins”

E-mail Advisor

Executive Director of Faith and Justice

Definition of success

“Wins” and progress

At start, at wins, and monthly

E-mail and meetings

Advisor

Advisor University needs and strategic outlook

Progress, needs Almost daily E-mail and meetings

Board

National Organization Break Away

Summer student training, Listserv info

Forms, methods, daily guidelines

At start and monthly

E-mail Chair and advisor

Source: Chris Bridges.

Chapter 5 Stakeholder Analysis and Communication Planning 129

compared to what is already known.”17 To increase knowledge and the successful use and reapplication of it, organizations often create a lessons learned knowledge base. For this database to be useful, it is important to communicate project successes and failures from all aspects of the project process. Captured throughout the life of the project, recommendations to improve future performance can be based on technical, managerial, and process aspects of the project. In addition, part of the project closeout process should include facilitating a lessons learned session for the entire project, especially on unsuccessful projects.

5-5 Project Meeting Management Planning and conducting projects require a variety of meetings, such as meetings to:

• Establish project plans • Conduct the project activities • Verify progress • Make decisions • Accept deliverables • Close out projects

Meetings are an important process on projects since many important decisions are made at meetings and much time of expensive project personnel is invested in meetings.

One common feature of agile projects is the “stand-up meeting.” These short (15 minute or less) meetings are often held at the start of each day with no coffee or chairs to be comfortable. Each project team member briefly states what she accom- plished the previous day, what she plans to accomplish this day, and what obstacles may challenge her.

5-5a Improving Project Meetings Project meetings should be conducted in as efficient and effective a manner as possible. One way to improve the project meeting process is to apply the simple and effective plan-do-check-act (PDCA) model.

PDCA MODEL The idea behind process improvement with the PDCA is that any pro- cess practiced repeatedly, focusing on reusing and adapting things that worked well and avoiding things that did not work well, improves over time. Exhibit 5.12 depicts the PDCA model as it is applied to project meetings.

PROJECT MEETING AGENDA TEMPLATE When applying the PDCA improvement model specifically to improving project meetings, the first step is planning the proj- ect meeting in advance. The project manager makes sure that the agenda is pre- pared and distributed ahead of time. If a project team is meeting often, this advance agenda preparation may be done at the end of one meeting for the next meeting. That way, everyone understands beforehand what will be covered in the upcoming meeting and has the opportunity to be prepared. The agenda also can be helpful in deciding whether to invite a particular subject matter expert (SME) or other guest to the meeting. A project meeting agenda template is shown in Exhibit 5.13.

The top part of the agenda contains meeting logistics. The second item on the tem- plate asks for the meeting purpose. If a project manager cannot state in a sentence why he wants to conduct a meeting, perhaps the meeting is not necessary. The main body of the agenda has three columns. First is a list of the topics. This starts with a quick review

A G I L E

130 Part 2 Planning Projects

of the agenda, because projects often move quickly, and this provides an opportunity to add or delete an item from the agenda. The major topics of the meeting are listed next in the order in which they will be covered. Often, remaining items from previous meetings or other urgent matters top the list. However, a project manager wants to be sure to cover the most important matters, even if they may not have the same sense of urgency. The second-to-the-last item on the standard agenda is the meeting summary. The project manager summarizes major decisions that were made as well as work assignments that were distributed. This helps people remember what they agreed to do. The final item on the agenda is an evaluation of the meeting. This is explained in the check step of the PDCA model.

EXHIBIT 5.12 PDCA MODEL APPLIED TO PROJECT MEETINGS

The Meeting

Cycle

Plan: prepare advance agenda

Do: conduct meeting, write minutes

Check: evaluate meeting

Act: perform in-between

meeting tasks

Source: Adapted from Timothy J. Kloppenborg and Joseph A. Petrick, “Meeting Management and Group Character Development,” Journal of Managerial Issues (Summer 1999): 168–172.

EXHIBIT 5.13 PROJECT MEETING AGENDA TEMPLATE

Project Team PlaceTimeDate

PURPOSE:

Topic

Review agenda

Summary

Meeting evaluation

Person Time

2 min

2 min

5 min

Chapter 5 Stakeholder Analysis and Communication Planning 131

The second column lists the person responsible for each topic on the agenda. Typi- cally, the project manager takes care of the meeting start and close, but individual project team members may be assigned specific action items. When people know in advance that they are responsible for an action item, they are more likely to be prepared Additionally, if the advance agenda is available for key stakeholders to see, some of the stakeholders may contact the responsible person in advance to provide input. This is a good way to keep stakeholders engaged.

The third column is a time estimate for each item. While the project manager does not need to be a slave to the clock, recognition of how long team members are in meet- ings and how many items are accomplished goes a long way. People are more likely to attend a meeting if they are sure it will end on time.

PROJECT MEETING MINUTES TEMPLATE The second step in the PDCA process—“do”—means to conduct the meeting and to capture minutes as the meeting is conducted. Many project teams rotate the role of minutes taker so each team member feels equal. A template for taking project minutes is shown in Exhibit 5.14.

5-5b Issues Management The project minutes mirror the agenda to the extent that both refer to the same meeting. The top part of the minutes form is logistics, just as in the agenda. The four primary types of information captured in a project meeting are:

1. Decisions made 2. New issues surfaced and old issues resolved 3. Action items agreed to 4. An evaluation of the meeting

EXHIBIT 5.14 PROJECT MEETING MINUTES TEMPLATE

Decisions Made:

Issues Log: Resolved Issues

New Issues

Action Item Person Responsible Completion Date

Meeting Evaluation

Project Team TimeDate

Members present:

132 Part 2 Planning Projects

DECISIONS AND ISSUES First, any decisions that were made should be documented. Second, any new issues that surfaced or existing issues that were resolved should be recorded. An issue is “a point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.”18 An issues log is “a project document used to document and monitor elements under discussion or in dispute between project stakeholders.”19 Issues logs ben- efit a project in at least two ways. First, when an important issue—but not one that can be solved in the immediate meeting—is introduced, the project manager can add it to the open issues and not spend time on it in the current meeting when more pressing matters need to be settled. Second, the issues log ensures that important issues are not forgotten. An issues log template is shown in Exhibit 5.15.

ACTION ITEMS The third type of project information is action items. Each of these is a task that one or more members of the project team agree to perform by a specific date. These are recorded, and the project manager reminds the team at the end of each meet- ing what each member agreed to do.

EVALUATION The final item to be recorded on the project meeting minutes is an eval- uation of both good points from the project meeting that the team would like to repeat or at least adapt and poor points from the meeting that the team would like to avoid in the future. An experienced team can collect these points in a minute or two; the time they save in future meetings often pays great dividends. An easy way to capture these evaluations is a Plus-Delta template as shown in Exhibit 5.16.

EXHIBIT 5.15 PROJECT ISSUES LOG

OPEN ISSUES

NAME DATE OPENED ORIGINATOR POTENTIAL IMPACT

PROGRESS

CLOSED ISSUES

NAME DATE OPENED ORIGINATOR HOW RESOLVED DATE CLOSED

Chapter 5 Stakeholder Analysis and Communication Planning 133

On agile projects this evaluation is called retrospectives. When assessing the project meeting with a Plus-Delta method, a project manager

can simply draw the form on a flip chart or marker board. Then, each person is asked to offer his opinion on at least one thing that either was good (+) that he would like to see repeated or one thing that was poor (A) that kept the team back somehow and he would like to see overcome in future meetings. The key to making this work for the project manager is how she responds to any deltas. If the project manager responds defensively, the team members may not want to offer further suggestions.

Finally, the “act” part of the PDCA cycle for project meetings is for every team member to complete the action items they promised and for the project manager to communicate with the team members to make sure nothing is holding them back from their commitments. Wise project managers keep active but informal contact with team members between meetings to ensure action items are completed on time. When all steps of the PDCA cycle are applied to project meetings, the meet- ings improve; the team members gain satisfaction; and the project makes better progress.

5-6 Communications Needs of Global and Virtual Project Teams

As organizations change more rapidly, more projects are started with team members from various parts of the larger organization, from various organizations, and even from various parts of the world. These project teams certainly have the advantage of uti- lizing talent from a wide pool of resources. Project team members often enjoy greater autonomy and stimulation on these teams.

5-6a Virtual Teams These advantages, however, come with added challenges. Since the team is not all co-located, the project manager relies even more on persuasion than usual to accom- plish work. In contemporary project management, project managers use less onerous command and control than they might have a few years ago. This trend is even truer with global and virtual teams. A virtual team is “a group of people with a shared

EXHIBIT 5.16 PROJECT MEETING PLUS-DELTA EVALUATION TEMPLATE

A G I L E

134 Part 2 Planning Projects

goal who fulfill their roles with little or no time spent meeting face to face.”20 When project teams operate in a virtual mode, many of the following characteristics are present:

• Team members are physically dispersed. • Time boundaries are crossed. • Communication technologies are used.

Cultural, organizational, age, gender, and functional diversity is present.21

5-6b Cultural Differences Cultural patterns differ in various parts of the world so project team members need to be more sensitive to how their actions are interpreted. For example, in some cul- tures looking a person in the eye signifies you are paying close attention, while in other parts of the world people may look slightly downward in deference to author- ity. In those cultures, looking a person in the eye might be considered a challenge. When people do not have face-to-face contact, they do not have the opportunity to see and learn from a person’s body language. Project managers working with global and virtual project teams need to be especially mindful of the increased need for communications using methods other than face to face. The various methods regard- ing charter development described in Chapter 4, along with stakeholder analysis and communications planning in this chapter, are even more critical on virtual and global teams. The more unusual a team is, the more critical charters and communi- cations vehicles become. Exhibit 5.17 lists some of the extra communications chal- lenges posed by virtual and global project teams. Note that each project management need has a specific increased challenge—for example, the third need, relationship building, needs more time since people do not have the advantage of full face-to-face communication. Project managers and teams can enhance stakeholder satisfaction by learning the cultural ethics and values of all their stakeholders, work- ing hard to establish trust, and ensuring that they use fast and reliable information systems.

5-6c Countries and Project Communication Preferences It is helpful if the project team members can meet each other face to face even one time. While this can be very expensive, it may be much less expensive than not per- forming well on the project. Sometimes, the core project team is assembled to write

EXHIBIT 5.17 INCREASED CHALLENGES FOR VIRTUAL AND GLOBAL PROJECT TEAM

PROJECT MANAGEMENT NEED INCREASED CHALLENGES

1. Initiate project 1. More unique project needs

2. Understand stakeholders 2. More difficult to understand

3. Build relationships 3. Needs more time

4. Determine communications needs and methods 4. More unique needs, more reliance on electronic means

5. Establish change control 5. More facilitating than directing

6. Manage the meeting process 6. Less nonverbal clues, interest may wander

7. Control issues 7. With less group interaction, harder to identify

Chapter 5 Stakeholder Analysis and Communication Planning 135

and approve the project charter. The core team members then know each other and are inclined to give each other the benefit of doubt if there is a misunderstanding. Another method that is frequently used is to confirm meetings and calls with quick meeting minutes or e-mail follow-ups. By documenting decisions, it is easier to remember what happened and to uncover lessons learned when the project is complete.

While abundant differences occur between people from various countries, the method and timing of project communications are of interest here. For example, Mueller and Turner studied how cultural differences impact preferred modes of project management communication.22 They examined how collectivism versus indi- vidualism, along with the extent individuals in various cultures accept unequal power and ambiguity, impact project communications preferences. The results show that country preferences can be shown in four categories with common pre- ferences on frequency and type of communications for each group, as shown in Exhibit 5.18.

5-7 Communications Technologies Perhaps one of the most exciting and rapidly changing aspects of project management work is communications technologies. When the author first worked on projects in the 1970s, carbon copies were used extensively, careful printing was practiced so as to not mistake a number in a calculation, bidders on construction contracts needed to physically drive to a plans room to view plans and specifications so they could bid on upcoming projects, and people would proof contracts and letters multiple times since there were no spell checkers.

5-7a Current Technology Types Current Technology TypesProject team members and other stakeholders need to be able to respond to each other wherever they are. They need to be able to work creatively together, have access to project documentation, and yet protect confidentiality and version control. One important consideration to keep in mind is that communications technology should make the project easier—not harder. Do not select the most current technology for its own sake. Select whatever technology will help get the job done. Newer communication technologies enable team members to work effectively from increasingly remote locations.

EXHIBIT 5.18 COUNTRIES AND PROJECT COMMUNICATION PREFERENCES

COUNTRY GROUP PREFERENCES

1. Japan, Taiwan, and Brazil 1. Face-to-face, analytical at milestones

2. Hungary and India 2. Written status reports, float intervals

3. The Netherlands and Germany 3. Detailed progress reports, float intervals

4. Australia, United States, Canada, New Zealand, United Kingdom, and Sweden

4. Continuous phone updates, with written backup

Source: Adapted from Ralf Mueller and J. Rodney Turner, “Cultural Differences in Project Owner–Project Manager Communications,” Innovations Project Management Research 2004 (Newtown Square, PA: Project Management Institute, 2004): 412–414.

136 Part 2 Planning Projects

Summary This is the first chapter on project planning. After com- pleting project initiation by writing and ratifying a charter, a project team turns to planning. Planning is iterative on projects. While there is a logical order to planning, many times information that is developed while planning one function causes a project team to modify earlier planning. Nevertheless, it makes sense to start planning by identifying and analyzing the stakeholders.

Projects frequently have many diverse stakeholders. Some stakeholders do not know exactly what they want, and different stakeholders sometimes want dif- ferent things. The project manager and sponsor need to build effective working relationships with the project team and stakeholders. When good relationships are built and maintained, the project team can enjoy the trust that is so helpful in successfully completing the project.

Armed with the stakeholder analysis and the project charter, a project team is ready to create a communica- tions management plan. One important component of this plan is the communications matrix. This is the document that answers the questions:

• Who needs to know something about the project? • What does each need to know? • When do they need to know it?

• What format is easiest for them to receive and understand the information?

• Who is responsible for sending it?

Other important aspects of a project communica- tions management plan include managing and improv- ing meetings; managing and escalating issues; and capturing and using lessons learned.

Many project teams work as virtual teams at least part of the time. Some project teams have members who are in various parts of the world. Virtual and global teams share heightened communications chal- lenges since they often cannot physically meet. Global project management teams have the additional chal- lenge of working with different cultures where meth- ods of communicating may vary considerably. These added challenges reinforce the need for understand- ing stakeholders well and effectively planning project communications. Communications technology is changing rapidly, and many applications can work well for virtual and global project teams. The project manager needs to carefully select the technologies used so they help and do not pose added challenges. Once stakeholders and communications are planned, the project team can plan scope, schedule, resources, budget, risks, and quality—the topics of the next six chapters.

Key Terms from the PMBOK® Guide develop project management plan, 117 project management plan, 118 Plan stakeholder management, 118 plan communications management, 118 communications management plan, 118 identify stakeholders, 119

stakeholder analysis, 120 stakeholder register, 122 stakeholder management plan, 125 issue, 132 issues log, 132 virtual team, 135

Chapter Review Questions 1. List three reasons why understanding stake-

holders is important to successful project management.

2. What is the difference between an internal and external stakeholder?

3. Which three criteria should you consider when prioritizing stakeholders?

4. When should relationship building between the project manager/other core team members and important stakeholders occur?

5. What are some ways to build relationships within the core team?

6. What are some ways to build relationships with key stakeholders?

7. What are some important functions of commu- nication from stakeholders?

8. What are some important functions of commu- nication to stakeholders?

9. What is the difference between “push” and “pull” methods of communication?

Chapter 5 Stakeholder Analysis and Communication Planning 137

10. What are three types of project communications timing schedules?

11. What six columns should a communications matrix contain?

12. Why is it so important to capture lessons learned in a knowledge database?

13. List the items that go into a project team meeting agenda and tell the purpose of each.

14. Describe an AGILE “stand-up” meeting. 15. List and describe the four main types of infor-

mation captured in project meaning minutes. 16. What is a virtual team? 17. Name three increased challenges for global and/

or virtual teams. 18. Why is it helpful for a virtual team to meet in

person at least once?

Discussion Questions 1. A new grocery store is being erected, which will

demolish a neighborhood basketball court. Who would be some internal stakeholders? Who would be some external stakeholders?

2. Think of a recent project you completed and choose three stakeholders. Prioritize them, using the six-criteria model.

3. In your opinion, what is the single most impor- tant component of building relationships within a project team? Why?

4. In your opinion, what is the greatest benefit of having good communication between the project team and project stakeholders? Why?

5. Imagine you are the project manager of a team tasked with building a new hotel. When brainstorming project communication plan con- siderations, what would you list under “purposes”?

6. Using the same scenario as question 5, which timing schedule would you choose to use for each communication? Why?

7. Create a project meeting agenda for an upcoming project (or class) meeting you have.

8. Betty, a project manager, sent out agendas before an upcoming meeting to everyone involved. Dur- ing the meeting, she got a team member to take minutes. After the meeting, Betty followed up with team members to check on their progress. Evalu- ate Betty’s actions using the PDCA model. What, if anything, could she have done better?

9. You are working for a multinational organization and need to relay information to Japan. Which communication method would you choose to use and why?

10. Give as many examples of cultural differences as you can, using information from this text and your own experiences.

PMBOK® Guide Questions 1. The “component of the project management plan

that describes how project communications will be planned, structured, monitored, and con- trolled“ is the: a. communication model b. communications management plan c. stakeholder register d. organizational breakdown structure

2. In order for a new grocery store to be erected, a neighborhood basketball court located on the building site will have to be demolished. The neighborhood children who liked to play basketball there could be considered as _________. a. subject matter experts b. internal stakeholders c. external stakeholders d. customers

3. According to the PMBOK® Guide, stakeholders can be prioritized by their potential impact on the project based on a determination of all of the factors below EXCEPT: a. level of authority b. level of concern c. active involvement d. political connections

4. The components of a project communications management plan should typically include the purpose of the communication, structure (for- mat, content etc.), methods or technologies to be used, and _____________: a. work performance data b. time frame and frequency c. stakeholder priorities d. lessons learned

138 Part 2 Planning Projects

5. Which of these is NOT a challenge of working on global and virtual teams? a. competencies b. language c. time zones d. culture

6. Most project meetings are formal, planned events between project stakeholders. Effective meetings typically have a purpose, a pre- arranged time and place, a list of attendees and their roles, and an agenda with topics and issues to be discussed. After the meeting, _____________ are circulated. a. refreshments b. business cards c. meeting minutes d. lessons learned

7. The “project document that includes the identification, assessment, and classification of project stakeholders” is called the _____________. a. stakeholder engagement matrix b. organizational breakdown structure c. stakeholder register d. weighted scoring model

8. Inadequate communications planning may endanger the success of the project. Which of

these could be a problem resulting from poor communications planning? a. communication to the wrong audience b. delay in message delivery c. misinterpretation of the message

communicated d. all of the above could be problems

9. One of the key responsibilities of a project man- ager is to manage stakeholder expectations. It is important for the project manager to have interpersonal or “soft” skills that include: over- coming resistance to change, resolving conflict, active listening and _____________. a. displaying confidence b. subject matter expertise c. ability to command and control d. building trust

10. The communication method that is used for large audiences or large volumes of information and requires recipients to access the content at their own discretion, is called _____________ communication. a. push b. pull c. synchronous d. interactive

Example Project Do each of the following for your project.

• Develop a stakeholder analysis. Identify as many stakeholders as you can using Exhibit 5.3. List stakeholders by name and title where possible.

• Prioritize the listed stakeholders as shown in Exhibit 5.4.

• Specifically identify each stakeholder’s interests as shown in Exhibit 5.6. Recognize that some stake- holders may have an interest in multiple aspects of the project process or results.

• Describe the activities you are using to build rela- tionships both within your core team and with other stakeholders.

• Create a project decision-making guide like Exhibit 5.7. List specific examples of decisions to the extent you can.

• Create a stakeholder engagement matrix like Exhibit 5.8.

• Develop a communications matrix like Exhibit 5.9. Be sure to use considerations in Exhibit 5.8 for ideas regarding purpose, structures, methods, and timing for each communications need.

• Document a project meeting with an advance agenda, meeting minutes, issues log, and Plus-Delta form of evaluation like Exhibits 5.12 through 5.15.

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Alderton, Matt, “What’s Your Number?” PMNetwork 26 (12) (December 2012): 48–53.

Anantatmula, Vittal, and Michael Thomas, “Managing Global Projects: A Structured Approach for Better

Chapter 5 Stakeholder Analysis and Communication Planning 139

Performance,” Project Management Journal 41 (2) (April 2010): 60–72.

Assudani, Rashmi, and Timothy J. Kloppenborg “Managing Stakeholders for Project Management Success: An Emergent Model of Stakeholders,” Journal of General Management 35 (3) (Spring 2010): 67–80.

Badiru, Adedeji B., Triple C Model of Project Manage- ment: Communication, Cooperation, and Coordina- tion (Boca Raton, FL: CRC Press, 2008).

Bourne, Lynda, and Derek H. T. Walker, “Visualizing Stakeholder Influence: Two Australian Examples,” Project Management Journal 37 (1) (March 2006): 5–21.

Chicchio, Francois, “Project Team Performance: A Study in Electronic Task and Coordination Com- munication,” Project Management Journal 38 (1) (March 2007): 97–109.

Daft, Richard L., Management, 9th ed. Management, 9th ed. (Mason, OH: South-Western Cengage Learning, 2010).

Englund, Randall L., and Alfonso Bucero, Project Spon- sorship: Achieving Management Commitment for Project Success (San Francisco, CA: Jossey-Bass, 2006).

Fleming, John H., and Jim Asplund, Human Sigma (New York: Gallup Press, 2007).

Goodpasture, John C., Project Management the Agile Way: Making It Work in the Enterprise (Fort Lau- derdale, FL: J. Ross Publishing, 2010).

Hass, Kathleen B., From Analyst to Leader: Elevating the Role of the Business Analyst (Vienna, VA: Man- agement Concepts, 2008).

Herzog, Valerie Lynn, “Trust Building on Corporate Project Teams,” Project Management Journal 32 (1) (March 2001): 28–35.

Hollinsworth, Chauncey, “PMPs on FB? OMG!” PMNetwork 24 (3) (March 2010): 41–46.

Kloppenborg, Timothy J., and Joseph A. Petrick, “Leadership in Project Life Cycles and Team Character Development,” Project Management Journal 30 (2) (June 1999): 8–13.

Kloppenborg, Timothy J., and Joseph A. Petrick, “Meeting Management and Group Character

Development,” Journal of Managerial Issues (Summer 1999): 140–159.

Montoya, Mitzi M., Anne P. Massey, Yu-Ting Caisy Hung, and C. Brad Crisp, “Can You Hear Me Now? Communication in Virtual Product Development Teams,” Journal of Product Innovation Management 26 (2009): 139–155.

Montoya, Mitzi M., Anne P. Massey, and Vijay Khatri, “Connecting IT Services Operations to Services Marketing Practices,” Journal of Management Information Systems 26 (4) (Spring 2010): 65–85.

Mueller, Ralf, and J. Rodney Turner, “Cultural Differ- ences in Project Owner–Project Manager Commu- nications,” Innovations Project Management Research 2004 (Newtown Square, PA: Project Management Institute, 2004): 403–418.

Patanakul, Peerasit, Bookiart Iewwongcharien, and Dragan Milosevic, “An Empirical Study of the Use of Project Management Tools and Techniques across Project Life-Cycle and Their Impact on Project Success,” Journal of General Management 35 (3) (Spring 2010): 41–65.

Reed, April H., and Linda V. Knight, “Effect of a Virtual Project Team Environment on Communication-Related Project Risk,” Interna- tional Journal of Project Management 28 (5) (July 2010): 422–477.

Schlenkrich, Lara, and Christopher Upfold, “A Guide- line for Virtual Team Managers: The Key to Effec- tive Social Interaction and Communication,” Electronic Journal Information Systems Evaluation 12 (1) (2009): 109–118.

The Standard for Program Management, 3rd ed. (Newtown Square, PA: Project Management Insti- tute, 2013).

Thomas, Dominic M., and Robert P. Bostrom, “Vital Signs for Virtual Teams: An Empirically Developed Trigger Model for Technology Adaptation Inter- ventions,” MIS Quarterly 34 (1) (March 2010): 114–142.

Young, R. Ralph, Steven M. Brady, and Dennis C. Nagle, Jr. How to Save a Failing Project: Chaos to Control (Vienna, VA: Management Concepts, 2009).

Endnotes 1. PMBOK® Guide 537. 2. PMBOK® Guide 554. 3. PMBOK® Guide 550. 4. PMBOK® Guide 549.

5. PMBOK® Guide 532. 6. PMBOK® Guide 543. 7. PMBOK® Guide 563. 8. PMBOK® Guide 396.

140 Part 2 Planning Projects

9. PMBOK® Guide 563. 10. Lynda Bourne and Derek H. T. Walker, “Visualiz-

ing Stakeholder Influence: Two Australian Exam- ples,” Project Management Journal 37 (1) (March 2006): 5–21.

11. Adapted from Valerie Lynn Herzog, “Trust Build- ing on Corporate Project Teams,” Project Manage- ment Journal 32 (1) (March 2001): 33–34; and Timothy J. Kloppenborg and Joseph A. Petrick, “Leadership in Project Life Cycles and Team Char- acter Development,” Project Management Journal 30 (2) (June 1999): 11.

12. PMBOK® Guide 563. 13. PMBOK® Guide 402. 14. Adapted from John H. Fleming and Jim Asplund,

Human Sigma (New York: Gallup Press, 2007): 97. 15. Adedeji B. Badiru, Triple C Model of Project Man-

agement: Communication, Cooperation, and Coor- dination (Boca Raton, FL: CRC Press, 2008): 29.

16. Matt Alderton, “What’s Your Number?” PMNet- work 26 (12) (December 2012): 48–53.

17. Richard L. Daft, Management, 9th ed. (Mason, OH: South-Western Cengage Learning, 2010): 631.

18. PMBOK® Guide 544. 19. PMBOK® Guide 544. 20. PMBOK® Guide 271. 21. Adapted from Lara Schlenkrich and Christopher

Upfold, “A Guideline for Virtual Team Managers: The Key to Effective Social Interaction and Com- munication,” Electronic Journal of Information Sys- tems Evaluation 12 (1) (2009): 110.

22. Ralf Mueller and J. Rodney Turner, “Cultural Dif- ferences in Project Owner–Project Manager Com- munications,” Innovations Project Management Research 2004 (Newtown Square, PA: Project Man- agement Institute, 2004): 403–418.

PROJECT MANAGEMENT I N ACT I ON

Project Communication Planning for a Distributed Project

During an IT rollout of servers, clients, networking equipment, and a central data center involving a range of subcontractors at each of the roughly 50 regional schools the original communication plan showed:

Original communication plan

Project

Main contractor

Subcontractor 1

Subcontractor 2

Subcontractor N

School 1

School 2

School N

Joint edu association or

administration union

Chapter 5 Stakeholder Analysis and Communication Planning 141

PROJECT MANAGEMENT I N ACT I ON

First of all two on-site visits at each location were introduced in order to

1. get to know the location and the people involved and

2. make sure all environmental preconditions agreed upon had been properly set up.

For each location there were between 5 and 20 people involved who all needed special information (depending on their role) thus multiplying the planned effort of communication considerably. However, the still early discovery of the complex stakeholder situation also facilitated a degree of fast- tracking and intensifying the cooperation, which was essential to finalize the project in quality, time, and budget, despite several buffer-consuming events, with very favorable media coverage and proper project close, which otherwise would have been impossible.

Apart from the headmaster and IT teacher, what other roles did we “discover”?

• All teachers whose class rooms were involved (re- ceiving equipment, have to move/exchange furni- ture, rearrange the room).

• Caretaker (usually the one who knew about walls, wires, changes to the building, and the construction history where there were no drawings available).

• Owner of the building (community, private owner, society).

• Sponsor for each individual school (who had to agree to a detailed plan and a float sum of money. This was quite a topic since originally it was thought that a float lump sum ofmoney could be spent on the whole proj- ect moving money between sites according to need. The need differed greatly since a newly build school (concrete/steel) poses a whole different range of tasks as compared to 150-year-old converted castle schools with thick walls (think of wireless LAN, think of “pro- tection of historical monuments” = no drilling of holes anywhere and a long analysis and certificates for every little change to the building, think of moist or even wet intended server locations).

• The schools all had preferred local partners for elec- tricity (dedicated electrical phases for 19”server, power supply and network equipment, ideally dry and ventilated and cool, usually a small moist place with no air flow at all like a broom closet of the Harry Potter type in Privet Drive).

After being appointed PM for rollout and implementation I noticed that this was far from enough and needed to be amended.

Revised communication plan

Project

Subproj 1

Subproj 2

Subproj 50

Joint edu association or

administration union

School 1

School 2

School N

Team Team

Team

Team

Team

Team

Team

Team

Team

Co re

te am

Main contractor (bundling crafts and trades)

Subcontractor 1

Subcontractor 2

Subcontractor N

142 Part 2 Planning Projects

• Structural fire protection authority (they had serious words for the people who suggested drilling through a bulkhead firewall).

• Regional politicians who support the improvement of learning environments.

• Media who supported the project in terms regional development and marketing the initiative to improve education and bring up-to date learning facilities also to the more rural areas.

• And not to forget the neighborhood and especially the parents (in particular the ones less IT enthusias- tic) who needed a good portion of convincing that this was something big and essential to their kids’ development and future chances.

What finally saved the project? 1. Initial core team brain storming and proper

stakeholder analysis (no matter whether according to PMI, IPMA, or PRINCE2, list them all, check their expectation, interests, influence, power, degree of potential support, and involvement).

2. Two alternative Meetings informing all interested parties (obligatory to certain stakeholders and open to the public and invited media), so everyone KNEW, everyone received a roughly 50-page handout with detailed plans and intentions, involvement of all relevant parties, order of steps, phases of progress, ways of communication etc.

3. A short pilot consisting of 8 schools, 2 schools of every one of the 4 different types (primary/small, secondary/middle, gymnasium/large, special needs) helped us group the remaining location in mixed regional groups for each rollout team, scheduling the whole procedure was a challenge because due to different sizes and varying numbers of equipment, totally different buildings etc. there was no chance to cut everything into weekly time boxes

à la “sprints” in agile scrum. Instead every team had their own stream of tasks, consisting of nearly the same steps, however, with independent underlying amounts of effort.

4. At virtually every first on-site visit someone unexpected played a vital role (relevant for interdependency of activities, e.g., schedule, cost, resources, communication, risks, basically the whole range of PM topics), we (the project core team on “whistle stop tour,” usually four to five people) explained everything we said at the two kickoff meetings again, answered more questions, and made clear that local support according to schedule was vital and deliberately failing to meet deadlines meant moving down the list and along the time line.

5. During the second on-site meeting we checked the “preconditions ready” and if so delivery and set up of IT equipment were approved, if not another school from further down the list was invited to move up if they met the criteria.

6. Every piece of equipment had a checklist, all functions were tested and ticked off by a technician and a school representative reporting status “green,” which automatically approved the final steps including training of staff on-site by the same technicians who worked on-site the 1–2 weeks beforehand.

Bear in mind: 1. Have a plan You need to follow a . systematic

approach throughout the project. 2. Employ structured Information. 3. Pilot what you do. 4. Communicate face to face on site. 5. Have clear rules. 6. Have a realistic time line, incl. buffers for all sorts of

risks and additional stakeholder involvement wherever necessary.

Source: Martin Kontressowitz.

Chapter 5 Stakeholder Analysis and Communication Planning 143

CHA P T E R 6 Scope Planning

You’re browsing a favorite retailer’s website, and you notice the onscreen recommendations are just right for you. The site seems to know what you’ve bought before. This great customer service is enabled by the retailer’s web intelligence solution from Teradata.

Teradata is the world’s largest company focused solely on enterprise data warehousing and analytic solutions. The simple web shopping scenario is just one example of how our customers use information to improve their relationship with you.

So what does this have to do with project scope management? In this example the retailer purchased a Teradata solution that included hardware, software, and a consulting project for the implementation. Teradata implemented this project based on our experience and a methodology built upon a foundation of scope management.

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Describe the plan scope management, collect requirements, and define scope processes.

• Create a requirements traceability matrix, project scope statement, and change request form.

• Describe what a work breakdown structure (WBS) is and explain why it is vital to project planning and control.

• Compare and contrast different methods of developing a WBS.

• Create a WBS, including work packages and a numbering system for the code of accounts both by hand and using MS Project.

© Yu ri Ar cu rs /S hu tte rs to ck

144

Topics:

• Plan scope management

• Collect requirements

• Define scope

• Create WBS

• Change requests

We can manage scope in various ways—ranging from traditional waterfall to agile approaches—but must manage scope to deliver the right solution in an efficient manner.

The first step in project scope management is to mutually agree what the project will deliver. In our example, the retailer needed to integrate data from their web analytics software, an in-house customer relationship system, and other sources. They also had requirements for reports and the technical integration with their IT infrastructure. The Teradata team elicited requirements in a way that uncovered what the customer really needed.

Projects often use a statement of work (SOW) or similar document to outline the high-level scope. In a Teradata project, this is part of our customer contract. We then elaborate more detailed requirements in a traceability matrix. This ensures all requirements tie “end to end” from the contract through project testing and customer acceptance. The time spent up-front in requirements management pays dividends during project testing and customer acceptance, where discovering unknown requirements is much more time consuming and expensive.

Teradata follows traditional project management practice to develop a work breakdown structure (WBS) as the basis for a detailed project schedule and resource plan. We typically use Microsoft Project as a scheduling tool; a plan based on the WBS makes it easy to track and communicate the status of each deliverable.

Finally, the entire set of requirements is managed under change control. This is an important process, because the team must balance control and flexibility. We also must meet (or agree to change) the project cost and schedule parameters. Our project manager facilitates an analysis of the technical, schedule, and cost impact—then all parties reach amutual agreement on how to proceed.

This simple example illustrates how the Teradata project methodology builds upon a foundation of scope management to deliver exactly what the customer needs in the most efficient manner. An effective scope management approach fosters open communications and sound decision making to ensure all parties get the business value expected from the project.

Mike Van Horn, Teradata

PMBOK® Guide

145

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative Closure

Planning Executing Closing RealizingInitiating

RealizedResultTo Proceed

6-1 Plan Scope Management Once all of the stakeholders for a project have been identified, the project team members plan scope management, collect project requirements, define the project’s scope, and create a work breakdown structure (WBS). These are the scope planning processes that will be covered in this chapter. When planning scope, it is also wise to plan for changes. While this is not technically part of scope planning, it will also be covered in this chapter.

The flow of scope planning is illustrated in Exhibit 6.1. The boxes represent the proj- ect work processes involved, and the documents shown before and after the boxes repre- sent major inputs needed to perform the processes as well as major outputs created by the work processes. Documents covered in previous chapters (Charter in 4 and Stake- holder Register in 5) are needed inputs for the first two processes.

The first scope process, plan scope management, is “the process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled.”1 The product scope is “the features and functions that characterize a prod- uct, service, or result.”2 The project team also needs to determine the project scope or “the work performed to deliver a product, service, or result with the specified features and functions.”3 Together, the product scope (the outputs the team will deliver to its customers) and the project scope (the work they need to perform to create the project’s outputs) form the total scope. In other words, the project team members determine what they will do to ensure they have identified and organized all of the project work so they can use it as the basis of all other planning and then as the basis for executing and con- trolling the project work.

6-2 Collect Requirements Collect requirements is “the process of defining, documenting, and managing stake- holder needs and requirements to meet project objectives.”4 The first step in collecting requirements is to ensure that the project team is absolutely clear on the project objec- tives. This could be accomplished by reviewing the project charter—particularly the “why” section that justifies the project. The project team members then may describe in more depth what each believes the expected project benefits are and/or what problems the project is attempting to overcome. On simple projects, this may take just a few min- utes. On complex projects, a project manager may choose to use idea generation, group- ing, and/or cause-and-effect techniques to make sure that everyone on the project team

EXHIBIT 6.1 SCOPE PLANNING FLOW

Plan Scope Management

Scope Management Plan

Stakeholder Register

Charter Collect Requirements

Define Scope

Create WBS

Perform Integrated Change Control

Approved Changes and Updates

Scope Baseline with WBS

Scope Statement

Requirements Traceability Matrix

146 Part 2 Planning Projects

understands why the project is being conducted. Understanding broad project objectives will help in making more detailed decisions later. This also reinforces the project’s importance and may help motivate team members and other stakeholders during chal- lenging times. It is especially useful with multifunctional, virtual, and global project teams. Finally, a clear understanding of the project’s objectives helps if the project needs to be replanned at some point.

6-2a Gather Stakeholder Input The second step is to gather input from the various project stakeholders. When a project manager and team listen closely to both internal and external customers, they under- stand better both what their needs are and what risks and issues may confront them during the project. Successful project managers know that for a project outcome to be useful to the project’s customers, the customers need to be able to use the output to better serve their own customers in turn.

The methods of developing deep understanding of customers and their needs vary extensively from one industry to another. For example, in new product development projects, teams often use voice of the customer (VOC) techniques to elicit the benefits and features the customers want out of the project expressed in the customer’s language. Teams using VOC try to understand the customer by not only asking questions, but also by placing themselves in the customer’s situation. If a project team is designing a new system that is to be used in the field, the team member should get down in the mud with the mechanic and hand the mechanic repair tools to see from the mechanic’s point of view how the new system will be used.

Once captured, these customer wants and needs are then stated in operational terms that the people performing the project work can use to plan their work. If the customer wants blue food coloring in a food item, the project team developing the item needs to know the precise desired shade of blue, the tolerance for color variation, and how the blue color may interact with other ingredients.

The project manager wants to understand how a project’s success will be determined from the customer’s perspective. The best way to gain this understanding (and to begin building a strong relationship with customers) is to directly ask customers. The project leaders can ask the customer(s) to specify how they will judge the quality of the project.

On an information systems project, the team may use a joint application design (JAD) session to elicit customer requirements. This is often a facilitated session in which users of the software state what their preferences are regarding how the software should work. The project manager and team often send the users their understanding of the project objectives and deliverables in advance so the users are better prepared to discuss their needs. Only one group of users is normally in this meeting at a time, while the project manager and the tech- nical workers are in the session the entire time. Each possible feature of the system should be discussed. If the system is large and complicated, the amount of time that can be spent per item may be restricted. Users often wish to talk in depth about how they want to use the system, and developers often want a detailed discussion about how they plan to create the feature. To avoid sinking into too much detail, the project manger can ask the users to start with only a high-level description of their reason for the requested feature and then guide the discussion with the following five questions:

1. What do we not understand about the request? 2. What is the business reason for the request? 3. What is the impact of not providing this feature? 4. What action items need to be accomplished if we do this? 5. What impact will this have on other parts of the project or elsewhere?

Chapter 6 Scope Planning 147

On some types of projects, the customers can give their ideas using one of the techniques above, and the project team can be confident that the customers’wants and needs have been captured. On other projects, once the customers’ viewpoint is captured, it makes sense to create a model or prototype of some sort so the customers can decide if their wishes have been fully and accurately captured. Often, this extra step helps the customers to bemore fully vested in the project and creates a strong working relationship that is helpful when difficulties arise during project execution.

It is helpful to list requirements and their supporting information in a requirements traceability matrix such as that shown in Exhibit 6.2. When requirements are complete each needs to be:

• Traceable back to the business reason for it • Identified with the stakeholder(s) who need it • Clear so everyone understands it the same way • Measurable so its value and completion can be verified • Prioritized according to value, cost, time risk, or mandate so tradeoff decisions can

be made if needed

6-3 Define Scope Define scope is “the process of developing a detailed description of the project and product.”5

Essentially, the project scope statement includes three things regarding the total scope. First, the team needs to determine both what they will deliver to the project stakeholders at the end of the project and what they need to deliver along the way to ensure they will be successful in the end. These are the deliverables—the product scope. For example, if a final project deliv- erable is a new computer program, intermediate deliverables may include an outline of what will be included and a prototype. Second, the team should decide what work needs to be accomplished to create the deliverables This is the project work statement—the project scope. Third, the team needs to determine what will limit or influence the project work—such as exclusions, constraints, and assumptions.

6-3a Reasons to Define Scope Scope definition is an important part of project planning because all other planning is based upon the project scope. While the requirements collected represent the customers’ statement of what they need, the defined scope is the project team’s response—asking the

EXHIBIT 6.2 REQUIREMENTS TRACEABILITY MATRIX

BUSINESS NEED REQUIREMENTS STAKEHOLDER(S) PRIORITY

148 Part 2 Planning Projects

customer, “If we provide this, will it solve your problem?” It is impossible to estimate how much a project will cost, how many (and what type of) workers will be needed, how long a project will take, what risks are involved, or what quality standards will be invoked without first understanding what work the project includes.

Scope definition also is vital in preventing scope creep. Scope creep happens for two com- mon reasons. First, if the scope is not clearly defined and agreed upon, it is easy to add to the project without realizing that more time and money will be required. Second, sometimes when a project is going well, a customer is so excited that he or she asks an innocent- sounding question: “Can the project output also do… ?” The person performing the project work is often flattered and agrees without understanding the implications. In contemporary business, pleasing the customer is desirable. However, the best time to gain customer under- standing is when the project team is defining the scope—not while working to implement it.

6-3b How to Define Scope Scope definition can vary greatly from one project to another. On some types of projects, such as a small, routine construction project, it may be quite simple to determine what project outputs will be created and what work is involved in creating them. On other projects, such as one large company acquiring another, it may be very difficult to deter- mine the total amount of work that needs to be accomplished. Regardless of how easy or difficult it may be to define scope and in spite of industry-specific methods that may be helpful in doing so, all project teams need to complete each part of this process.

LIST DELIVERABLES AND ACCEPTANCE CRITERIA The first step is to list project deliverables. The requirements elicited from the customer often lead to some of the final deliverables. Project teams need to understand that there are often multiple deliverables. For example, if a project entails constructing a house, the homeowners probably want not only the house but also documentation on systems within it, perhaps an explanation (training) on how to use certain items such as an innova- tive thermostat, and a warranty guaranteeing a properly functioning house. The project team also needs to list intermediate deliverables—those things that need to be developed for the project to progress. Some of these were probably listed in the charter, but others may not yet be identified. The project team then needs to deter- mine the acceptance criteria for each deliverable.

ESTABLISH PROJECT BOUNDARIES The second step in defining scope is to establish the project boundaries. Think of the project boundaries as the sidelines on an athletic field. By understanding what is in play and what is not, athletes know clearly when to play and when to stop. Likewise, project team members need to know when to play and when to stop. The first part of the boundary definition is to decide which features and work elements are included (in scope) and which are excluded (out of scope). Users collectively often request far more work than a project can deliver. Therefore, the team needs to decide what is included and what is not. Sometimes, the sponsor makes the larger scope decisions, but the project manager and team still have many detailed scope decisions to make.

Expectations need to be managed regarding any project. The project team members need to understand the constraints imposed upon the project. If the work must be deliv- ered by a certain date or if only limited resources are available, the project may be con- strained, and the team should be careful to only promise what it can deliver. In planning, people make assumptions about dates and times, such as that a shipment of required materials will arrive by the date the supplier promised. These assumptions should be stated. If an assumption proves to be false, it frequently increases the project risk and may also limit the project scope.

Chapter 6 Scope Planning 149

CREATE A SCOPE DESCRIPTION The final step is to create a scope description. This sen- tence or two describes the work that needs to be accomplished to create the project deliverables.

A project scope statement guides the project team during subsequent planning and execution. On some very small projects, a well-developed charter could double as a scope statement. On most projects, a scope statement needs to be developed prior to develop- ment of the WBS. An example scope statement for the Alternative Breaks project is shown in Exhibit 6.3.

6-3c How to Define Scope in Agile Projects On agile projects, the scope definition starts with user stories. The team creates “per- sonas,” which are fictional people who represent user types and then asks what will they do with the project deliverables and how will they benefit. These user stories de- fine scope and functionality. Acceptance tests will also be agreed upon at this time by describing the manner in which project deliverables will be tested and how they should prove workable. At the project outset, the overall scope is only defined at a high level and a backlog of possible work is identified. The customer representative (sometimes called the owner) prioritizes the scope based upon business need, value, cost, and risk. The team then commits to the amount of work they can perform in the first iteration. As the project progresses, the scope is described more specifically and is documented more closely.

6-4 Work Breakdown Structure (WBS) A tool that is used on virtually all projects is the WBS. To understand this tool, we first define it, tell why it is important, show several common formats to use when constructing one, and demonstrate the steps required to construct a WBS.

A G I L E

EXHIBIT 6.3 SCOPE STATEMENT

ALTERNATIVE BREAKS PROJECT SCOPE STATEMENT

Scope Description: This project will educate groups of 12 students on social justice issues, send them to perform direct service on the issues, and provide reflective opportunities throughout the process. Key deliverables with acceptance criteria (product scope):

KEY DELIVERABLES ACCEPTANCE CRITERIA

Project plan Secured housing,

Agreement with organization

Fund raising Adequate money

Education Syllabus

Reorientation Digital archives

Trip itself Return safely, pre- and post-evaluation

Exclusions: No alcohol, drugs, or romances; ratio number of trips to student population.

Constraints: Van only holds 12 people—11 students and one faculty or staff; number of highly qualified site leaders.

Assumptions: Service builds active citizens; international trips add more value than expense; a trip is better with a staff or faculty member.

Source: Chris Bridges.

150 Part 2 Planning Projects

6-4a What Is the WBS? The work breakdown structure or WBS is a tool that project teams use to progressively divide the deliverables of a project into smaller and smaller pieces. The project team members start by identifying the major deliverables to be created and keep asking “What are the components of this deliverable?” The WBS is not a list of work activities, an organizational chart, or a schedule. Other tools that follow are used for those purposes. The WBS is a framework that is used as a basis for further planning, execution, and control.

Classically, and still today on large projects, the WBS is created after the scope is defined. In contemporary project management, particularly on small and middle-sized projects, the WBS may be created concurrently with the scope statement.

The WBS is normally developed by listing deliverables—first major deliverables and then progressively smaller ones until the team feels that every deliverable has been identified. Managers of smaller projects sometimes perform another process concurrent with WBS development: defining activities and milestones. Define activ- ity is “the process of identifying the specific actions to be performed to produce the project deliverables.”6 Many people find that work activities can be easily defined once the various deliverables are itemized. To clearly distinguish between the work processes of WBS development and activity development, WBS development is cov- ered in this chapter, and activity development is covered as part of project schedul- ing in the next chapter. Developing the WBS and defining the activities form an example of how two separate work processes are sometimes performed together (especially on small or simple projects) and sometimes separately (especially on large or complex projects).

6-4b Why Use a WBS? The reasons for using a WBS are many. Planning projects requires discipline and visibility. A WBS can be used as a pictorial representation of project deliverables. By using a systematic process for creating a WBS, project team members can ensure that they remember all deliverables that need to be created. Deliverables that are not planned, but need to be, often add to schedule delays and budget overruns.

The WBS is the basis for all subsequent planning of such important functions as schedule, resources, cost, quality, and risk. It serves as an outline for integrating these various functions. The WBS is easily modified and can thus handle the changes that often happen on projects. The impact of these changes is then shown in the schedule, budget, and other control documents. If a problem occurs during project execution, the WBS is helpful in understanding exactly where and why the problem occurred. This helps to manage the quality of the project deliverables and keep all the other facets of the project on schedule while the isolated problem is fixed.

The WBS is also helpful in project communications. Typically many stakeholders help develop the WBS, and this effort helps them understand the project. Software such as Microsoft Project enables a WBS to be shown in its entirety to people who need to understand the details, but it also allows project details to be hidden so that others can see the big picture.

Chapter 6 Scope Planning 151

6-4c WBS Formats There are various formats for constructing a WBS, but they all have the same purpose. The overall project is considered the first level, as shown in Exhibit 6.4. In this example, a WBS for a house is presented in the indented outline format.

The second level in this example depicts major deliverables from the house project, namely the house in its framed state, when it is wired, and when it is drywalled. This second level is indented one tab. Note that a section is included for the work of planning and managing the project.

A WBS usually has one or more intermediate levels, which generally represent items that need to be created in order to produce the final deliverables, such as drafts, proto- types, designs, and so on. These are frequently called interim deliverables. All levels of the WBS with at least one level below are considered summary levels. The completion of summary-level elements is based upon completion of all levels underneath. For example, in Exhibit 6.4, the house would not be framed until the framing contractor, wood, and assembled frame interim deliverables were complete.

EXHIBIT 6.4 HOUSE WBS IN INDENTED OUTLINE FORMAT

HOUSE

• Project Management • Framed House

– Framing Contractor – Wood – Assembled Frame

• Wired House – Wiring Contractor – Wiring – Installed Wiring

• Drywalled House – Drywall Contractor – Drywall – Hung Drywall

Framing a house is a major deliverable in a house project.

© M ic ha el W oo dr uf f/S

hu tte rs to ck .c om

152 Part 2 Planning Projects

Exhibit 6.4 used the indented outline format for WBS method, but other methods are sometimes used. One other method is the hierarchical or “org chart” (short for organizational chart, which it resembles) method. A third method is called free format because the facilitator is free to draw it in any manner. The same house project shown in Exhibit 6.4 in indented outline format is shown in Exhibit 6.5 in org chart format and in Exhibit 6.6 in free format.

Both of these methods allow a team to use a marker board or flip chart and have plenty of room to add additional elements as people think of them.

EXHIBIT 6.5 WBS IN ORG CHART FORMAT

Drywalled HouseFramed HouseProject Management Wired House

Drywall ContractorFraming Contractor Wiring Contractor

DrywallWood Wiring

HOUSE

Hung DrywallAssembled Frame Installed Wiring

EXHIBIT 6.6 WBS IN FREE FORMAT

House

Framed House

Framing Contractor

Wood

Assembled Frame

Wired House

Wiring Contractor Wiring

Installed Wiring

Drywalled House

Drywall Contractor

Drywall

Hung Drywall

Project Manage- ment

Chapter 6 Scope Planning 153

The WBS method using indented outlines can easily be imported into MS Project. Teams using the org chart or free format methods to develop their WBS generally translate it into the indented outline format for input into software.

6-4d Work Packages The house example above has only three levels as follows:

1. The first level, or project title level 2. One intermediate level, or summary level 3. The lowest level, or work package level

In a WBS, an element at the lowest level is called a work package, which is “the work defined at the lowest level of the work breakdown structure for which cost and duration can be estimated and managed.”7 Work packages are the basis for all subsequent plan- ning and control activities. Exhibit 6.7 shows a WBS in org chart format with work packages in solid boxes.

One frequently asked question when breaking the deliverables into work packages is how small is small enough. The answer is, “It depends.” In Exhibit 6.7, work packages occur at levels 3, 4, and 5. The work package is the point from which:

• Work activities are defined • The schedule is formed • Resources are assigned • Many of the control features are developed

Work packages need to be detailed enough to facilitate further planning and control. If they are too detailed, the burden of tracking details increases. The project manager needs to feel confident that the work to create the deliverable can be assigned to one person who can estimate the schedule and cost and can be held responsible for its com- pletion. If the work is well understood, a single deliverable is to be produced, it is clear

EXHIBIT 6.7 WBS DEPICTING WORK PACKAGES

PM

Project

AB CD EF

Level 1

2

3

4

5

Work Packages

Source: Kevin P. Grant, UTSA.

154 Part 2 Planning Projects

how the deliverable will be judged for quality and completeness, and the assigned worker has proven reliable in the past, the level may not have to be too detailed. On the other hand, if the deliverable and how it will be judged are poorly understood and the assigned worker has yet to be proven reliable, a more detailed level may make sense.

For ease of reading, work packages and other components on a WBS are usually stated in very few words. A WBS component is “an entry in the WBS that can be at any level.”8 Enough words should be used so the same name is not used more than once. However, because the names are typically short, there is still the potential to get confused by exactly what is included in a particular work package. Therefore, WBS components are often defined further by creating a WBS dictionary. A WBS dictionary is “a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS.”9 An example of a WBS dictionary entry with de- tailed information for a work package is shown in Exhibit 6.8. Note that some of this additional information such as activities, resource assignments, effort, and cost will be described in subsequent chapters.

6-4e How to Construct a WBS When a project team needs to construct a WBS, it needs to include in its planning team a subject matter expert (SME) who understands how each portion of the work will be accomplished. Teams approach this in two ways. Some teams include only the core team members and plan the WBS as far as they can. At that point, different core team members are assigned to assemble the SMEs they need to plan the remaining details. Other teams invite the SMEs to the WBS planning meeting right from the start and utilize their input right away. The choice of how to include SMEs often is determined by the size and complexity of the project and by the cultural norms of the company.

The planning team uses a top-down approach in creating the WBS. This is easy to start when the type of project is familiar and at least some members of the planning team are likely to understand the general flow of work. If the project is similar to others

EXHIBIT 6.8 WORK PACKAGE DETAIL

Project: Expansion to Full Scale Production Work Package: Assembly Hardware Test

Description: Plan, conduct, evaluate, and report results of tests to ensure proper function of the assembly hardware.

Deliverable(s): Test results summary.

Input(s): Assembly hardware prototype

Activities Resource Expected Duration

Cost

Prepare test plan Production Analyst 8h $ 720

Conduct test Production Analyst 16h 1,440

Evaluate test results Production Analyst 6h 540

Prepare test results summary Production Analyst 8h 720

$3,420

Source: Kevin P. Grant, UTSA.

Chapter 6 Scope Planning 155

performed, either a template or the WBS from a previous project can be used as a start- ing point, with the team then asking what else this project needs and what items from the template or previous project can be skipped. Templates and previous examples can save teams a great deal of time, but they must be used with caution because each project is different.

Sometimes, however, a project is so different from previous work that the team finds it useful to jump-start the WBS construction by brainstorming a list of project deliver- ables just to understand the overall structure of the project. However, once the overall structure is understood, the team proceeds with the typical top-down approach for the remainder of the WBS construction.

IDENTIFY MAJOR DELIVERABLES The team defines the project product by reviewing the project planning completed so far. The team members review the project charter, requirements matrix, and scope statement so they can state what the project’s major deliverables will be. Remember that while many projects may have a primary deliverable such as a house, almost all projects have additional deliverables dealing with documenta- tion and customer enablement. These could include training, service, or other means of helping the customer use the project’s products effectively.

One of the first decisions to be made is how to organize the second level of the WBS. (Remember the first level is the overall project.) Three methods are shown in Exhibit 6.9. One method is by project phase, with the second level being the signing of a contract, building the foundation, and framing the house. Alternatively, the second level can be organized by design components, such as kitchen, bedrooms, and bathrooms. Finally, the second level can be organized by work function. A house project organized this way might have carpentry, plumbing, and electrical as second-level elements.

Organizing by project phase has the advantage of using the milestones in the project charter as an organizing principle. It also facilitates rolling wave planning. Rolling wave planning is “an iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level.”10 If the planners of the project in Exhibit 6.9 used rolling wave planning, the work associated with the contract would be planned in detail immediately, and work for the foundation and framing might only be planned at a high level at first with more detail worked out as the project team worked on the contract. Rolling wave planning allows a team to get a quick start on a project—especially one where details of later phases may depend on the results of work performed during early phases. Rolling wave planning helps a project team avoid either of two extremes. One extreme is to never start doing anything because the plan is not yet complete, which is also known as analysis

EXHIBIT 6.9 WBS ORGANIZATION EXAMPLES

PROJECT PHASE DESIGN COMPONENTS/ DELIVERABLES

WORK FUNCTION/ SUBPROJECT

Project Management Project Management Project Management

Contract Kitchen Carpentry

Foundation Bedrooms Plumbing

Framed House Bathrooms Electrical

… … …

156 Part 2 Planning Projects

paralysis. The opposite extreme is not planning at all because of fear that planning will take too long; this is known as ready, fire, aim.

Organizing by either phase or design components helps to focus communications on project deliverables and their interactions. Organizing by work function allows the functions to focus on their specific activities, but often does not promote cross- functional discussion. Handoffs of work from one group to another are not always as smooth. Therefore, if a project manager decides to organize the WBS by work function, extra care needs to be taken in establishing inter-functional communications.

Note that one additional second-level item is shown on all three methods—that of project management. This includes the work of planning and managing the effort and includes preparing documents, attending meetings, integrating diverse portions of the project, handling communications, and so on. Since much of the work involved in proj- ect management is level of effort, this section may not be decomposed. If the work of managing the project is left out, it is more likely that the project will not be completed on time and within the budget.

DECOMPOSE DELIVERABLES Once the major deliverables have been defined, it is time to break them into smaller deliverables or components. This is called decomposi- tion, which is “a technique for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts.”11 The team members can use the top-down approach, asking what all the components of each major deliverable are. Alter- natively, the team members may use a bottom-up approach by brainstorming a list of both interim and final deliverables that they feel need to be created. Each deliverable can be written on an individual Post-it Note. These deliverables are then assembled on a large work space where team members group the smaller deliverables either under the major deliverables that have been previously identified or into additional related groups that are then headed by major deliverables.

CONTINUE UNTIL DELIVERABLES ARE THE RIGHT SIZE At this point, the WBS has been formed and can be reviewed for completeness. Once it is determined to be com- plete, the team can ask if the deliverables at the lowest level need to be divided again to be at the proper size for further planning and control as described above. For example, in the new car development project in Exhibit 6.10, level-two components, such as prod- uct design, are at too high of level. Therefore, at least one further level is included. If some of those components, such as product goals, are still too broad, yet another level would need to be developed.

REVIEW At this point, several things should be considered to ensure that the WBS is structured properly. One consideration with WBS construction is the parent-child con- cept. The higher level is considered the parent and the lower-level elements are consid- ered children. For example, in Exhibits 6.4 through 6.6, “Framed House” is a parent to the children: “framing contractor,” “wood,” and “assembled frame.” “Framed House,” in turn, is a child to “HOUSE.” The framed house component is not complete until all of its children components are complete. The team asks if, once these elements are com- plete, the framing is complete. In an effort to simplify the WBS, where only one child element for a parent exists, you would not break it down. In fact, a good rule of thumb is to have somewhere between three and nine child elements for each parent. The fewer levels a WBS has, the easier it is to understand.

To avoid confusion, each component in the WBS needs to have a unique name. Therefore, two similar components may be “draft report” and “final report,” instead of merely calling each “report.” The team also assigns a unique number to each component. In one common numbering system, the number for a child item starts with the number

Chapter 6 Scope Planning 157

assigned to its parent and adds a digit. An example of a WBS with components num- bered is shown in Exhibit 6.11.

Different organizations sometimes develop their own unique variations of project planning and control techniques. Exhibit 6.12 describes the manner in which a large, complex organization (the U.S. Central Intelligence Agency) combines stakeholder analysis with WBS.

6-5 Establish Change Control A baseline is “the approved version of a work product that can be changed only through formal change control procedures and is used as a basis for comparison.”12 The project team looks at the scope statement and WBS to ensure completeness and seeks to validate the scope by consulting with the sponsor, customers, and/or other stakeholders. Simulta- neously, the project team can be planning other aspects of the project such as schedule, resources, budget, risks, and quality. Once all of these plans are complete and any impacts to scope have been accounted for, it is time to baseline the scope statement and the entire project plan. This is discussed in more detail at the end of the planning stage.

Most projects are planned and conducted in an atmosphere of uncertainty. Projects are planned making assumptions based upon the best information available to the proj- ect team, but many things can change during the course of a project. Therefore, project teams deal with change by establishing and using a change control system, which is an “approved set of procedures that describes how modifications to the project deliverables and documentation will be managed and controlled.”13 Uncontrolled change is known as scope creep. Sometimes, the effects of scope creep are so bad that a well-started project can run into serious trouble.

The critical portion of a change control system is the method of documenting changes. Each potential change to a project is normally documented by some sort of change request, which is “a formal proposal to modify any document, deliverable, or baseline.”14

This means every change to a project needs to be formally proposed. The poten- tial change is then either accepted or not. If it is accepted, the project plans are changed to reflect the impact of the change. Most people quickly understand the

EXHIBIT 6.10 PARTIAL WBS OF CAR DEVELOPMENT PROJECT

Car Development Project Project Management Product Design

Product Goals Concept Design Modeling Design Vehicle Integration Engineering Feasibility Detailed Engineering Design Performance Development Regulatory Certification

Process Development Prototype Production Materials Procurement General Materials Procurement Trial Manufacture

158 Part 2 Planning Projects

EXHIBIT 6.11 LIBRARY PROJECT WBS WITH COMPONENTS NUMBERED

LIBRARY PROJECT

1. Project Management

2. Facility Needs

2.1 VISION STATEMENT

2.2 STAKEHOLDER INPUT

2.3 OPTIONS

3. Building Proposal

3.1 RECOMMENDED SIZE AND SCOPE

3.2 SITING

3.3 COST RATIONALE

4. Building Approval

4.1 VP OF FINANCE APPROVAL

4.2 PRESIDENT APPROVAL

4.3 BOARD APPROVAL

5. Staff Education

5.1 LITERATURE REVIEW

5.2 LIBRARY VISITS

5.3 SUPPLIER INPUT, PROCESS, OUTPUT, CUSTOMER ANALYSIS

5.4 TRAINING

6. Fundraising

6.1 POTENTIAL DONOR LIST

6.2 RELATIONSHIP BUILDING WITH POTENTIAL DONORS

6.3 EDUCATION OF POTENTIAL DONORS

6.4 DONATIONS

6.5 FOLLOW-UP WITH DONORS

7. Building Documents

7.1 FACILITY AND SITE SPECIFICATIONS

7.2 SCHEMATIC DESIGNS

7.3 DEVELOPMENT PLANS

7.4 CONTRACT DOCUMENTS

8. Building Construction

8.1 ARCHITECT

8.2 CONTRACTORS

8.3 CONSTRUCTION

8.4 FURNISHINGS

9. Building Acceptance

9.1 BUILDING AND GROUNDS ACCEPTANCE

9.2 BUILDING OCCUPANCY

9.3 BUILDING DEDICATION

9.4 WARRANTY CORRECTIONS

Chapter 6 Scope Planning 159

need to document major changes, but some resist the effort it takes to document small changes. The impact of many small changes is like the old saying “killed by a thousand small cuts.” Many small changes individually have small impacts on a project, but collectively they have a major impact. Project managers need to create an expectation that all changes be formally documented using a simple change request form so all team members will document proposed changes. A simple change request form is shown in Exhibit 6.13.

Change request forms typically include several sections. The top section lists basic infor- mation to track the change request to the project and to the person who submitted it. The second section contains two simple statements describing the change and why the change is needed. The third section details the impact expected from the potential change. This can vary in length from a simple check and comment section, as in Exhibit 6.13, to an extremely involved description of potential impact on complex system projects such as designing an aircraft. In complex projects, small changes can sometimes have catastrophic impacts. Finally, there should be a space for the change to be approved. Regardless of the complexity and format, the most important consideration is that potential changes must be submitted and documented whether they are approved or not.

6-6 Using MS Project for Work Breakdown Structures (WBS)

The WBS is a building block for the remaining detailed project planning tools. This is the place where the value of software to automate detailed work becomes apparent. Our coverage of MS Project in this chapter describes how to set up a WBS in MS Project.

EXHIBIT 6.12 STAKEHOLDER ANALYSIS AND WBS AT THE CIA

At the CIA where I created and run our agency-wide project management training and certification program, I come in contact with large numbers of dedicated project managers. With enrollment averaging about 2,500 students per year, I encounter a work- force with a broad spectrum of experiences, skills, and expectations. One of the more prevalent expectations is associated with stakeholder analysis and communication; employees invariably feel that they pretty much know most or all they need to know in this area and may even begrudge somewhat the three days associated with our Project Communications Management course. What they discover, is the shortcomings in their appreciation for and knowledge about project communications. Using a five- point Likert scale, we have every student perform a self-assessment of their communications proficiency prior to and after the class. To the students’ surprise, proficiency increases average a full point; student feedback virtually always includes statements to the effect that they didn’t realize just how much more effective they can be in project management by investing more in the proj- ect communications area.

The organizational chart plays a central role in how the CIA approaches the analysis of stakeholders. Employees learn through classroom exercises to use the organizational chart as a roadmap for identifying the stakeholders. As they march through the branches in this chart, they make conscious decisions about whether the function represented by the title or box on the chart or whether the individual performing that function is a stakeholder. Once they have identified the stake- holders and performed the associated stakeholder analysis, they then turn to the WBS to help with the planning and implementation of the communications tasks that follow. In fact, communications for the types of projects undertaken at the CIA have taken on such importance that we advocate it be placed at the first level of WBS decomposition alongside equally important components such as project management. For projects of sufficient size, a full-time leader is often assigned to the communications component; the scope of their duties includes communications within the project as well as communications outside the project.

Source: Michael O’Brochta, PMP, director, PPMC Program, CIA.

160 Part 2 Planning Projects

6-6a Set Up the WBS Setting up the WBS has five steps, as follows:

1. Understand WBS definitions and displays. 2. Enter summaries. 3. Create the outline for your WBS. 4. Insert row number column. 5. Hide (or show) the desired amount of detail.

STEP 1: UNDERSTAND WBS DEFINITIONS AND DISPLAYS MS Project refers to WBS elements as summary tasks or summaries. Summaries are displayed:

• In tables as an outline, with summary tasks in bold. MS Project uses only the in- dented outline format to display a WBS.

• In a Gantt view with different graphic shapes (there are several Gantt views).

Exhibit 6.14 shows a Gantt view of a WBS with the entry table on the left and the Gantt chart graphic on the right. At this time the Gantt graphic is of little value— there is no underlying detail with duration values that drive a summary duration longer than one day.

STEP 2: ENTER WBS ELEMENTS (SUMMARIES) Enter the summaries in the Task Name column cells as shown in Exhibit 6.15. WBS elements can be added with an insert function as follows:

1. Click on the Id field to select the row below where the new row will be. Selecting more than one row will result in that number of blank rows being inserted.

2. On the Task tab, Insert group, click Insert Task.

EXHIBIT 6.13 CHANGE REQUEST FORM

ORIGINATOR: PROJECT #:

Date

Description of Change:

Why needed:

Impact on project scope:

Impact on deadline dates:

Impact on budget:

Impact on quality:

Impact on risk:

Impact on team:

Date approved:

Project manager Sponsor Customer

Chapter 6 Scope Planning 161

3. In the Task Name field, enter the name of the added WBS element. 4. Enter any additional summary(s).

STEP 3: CREATE THE OUTLINE FOR YOUR WBS Set up the outline structure using the Indent and Outdent controls shown in Exhibit 6.16 (these are two separate controls, appearing as the Task tab green arrows).

1. Click the Task Name field of the row to be indented. 2. On the Task tab, Schedule group, click Indent Task. Indenting a summary row

will also indent its lower-level items. Multiple rows under a summary row can be indented at the same time by selecting all of them before clicking the Indent control.

3. To decrease an indent level with the Outdent control: On the Task tab, Schedule group, click Outdent Task. Any lower-level items will also be outdented.

EXHIBIT 6.14 GANTT CHART VIEW-THREE-LEVEL WBS

Task Id Column Project

Summary Row Intermediate

Summary Row

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

162 Part 2 Planning Projects

STEP 4: INSERT WBS ROW NUMBER COLUMN MS Project will automatically number all of the summaries in your WBS if you merely insert a WBS column to the left of the Task Name column. Right-click the Task Name heading, click Insert Column, and click WBS, as shown in Exhibit 6.17. The result will appear as Exhibit 6.18.

EXHIBIT 6.15 ENTER SUMMARIES (DELIVERABLES)

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

EXHIBIT 6.16 INDENT AND OUTDENT CONTROLS ON THE TASK TAB

Outdent Task Indent Task

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 6 Scope Planning 163

EXHIBIT 6.17 READY TO INSERT SELECTED WBS COLUMN

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

EXHIBIT 6.18 WBS COLUMN INSERTED

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

164 Part 2 Planning Projects

STEP 5: HIDE (OR SHOW) UNDERLYING DETAIL Some stakeholders will not want to see lower levels of WBS detail. To display the appropriate level detail, complete one or both of the following steps:

• Click Hide Subtasks (minus sign in box before the task name) to hide underlying detail, or

• Click Show Subtasks (plus sign in box) to show underlying detail.

In Exhibit 6.19, the underlying detail for the Board Retreats and Site Leader Retreat WBS elements is hidden.

Summary Once a project is formally approved by a sponsor rati- fying its charter, it is time for detailed planning. While project planning is iterative, normally the first steps are to identify stakeholders, plan communications, and determine what will be created on the project. Project teams start this process by asking customers what end- of-project deliverables they want. From the customers’ response, the planning team can determine both what interim deliverables need to be created and what work needs to be performed to create all of the deliverables.

Just as important as determining what will be produced during the project is determining what will not be pro- duced. These boundaries of what will and will not be included constitute the project’s scope.

Once the scope is defined, it can be organized into a work breakdown structure (WBS). A WBS is used to progressively decompose the project into smaller and smaller pieces until each can be assigned to one person for planning and control. The WBS serves as a basis for determining the project schedule, budget,

EXHIBIT 6.19 HIDE OR SHOW UNDERLYING DETAIL

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 6 Scope Planning 165

personnel assignments, quality requirements, and risks. As those other functions are planned, items are commonly identified that should be added to the WBS.

Some teams create their WBS by hand using the org chart or free format methods, while others directly type their WBS into project scheduling software such as Microsoft Project.

Key Terms from the PMBOK® Guide Plan scope management, 148 product scope, 148 project scope, 148 collect requirements, 148 define scope, 150 define activity, 153 work package, 156

WBS component, 157 WBS dictionary, 157 Rolling wave planning, 158 baseline, 160 decomposition, 159 change control system, 160 change request, 160

Chapter Review Questions 1. What are the two types of deliverables? 2. What is the first step in developing a project

scope management plan? 3. What three tasks comprise the “define scope”

process? 4. For a construction project, the house is

the deliverable, and how-to instruction sheets are deliverables.

5. Why is scope definition important? 6. What are two common causes of scope creep? 7. What does the acronym WBS stand for? 8. What are the advantages of using a WBS?

9. List three ways of organizing a WBS. 10. The lowest level of the WBS is known

as a . 11. What items are typically included in a work

package description? 12. What is rolling wave planning? 13. What is uncontrolled change known as? 14. Why do project teams use change control

systems? 15. List the major sections that should be included in

a change request form, and tell why each is important.

Discussion Questions 1. Are the product scope and project scope ever the

same? Cite examples if possible. 2. Create a template of a change request form.

What sections did you include and why? 3. Compare and contrast the three formats of con-

structing a WBS: indented outline, organizational chart, and free format.

4. Give an example of scope creep from one of your own projects or from a project that has made the news in recent years.

5. What are the advantages of completing the “define activity” process after creating the WBS?

6. Describe the roles various executives, managers, and associates play in scope planning.

7. You are the project manager in charge of expanding a popular restaurant. How

could you use voice of the customer (VOC) techniques to gain insight into your stakeholders?

8. Think about two upcoming projects your com- pany or school will be performing in the future. Which one do you think would have a more detailed WBS? Why?

9. The sponsor for a project you have been man- aging sends you an email that he would like to make a small change to the project. What is your response?

10. A potential client wants you to be project man- ager for the construction of a new house, but she is vague about the details. List a few questions you could ask her to gain a better understanding of the scope of the project.

166 Part 2 Planning Projects

Exercises 1. Create a requirements traceability matrix like

Exhibit 6.2 for a project in which you plan an event on your campus.

2. Create a scope statement like Exhibit 6.3 for a project in which you plan an event on your campus.

3. Construct a WBS in indented outline format like Exhibit 6.11 for a project in which you plan an event on your campus. Be sure to number each row. Also, construct the same WBS in MS Project like Exhibit 6.18.

PMBOK® Guide Questions 1. The process where project deliverables and proj-

ect work are subdivided into smaller and smaller pieces is called : a. collect requirements b. define scope c. plan scope management d. create WBS

2. The project scope baseline is comprised of the approved versions of three of the four documents listed below. Which of these documents is NOT included in the project scope baseline? a. project scope statement b. project charter c. work breakdown structure (WBS) d. WBS dictionary

3. Which of the following statements about a work package is true? a. It requires the work of the entire project team. b. It is the responsibility of the project manager. c. It is the most detailed level of the WBS. d. It is small enough that it can be completed by

one person. 4. During WBS creation, the product and project

deliverables are broken down into progressively lower levels of detail. Once the WBS has been defined at the second or third level of detail, whose input is essential in order to break down the work further? a. sponsor b. subject matter experts c. internal stakeholders d. external stakeholders

5. Which of the following is NOT a common WBS organizational format? a. cross-functional work b. major deliverables c. project phases d. subcomponents

6. A “component of the project management plan that describes how the scope will be defined, developed, monitored, controlled and verified” is the . a. project statement of work b. requirements management plan c. scope management plan d. WBS Dictionary

7. A grid that links product requirements from their origins (e.g., business reason needed, stakeholder who requested them) to the deliverables that satisfy them is referred to as a . a. network diagram b. Gantt chart c. requirements traceability matrix d. stakeholder register

8. Which of these is NOT a component of a Project Scope Statement? a. summary budget b. project deliverables c. acceptance criteria d. project exclusions or boundaries

9. The key output of the scope planning process is an approved version of the scope baseline. After this baseline is established, it can be referenced during project execution (once the project is in flight) in order to: a. staff the project properly with the right skill

sets b. link requirements back to their origins c. communicate with stakeholders effectively d. identify changes in scope that will go through

formal change control procedures 10. The process of breaking the WBS into smaller

and smaller deliverables is called: a. decomposition b. functional design c. detailed specifications d. value engineering

Chapter 6 Scope Planning 167

Example Project For your example project, create the following:

1. Scope management plan to direct your efforts. 2. Requirements traceability matrix like Exhibit 6.2

to understand customer desires. 3. Scope statement like Exhibit 6.3.

4. Change request form like Exhibit 6.13. 5. WBS first using either the free format or the org

chart format like Exhibits 6.5 and 6.6. 6. WBS in MS Project like Exhibit 6.18.

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Caudle, Gerrie, Streamlining Business Requirements: The XCellR8™ Approach (Vienna, VA: Management Concepts, Inc., 2009).

Collyer, Simon, Clive Warren, Bronwyn Hemsley, and Chris Stevens, “Aim, Fire, Aim—Project Planning Styles in Dynamic Environments,” Project Manage- ment Journal (September 2010): 41 (4): 106–121.

Fister Gale, Sarah, “The Evolution of Agile,” PMNet- work 26 (1) (January 2012): 28–33.

Hass, Kathleen B., Don Wessels, and Kevin Brennan, Getting It Right: Business Requirement Analysis Tools and Techniques Structures (Vienna, VA: Management Concepts, Inc., 2008).

Haugan, Gregory T., Effective Work Breakdown Struc- tures (Vienna, VA: Management Concepts, Inc., 2002).

Howard, Dale, and Gary Chefetz, What’s New Study Guide Microsoft Project 2010 (New York: Chefetz LLC dba MSProjectExperts, 2010).

Hunsberger, Kelley, “Change is Good: For Agile Pro- jects, Redefining Scope Isn’t Such a Creepy Thing,” PMNetwork (February 2011) 25 (2): 48–53.

Miller, Dennis P. Building a Project Work Breakdown Structure: Visualizing Objectives, Deliverables, Activities, and Schedules (Boca Raton, FL: CRC Press, 2009).

Project Management Institute Practice Standard for Work Breakdown Structures, 2nd ed. (Newtown Square, PA: Project Management Institute, 2006).

Rad, Parviz, and Vittal Anantatmula, Project Planning Techniques (Vienna, VA: Management Concepts, Inc., 2005).

Turk, Wayne, “Scope Creep Horror: It’s Scarier than Movie Monsters,” Defense AT&L (March–April 2010): 53–55.

Warner, Paul, and Paul Cassar, “Putting Together a Work Breakdown Structure,” in David I. Cleland, Field Guide to Project Management, 2nd ed. (Hoboken, NJ: John Wiley & Sons, 2004).

Endnotes 1. PMBOK® Guide 550. 2. PMBOK® Guide 552. 3. PMBOK® Guide 555. 4. PMBOK® Guide 531. 5. PMBOK® Guide 537. 6. PMBOK® Guide 536. 7. PMBOK® Guide 567.

8. Ibid. 9. Ibid.

10. PMBOK® Guide 560. 11. PMBOK® Guide 536. 12. PMBOK® Guide 529. 13. PMBOK® Guide 531. 14. Ibid.

168 Part 2 Planning Projects

PROJECT MANAGEMENT I N ACT I ON

Work Breakdown Structure Template

This template was created to ensure that the essential MANAGEMENT and TECHNICAL activities were being done by the project team for IT projects at major banks in South Africa. This was aligned to the recently updated project management standards of both PMI and Prince2. Note the line numbers. This figure represents only the

WBS elements; however, the template can be expanded to include all of the work activities required to create the deliverables identified in the WBS. The missing line numbers are activities. The PM in Action example in Chapter 7 dealing with project schedules will show how this template was used in a bank rollout schedule.

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 6 Scope Planning 169

CHA P T E R 7 Scheduling Projects

The projects I’m regularly involved in these days are for web-based software implementations. I help clients with initial adoption and use of our commercially-available applications. The cost and scope of these projects is fairly straightforward. Scheduling, however, is not!

Several problems make creating and managing implementation schedules a challenge. First, decision makers who buy our software and see its value seldom lead implementations themselves, and they may be slow to designate project leaders. Once they do, there are often gaps in communicating project objectives, timelines, and measures of success.

Second, a key success factor is populating the central repository with adequate quality content to justify the software’s use. There are two different approaches clients can take when scoping this work effort: schedule-driven approach—harvest, prepare, and load whatever content is readily available for quick deployment and usage—and scope-driven approach—define complete content requirements prior to initial launch.

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Describe five ways in which a project’s schedule is limited and how to deal with each.

• Describe potential problems in estimating time accurately and how to overcome them.

• Use the activity on node (AON) method to develop a project schedule.

• Describe how to adjust a project’s sequence logic using leads, lags, and alternative dependencies.

• Identify the critical path using both the two-pass and enumeration methods, and identify all float.

• Depict a project schedule on a Gantt chart both by hand and using MS Project 2013, showing the critical path and all float.

© Ra yw

oo /S hu tte rs to ck .c om

170

Topics:

• Plan schedule management

• Define activities

• Sequence activities

• Estimate activity durations

• Develop schedule

One risk using the second approach is that content development projects often have schedules with long durations, even when adequately resourced. The result: Months later, software has still not been adopted due to lack of content. Sadly, this is all too common in our industry, which is why we place great importance on a well-defined schedule and resource plan for content development.

Another critical success factor is users who have learned, retained, and mastered the skills of working with the software. This should be easy, but it’s not. Our products are often purchased expressly for people who are pressed for time, since improved efficiency is a major benefit. Unfortunately, I see people attend training and then forget everything they’ve learned because other priorities prevent them from spending the time needed to practice and master new skills. As a result, training investments go to waste because learning is not retained.

One solution that has worked well for our customers is establishing a scope that can be completed in a schedule of four to eight weeks. We schedule a project kickoff meeting to identify a project leader, tasks, and timeline. Team members are educated on goals, critical success factors, and typical issues and challenges. Once gaining consensus on an action plan, I communicate it to both the project leader and sponsor to ensure alignment. Then the team and I meet regularly to monitor progress. If there are issues, we develop plans to resolve them and follow up at subsequent meetings.

Establishing scope that can be accomplished in a 30- to 60-day schedule helps our clients get started using their web-based applications faster. By using them, people get motivated. Therefore, customers are more likely to allocate adequate resources and time to subsequent project phases that address the full scope of their content and training requirements, no matter how many months or years that may take. Project planning for the future becomes more realistic, improving the odds of success. Meanwhile, clients are achieving return on their software investments.

Carol A. Abbott, training specialist, Sant-Kadient

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative Closure

Planning Executing Closing RealizingInitiating

RealizedResultTo Proceed

PMBOK® Guide

171

7-1 Plan Schedule Management As is true of other project planning areas, planning for time is iterative. A project man- ager and team usually develop as much of the schedule as they can based upon the information in the work breakdown structure (WBS). The communication plan, require- ments traceability matrix, and scope statement are often either complete or at least in draft form at this point. Once a project is scheduled, the budget can be formulated, re- source needs can be identified and resources assigned, risks can be identified and plans developed to deal with the identified risks, and a quality management plan can be cre- ated. In many projects, these are not all treated as discrete activities, and some of them may be performed together. However, for clarity, each of these planning processes will be described individually.

The building blocks of a project schedule are activities. An activity is “a distinct, scheduled portion of work performed during the course of a project.”1 For activities to be useful as schedule building blocks, they should have the following characteristics:

• Clear starting and ending points • Tangible output that can be verified • Scope small enough to understand and control without micromanaging • Labor, other costs, and schedule that can be estimated and controlled • A single person who can be held accountable for each activity (even if more than

one person does the work, one person should be responsible)2

Since activities represent work that needs to be performed, they should be listed in a verb-noun format, such as “prepare budget,” “build frame,” “test code,” “transmit infor- mation,” “analyze data,” and “develop plan.” Each activity should be clearly differentiated from other activities, so it is often helpful to write the activities in verb-adjective-noun format, such as “write draft report” and “write final report.”

The Project Management Institute (PMI) has divided project time management into the following seven work processes.

1. Plan schedule management—the process of establishing the policies, procedures, and documentation for planning, developing, managing, executing, and controlling the project schedule

2. Define activities—the process of identifying the specific actions that need to be performed to produce the project deliverables

3. Sequence activities—the process of identifying and documenting dependencies among the project activities

4. Estimate activity resources—the process of estimating the type and quantities of material, human resources, equipment, or supplies required to perform each activity

5. Estimate activity durations—the process of approximating the number of work periods needed to complete individual activities with estimated resources

6. Develop schedule—the process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule

7. Control schedule—the process of monitoring the status of the project activities to update project progress and managing changes to the schedule baseline to achieve the plan3

Planning schedule management, defining activities, sequencing activities, estimating activity durations, and part of developing schedules will be covered in this chapter. Estimating activity resources and the remainder of developing schedules will be discussed in Chapter 8 (Resourcing Projects). Chapter 14 (Determining Project Progress and Results) will focus on controlling the schedule.

172 Part 2 Planning Projects

7-2 Purposes of a Project Schedule Projects are undertaken to accomplish important business purposes, and people often want to be able to use the project results as quickly as possible. Many specific questions such as the following can be answered by having a complete and workable schedule:

• When will the project be complete? • What is the earliest date a particular activity can start, and when will it end? • What activity must begin before which other activities can take place? • What would happen if a delivery of material was one week late? • Can a key worker take a week of vacation the first week of March? • If one worker is assigned to do two activities, which one must go first? • How many hours do we need from each worker next week or month? • Which worker or other resource is a bottleneck, limiting the speed of our project? • What will the impact be if the client wants to add another module? • If I am willing to spend an extra $10,000, how much faster can the project be

completed? • Are all of the activities completed that should be by now?

7-3 Historical Development of Project Schedules Throughout history, projects have been performed, but many early projects such as cathedrals in Europe took decades or longer to complete. As competition drove the need for more rapid completion, systematic methods were developed for scheduling projects.

In the 1950s, two project scheduling methods were developed: program evaluation and review technique (PERT) and critical path method. The critical path method (CPM) is “a method used to estimate the minimum project duration and determine the amount of scheduling flexibility on the logical network paths within the schedule model.”4 Both CPM and PERT were founded on the concepts still in place today of iden- tifying activities, determining their logical order, and estimating the duration for each. Networks representing the activities were developed and the schedule calculated. Each of the techniques also boasted a capability the other did not possess.

PERT was developed in the Navy’s Special Program Office because the Navy was developing the large and complex Polaris Weapons System. To complete it as quickly as possible, many activities needed to be worked on simultaneously. Furthermore, many aspects of the Polaris used unproven technology. There was considerable uncertainty regarding how long some of the new technology would take to develop. PERT enabled project managers to estimate the most likely amount of time needed to complete a proj- ect, and the level of confidence in completing it in a particular time. This has proven to be useful in research and development projects involving individual activities that are hard to estimate precisely. How uncertainty in project schedules is handled by PERT will be discussed more in Section 7.9.

CPM was developed in the Engineering Services Division of DuPont. DuPont needed to plan large projects when it built and refurbished enormous plants. Planners using CPM estimated the time for each individual work activity using a single time estimate. The focus was on understanding the longest sequence of activities, which determined how long the project would take. CPM enabled project managers to ask what-if ques- tions such as “If the project needs to be finished three weeks early, which activities should be speeded up and how much will it cost?” This proved to be useful in the con- struction industry where delays such as rain often necessitate the acceleration of a project.

Chapter 7 Scheduling Projects 173

PERT and CPM originally used a method for displaying the work activities called activity on arrow (AOA) or arrow diagramming method (ADM), in which schedule activities are represented by arrows and connected at points called nodes. Because it is often confusing to draw an accurate AOA network, this method is rarely used today. The more common method used today is called activity on node (AON) or the precedence diagramming method (PDM). AON or PDM is “a technique in which the scheduled activities are represented by nodes and are graphically linked by one ormore logical relationships to show the sequence in which the activities are performed.”5 A small project schedule is shown in Exhibit 7.1 with work activities A through D connected by arrows showing logical relationships (A must be complete before B and C can begin and both B and C must finish before D can begin).

The basic logic of these techniques still serves as the backbone of many project sche- dules today. However, other advances have added to scheduling capability. One is that since computers are so much more powerful and easier to use, many additional features have been added to project schedules. Another trend is that with many organizations operating in a “lean” mode, resource limitations rather than just the logical order of activities are a major determinant of many project schedules.

7-4 How Project Schedules Are Limited and Created One way to understand project schedules and how they are constructed is to understand that five factors may limit how fast a project can be completed:

1. Logical order 2. Activity duration 3. Resource availability 4. Imposed dates 5. Cash flow

The first factor is the logical order in which activities need to be completed. For example, one needs to dig a hole before cement can be poured in it. This is covered in the section on sequencing activities. The second factor is how long each individual activ- ity will take. This is discussed in the section on estimating activity duration. It includes methods for estimating durations, problems with estimates, and remedies to those pro- blems. The third factor is how many key resources are available at specific points in the project. For example, if six rooms were available to be painted at the same time, and fewer than six painters were available, progress would be slowed. This is discussed in

EXHIBIT 7.1 AON FORMAT SCHEDULE EXAMPLE

A

B

C

D

174 Part 2 Planning Projects

Chapter 8 in the section on resource availability. The fourth factor is imposed dates. For example, a project working on a government contract may not be able to start until the government’s new fiscal year, which starts on October 1. Chapter 8 also has a section on imposed dates. The fifth and final factor is cash flow. Projects may not start until money is approved, but progress may also be slowed until enough revenue arrives to cover expenses. This is covered in Chapter 9.

Because project schedules are limited by these five factors, creating a realistic schedule is an iterative process. A common method of developing the schedule is to first identify all of the activities and then determine the logical order by creating a network diagram. Once the order is determined, resources are assigned to each activity and an estimate of the time required for that activity is made. If the assigned resource is not available when the activity is scheduled, then an adjustment of some type is made. The schedule can be computed with all of this information. Next, it is time to compare the emerging schedule with any imposed dates and cash flow estimates. Any inconsistencies may cause the team to adjust the schedule. Other factors often need to be considered, such as quality demands and risk factors. When all of these have been planned, the final schedule can be approved.

The pressure to complete a project as quickly as possible is often great. The sponsor or customer may try to dictate a schedule before anyone knows whether it is feasible or not. Before agreeing, the project manager must first understand what makes sense in terms of a schedule before she is in a position to know whether to accept a sponsor’s suggestions or to argue about why it may be impractical. A project manager has the ethical responsibility to determine a schedule that is possible to achieve, persuade all stakeholders that the schedule makes sense, and then see to it that the project is deliv- ered according to that agreed-upon schedule.

The remainder of this chapter and the other planning chapters describe in detail how to plan each of these, culminating in an approved schedule and project plan that all stakeholders believe is reasonable. The project manager is then accountable to deliver the project on schedule. That project delivery is the essence of the final four chapters of this book.

7-5 Define Activities The first process in developing a project schedule is to define all of the work activities. The last row of a WBS represents the work packages—lowest-level deliverables. Now is the time to ask, “What work activities must be completed to create each of the project deliverables?” Exhibit 7.2 shows a WBS with the deliverables identified by numbers 1 through 9, and Exhibit 7.3 shows the same project with the activities required to create the deliverables listed. Notice that project management is the first section of the WBS and that each row in both exhibits has a unique number. The number of each activity shows the deliverable it helps to create. For example, activity 4.2, contact local bands, is needed for deliverable 3, entertainment.

As teams define activities, they want to be careful not to omit any. It is a good idea to have someone on your project team play devil’s advocate to challenge the team to identify additional activities. It is better to identify activities that do not need to be accomplished than to forget activities that will need to be added later. The team may think all of the activities have been identified; however, when the next process is performed—activity sequencing—it may become obvious that some activities have been forgotten. Another activity can always be added later. Remember the schedule will not be approved until all of the related planning is in place. It is better to discover a missing activity in the later stages of planning than after the schedule is approved. Activities that

Chapter 7 Scheduling Projects 175

need to be added after the final schedule is approved will add time and money to the proj- ect, perhaps driving it over budget and causing it to fall behind schedule.

If the project being planned is similar to previous projects, the team can look at those projects both for defining activities and for other planning that follows. Some organiza- tions have templates or checklists for certain types of projects that can be used as a start- ing point in defining activities. Regardless of the starting point, team members need to keep asking how this project is different from previous ones. Often, a new project includes a few unique activities that need to be included.

In addition to the activity list, the project milestones should be listed. A milestone is an important point in a project schedule that the project sponsor and manager want to use as a checkpoint. A few major milestones are often identified in the project charter, but quite commonly more milestones are identified during project schedule planning. Common milestones include completion of a major deliverable, completion of a critical activity, and the time just before a large amount of money needs to be committed to the project. A team may also decide to put a milestone at a merging point in the project schedule where multiple activities need to be complete before progress can continue. The common denominator in each of these decisions is to identify a few key points in the life of a project where management can determine if the project is progressing the way they want. A milestone list is shown in Exhibit 7.4. Note that the line numbers assigned to the milestones are one greater than the line numbers of the activities that must be completed for each milestone. For example, the milestone “Information needs finalized” (item 3.6) represents the point in time that all of the information-related activ- ities (items 3.1 through 5.5) are completed. For clarity, items 3.1 through 3.5 have been imported from Exhibit 7.3 and set in a lighter font. Notice also that the verb choice on the milestones is past tense, such as “confirmed,” “finalized,” and so on. This indicates that the activities leading up to each milestone must be complete.

7-6 Sequence Activities Once the activities have been identified, it is time to determine the logical order in which they can be accomplished. A common method of determining this sequence is to put each defined activity on a Post-it Note and to display them on a large work space (white board, several flip chart sheets on a wall, etc.). The activities that are expected to be accomplished early in the project can be placed on the left portion of the work surface, those activities expected to be accomplished midway in the project near the middle, and those expected to be last on the right. Then, one person can serve as a facilitator asking,

EXHIBIT 7.2 WORK BREAKDOWN STRUCTURE WITH DELIVERABLES ONLY

COLLEGE FUNDRAISER PROJECT

1. Project Management 2. Location 3. Information 4. Entertainment 5. Safety 6. Parking 7. Food 8. Sanitation 9. Volunteers

176 Part 2 Planning Projects

EXHIBIT 7.3 WORK BREAKDOWN STRUCTURE WITH ACTIVITY LIST ADDED

COLLEGE FUNDRAISER PROJECT

1. Project Management 2. Location

2.1 CONTACT UNIVERSITY FOR PERMISSION

2.2 DETERMINE IDEAL LOCATION TO MEET CAPACITY

2.3 DETERMINE ALTERNATIVE LOCATION IN CASE OF INCLEMENT WEATHER

3. Information

3.1 PROVIDE TEAM INFORMATION

3.2 PRODUCE PRE-EVENT ADVERTISEMENTS

3.3 DISPLAY WELCOME SIGNS AT ALL ENTRANCES

3.4 SET UP SIGN-IN TABLE

4. Entertainment

4.1 FIND INFORMATION ABOUT LOCAL NOISE ORDINANCES

4.2 CONTACT LOCAL BANDS

4.3 SET UP STAGE, SPEAKERS, FUN BOOTHS

5. Safety

5.1 DETERMINE LIGHTING NEEDS

5.2 CONTACT LOCAL FIRE DEPARTMENT (EMS)

5.3 CONTACT LOCAL POLICE DEPARTMENT

5.4 OBTAIN PERMISSION TO USE WALKIE-TALKIES

5.5 COORDINATE FIRST AID BOOTH

6. Parking

6.1 FIND ADEQUATE LOTS TO ACCOMMODATE CAPACITY

6.2 COORDINATE SHUTTLE SERVICE FROM LOTS TO SITE

6.3 RESERVE SPECIAL PLACES FOR HANDICAPPED

7. Food

7.1 CONTACT FOOD/BEVERAGE VENDORS FOR CONCESSIONS

7.2 MAKE GOODIE BAGS FOR CHILDREN

7.3 ORDER SUFFICIENT WATER

8. Sanitation

8.1 PROVIDE TRASH RECEPTACLES

8.2 PROVIDE ADEQUATE NUMBER OF PORTA-JOHNS

8.3 COORDINATE POST-EVENT CLEAN-UP

8.4 PURCHASE PAPER PRODUCTS AND SOAP

9. Volunteers

9.1 RECRUIT VOLUNTEERS

9.2 PRODUCE A MASTER VOLUNTEER ASSIGNMENT LIST

9.3 MAKE NAMETAGS FOR ALL VOLUNTEERS

Chapter 7 Scheduling Projects 177

“What activity or activities can be started right away and do not depend on any others?” Once one or more of these initial activities have been identified, the facilitator asks, “What activity or activities can we start now?” The initial activity is called a predecessor activity, which is “an activity that logically comes before a dependent activity in a schedule.”6 The following activity is called a successor activity, which is “a dependent activity that logically comes after another activity in a schedule.”7 The facilitator then places the successor activity after its predecessor and draws an arrow to show the rela- tionship. The team continues with this analysis until all activities have been placed on the work surface with arrows showing the predecessor–successor relationships. At that time, the team should mentally go through the network to ensure that no “dead-ends” are present where the chain of arrows from the project start to end is broken.

Exhibits 7.5 and 7.6 illustrate sequencing activities with the simple example of upgrading a product. The activities are identified in Exhibit 7.5, and their sequence is shown in Exhibit 7.6. The first activity is to determine the product features. As soon as that is done, two other activities can be performed.

This product upgrade example illustrates the basic logic of showing predecessor– successor dependency relationships. Dependencies can be either mandatory or discre- tionary. A mandatory dependency is “a relationship that is contractually required or

EXHIBIT 7.4 WORK BREAKDOWN STRUCTURE WITH MILESTONE LIST

COLLEGE FUNDRAISER PROJECT

1. Project Management

2. Location

2.1 LOCATION CONFIRMED

3. Information

3.1 PROVIDE TEAM INFORMATION

3.2 PRODUCE PRE-EVENT ADVERTISEMENTS

3.3 DISPLAY WELCOME SIGNS AT ALL ENTRANCES

3.4 SET UP SIGN-IN TABLE

3.5 DISPLAY SIGNS WITH RULES

3.6 INFORMATION NEEDS FINALIZED

4. Entertainment

4.1 BAND CONTRACT SIGNED

4.2 ENTERTAINMENT ARRANGED

5. Safety

5.1 SAFETY REQUIREMENTS COMPLETED

6. Parking

6.1 ALL PARKING NEEDS ARRANGED

7. Food

7.1 FOOD AND BEVERAGES READIED

8. Sanitation

8.1 ALL SANITATION NEEDS IN PLACE

9. Volunteers

9.1 VOLUNTEERS PREPARED

178 Part 2 Planning Projects

inherent in the nature of the work.”8 A discretionary dependency is “a relationship that is established based on knowledge of best practices… where a specific sequence is desired.”9 A mandatory example is “the hole must be dug before concrete can be poured into it” and a discretionary example is “past experience tells us it is better to delay designing product graphics until the marketing plan is complete.” The team needs to include all of the mandatory dependencies and use its judgment on which discretionary dependencies to include. Most teams include no more dependencies than necessary since more dependencies give the project manager fewer choices as the project progresses.

7-6a Leads and Lags Exhibit 7.6 shows the most common type of logical dependency, finish-to-start (FS), which is “a logical relationship in which a successor activity cannot start until a prede- cessor activity has finished.”10 That means, in this example, that the marketing plan must be completely designed before the graphics design starts. However, maybe the graphics design could start five work days before the marketing campaign design is complete. This could be modeled as a lead, which is “the amount of time whereby a successor activity can be advanced with respect to a predecessor activity.”11 With this lead of five work days, the arrow connecting design marketing campaign and design graphics would

Arranging adhesive notes on a wall allows team members to arrange project tasks in predecessor– successor relationships.

© Yu ri Ar cu rs /S hu tte rs to ck .c om

EXHIBIT 7.5 ACTIVITY LIST FOR PRODUCT UPGRADE PROJECT

• Determine product features • Acquire prototype materials • Produce prototype • Design marketing campaign • Design graphics • Conduct marketing • Perform sales calls

Chapter 7 Scheduling Projects 179

still represent a finish-to-start relationship, only with a five-day overlap during which time people could work on both activities. Leads are helpful if a project needs to be com- pleted quickly since they show how a successor activity can be overlapped with its prede- cessor instead of waiting until the predecessor is completely finished.

Perhaps in the example, the sales people are more effective if the design graphics are completed 10 days before they start performing sales calls so they have extra time to bet- ter understand the graphics. This could be shown by a lag, “the amount of time whereby a successor activity is required to be delayed with respect to a predecessor activity.”12 In this example, the arrow connecting design graphics and perform sales calls would still represent a finish-to-start relationship, only with a 10-day gap during which no one could work on either activity.

7-6b Alternative Dependencies Other types of relationships exist besides finish-to-start, including the following:

• Finish-to-finish (FF) is “a logical relationship in which a successor activity cannot finish until a predecessor activity has finished.”13 For example, perhaps the graphics could be designed while the marketing campaign is being designed, but could not be completed until the marketing campaign is completed.

• Start-to-start (SS) is “a logical relationship in which a successor activity cannot start until a predecessor activity has started.”14 For example, perhaps the graphics design could not start until the design marketing campaign started.

EXHIBIT 7.6 NETWORK FOR PRODUCT UPGRADE PROJECT

Acquire prototype materials

Design marketing campaign

Design graphics

Conduct marketing

Produce prototype

Perform sales calls

Determine new

product features

180 Part 2 Planning Projects

• Start-to-finish (SF) is “a logical relationship in which a successor activity cannot finish until a predecessor activity has started.”15 This is the least used relationship. An example is for a project to replace an old system where the new capability must be started before the old one is completely discontinued.

7-7 Estimate Activity Duration Once the activities have been defined and sequenced, both estimating activity resources and estimating activity durations can take place. Duration is “the total number of work periods (not including holidays or other nonwork periods) required to complete a sched- ule activity, usually expressed as workdays or workweeks.”16

It makes sense to identify the people who will work on each activity as soon as possible since they often have the most knowledge about how to actually do the work and how long it will take. Also, the length of time to perform an activity is often dependent upon who will do that work. We discuss resource assignments in Chapter 8.

When estimating how long activities are expected to take, each activity should be evaluated independently. All assumptions and constraints made when estimating should be documented since if one of these changes, it could change the estimate. For the first estimate of each activity, a normal level of labor and equipment and a normal work week should be assumed. If overtime is planned right from the start, the project manager is unlikely to have much flexibility if the schedule needs to be accelerated. For each activity, the output to be created and the skill level required to perform the work should be identified. Any predetermined completion date can be disregarded at this point. Negotiation with a customer or supplier may be necessary, but the project manager needs to understand what is reasonable under normal circum- stances before entering those negotiations. When a past project is being used as a guide, the actual time it took to perform the activities should be used, not the time that was initially estimated.

Exhibit 7.7 is a continuation of the product upgrade example with the times estimated for individual activities. Note that the estimated times in this example are in work days. It is important to keep time estimates in the same unit of measure, be it hours, days, weeks, or another measure. Exhibit 7.8 includes suggestions for creating realistic time estimates.

EXHIBIT 7.7 ACTIVITY DURATION ESTIMATE EXAMPLE

TIME ESTIMATE IN WORK DAYS ACTIVITY NAME

5 Determine new product features

20 Acquire prototype materials

10 Produce prototype

10 Design marketing campaign

10 Design graphics

30 Conduct marketing

25 Perform sales calls

Chapter 7 Scheduling Projects 181

7-7a Problems and Remedies in Duration Estimating Many factors can impact the accuracy of activity duration estimates. A list of potential problems, remedies for those problems, and the chapter in which each is discussed is shown in Exhibit 7.9. These techniques are not mutually exclusive. Many organizations use several of them; however, few organizations use them all. It is important for business students to be aware of these techniques and their potential benefits, since each is used by some companies. Many companies customize the mechanics of how they use these techniques.

7-7b Learning Curves The concept behind learning curves is simple: The more times a person performs an activity, the better and faster he or she becomes. The reason this concept is sometimes applied to activity duration estimating is that the rate of improvement can be studied and predicted. Therefore, on types of projects where certain activities are performed many times, a project planner can predict how long it will take each time to perform the activity. The rate of improvement can vary widely depending on many factors, such as:

• How much the culture of the organization stresses continual improvement • How much skill is involved in the activity • How complex that activity is • How much of the activity is dependent on the worker versus dictated by the pace of

a machine

EXHIBIT 7.8 SUGGESTIONS FOR CREATING REALISTIC TIME ESTIMATES

1. Verify all time estimations with the people doing the work. Or, even better, have the people doing the work provide the initial estimates of the activity completion time.

2. Estimate times of completion of work without initial reference to a calendar. Just consider how long you believe each activity will take under normal working conditions.

3. Make sure all time units are identical: work days, work weeks, months (consider time off for company holidays), or another measure.

4. Some people tend to estimate optimistically. Keep in mind the following time constraints:

• Unexpected meetings • Learning curves • Competing priorities • Vacation • Resources or information not available on time

• Inaccuracy in work instructions • Interruptions • Emergencies and illness • Rework

5. Contrary to point 4, some people estimate pessimistically in order to look good when they bring their project or activities in under budget and under schedule. Try to develop an understanding of the estimator’s experience along with their optimistic or pessimistic tendencies and try to encourage balance in estimates.

6. Don’t initially worry about who is going to do the work, and don’t worry about the mandatory deadline. Figure out a realistic estimate first, and then figure out what to cut later.

7. When using the actual time from a previous project, adjust the estimate up or down based upon size, familiarity, and complexity differences.

182 Part 2 Planning Projects

The amount of time necessary to perform an activity is calculated based upon a rate of improvement that occurs every time the number of repetitions doubles. For example, if the learning rate is 80 percent and the first time the activity was performed (by pro- ducing the first unit) it took 100 minutes, then after doubling the volume, the second unit would require 80 minutes. To double the repetitions again, the fourth unit would require 64 minutes. The time estimates for each time the activity is performed can be found in learning curve tables such as the one shown in Exhibit 7.10. Notice that the rate of learning is very important since more rapid learning leads to much faster perfor- mance times for succeeding times an activity is performed.

EXHIBIT 7.9 ACTIVITY DURATION ESTIMATING PROBLEMS AND REMEDIES

POTENTIAL ACTIVITY DURATION ESTIMATING PROBLEM REMEDY CHAPTER

Omissions Refining scope and WBS Checklists, templates, devil’s advocate Lessons learned

6 7 15

General uncertainty in estimate Rolling wave planning Reverse phase schedule Learning curve Identify and reduce sources of uncertainty Manage schedule aggressively

6 8 7 10, 11

14

Special cause variation Risk analysis Resolve risk events

4, 10 14

Common cause variation PERT Monte Carlo Project buffer

7 7 8

Merging (multiple predecessors) Milestones Reverse phase schedule Feeding buffer Manage float

4, 7 8 8 14

Queuing Staggering project start dates Resource leveling Resource buffer

2 8 8

Multi-tasking Prioritizing projects Carefully authorize start of non- critical activities

2 8, 14

Student syndrome (starting late) Float Critical path meetings

7 14

Not reporting early completion of rework Project culture Project communications Contract incentives Project leadership Progress reporting

3 5 11 13 14

Source: Adapted from Larry Leach, “Schedule and Cost Buffer Sizing: How to Account for the Bias between Project Performance and Your Model,” Project Management Journal 34 (2) (June 2003): 44.

Chapter 7 Scheduling Projects 183

For consumers, one result when an industry has a steep learning curve is rapidly declining prices. People expect prices to decline for new electronics and other consumer items. As a project manager, you need to make sure to also plan for the amount of learning that may take place. Further, as a project manager, you need to create and sustain the environment that encourages and expects rapid learning so you can become ever more competitive.

On agile projects, duration estimates improve as early iterations are completed. Armed with more specific knowledge of how long certain activities take, later iterations can be estimated more accurately. However, since the estimates are for a specific dura- tion of generally two- or four-week iterations, the estimate is for velocity “a measure of a team’s productivity rate at which deliverables are produced, validated, and accepted within a predetermined interval.”17 This means the project manager estimates how much can get done in the next iteration.

7-8 Develop Project Schedules You need to complete all of the scheduling processes discussed up to this point even if you use Microsoft Project or another scheduling tool. At this point, you have defined, sequenced, and estimated the duration for all the schedule activities. Now is the time to use all of this information to develop a project schedule. Once the schedule is developed based upon this information, resource needs and availability and cash flow constraints often extend the proposed schedule, while imposed date constraints often suggest the need for schedule compression.

The first major task in developing the project schedule is to identify the critical path, which is “the sequence of activities that represents the longest path through the project, which determines the shortest possible duration.”18 Because it is the longest sequence of activities, the critical path determines the earliest possible end date of the project. Any time change to an activity on the critical path changes the end date of the entire project. If the project manager changes an activity on the critical path to start at a later date, then the whole project will end at a later date. If the amount of work for an activity on the critical path is increased, then the whole project will end at a later date. If, on the other hand, an activity on the critical path is performed faster than planned, the entire project could be completed sooner. The critical path gets its name not because it is the most critical in terms of cost, technical risk, or any other factor, but because it is most critical in terms of time. Since virtually everyone wants her projects completed at the promised time, the critical path gets a great deal of attention.

The two methods for determining the critical path are the two-pass and enumeration methods. Each uses the same activity identification, duration estimate, and activity sequencing data but processes the data in a different manner. While both determine the critical path, each also determines other useful information.

A G I L E

EXHIBIT 7.10 LEARNING CURVE TABLE

ACTIVITY 60% 70% 80% 90%

1 100 100 100 100

2 60 70 80 90

4 36 49 64 81

8 21.6 34.3 51.2 72.9

184 Part 2 Planning Projects

7-8a Two-Pass Method The two-pass method is used to determine the amount of slack each activity has. To per- form this method, two logical passes should be made through the network. The first pass is called the forward pass. The forward pass is “a critical path method technique for calculating the early start and early finish dates by working forward through the schedule model from the project start.”19 On the forward pass, the project team starts at the beginning of the project and asks how soon each activity can begin and end. If the proj- ect is being scheduled with software, actual calendar dates are used. Often, when calcu- lating the schedule by hand, a team starts at date zero. In other words, the first activity can begin after zero days. To envision this, consider Exhibit 7.11, where all of the previ- ously determined information has been displayed.

A legend is shown in the lower right corner of Exhibit 7.11. This explains each bit of information that is displayed for each activity. For example, the first activity name is “Determine new product features.” The estimated duration for this activity is five days. This activity is coded with the letter A. The four corners of each block display four important times for each activity:

• Early start date (ES)—“the earliest possible point in time on which uncompleted portions of a schedule activity can start, based upon the schedule network logic, the data date, and any schedule constraints.”20

• Early finish date (EF)—“the earliest possible point in time on which uncompleted portions of a schedule activity can finish, based upon the schedule network logic, the data date, and any schedule constraints.”21

EXHIBIT 7.11 TWO-PASS EXAMPLE SCHEDULE SET UP

Acquire prototype materials

20

Design marketing campaign

10

Design graphics

10

Conduct marketing

30

Produce prototype

10

Perform sales calls

25

Legend

ES

LS

EF

LF

Float Activity name

Duration

0 A

B

D

C

G

F

E

Activity code

Determine new

product features

5

Chapter 7 Scheduling Projects 185

• Late start date (LS)—“the latest possible point in time in which uncompleted portions of a schedule activity can start, based upon the schedule network logic, the project completion date, and any schedule constraints.”22

• Late finish date (LF)—“the latest possible point in time when the uncompleted portions of a schedule activity can finish based upon the network logic, the project completion date, and any schedule constraints.”23

“Determine new product features,” for example, has an early start time of zero since it can begin as soon as the project is authorized.

FIRST OR FORWARD PASS The first pass is then used to calculate the early finish, which is the early start plus the estimated duration (ES + Duration = EF). In this case, 0 + 5 = 5 means the activity “Determine new product features” can be completed after five days. Each activity that is a successor can start as soon as its predecessor activity is complete. Therefore, the next two activities can each start after five days. To calculate the early finish for each of these activities, add its duration to the early start of 5, for early completion times of 25 and 15, respectively. The difficult part of calculating the first pass comes when an activity has more than one predecessor. For example, “Perform sales calls” cannot begin until all three preceding activities (“Produce prototypes,” “Design gra- phics,” and “Conduct marketing”) are complete. Therefore, its early start is 45. This is true even though “Produce prototypes” and “Design graphics” have earlier finish times, because “Conduct marketing” cannot be completed until day 45. The later time is always taken. The results of the first pass are shown in Exhibit 7.12. Note that the earliest the entire project can be completed is 70 work days.

EXHIBIT 7.12 SCHEDULE EXAMPLE FIRST PASS COMPLETE

5 15

Design graphics

10

Legend

0 5A

B

D

5 25

25 35C

15 25

15 45

E G

F

45 70

Activity code ES

LS

EF

LF

Float Activity name

Duration

Acquire prototype materials

20

Design marketing campaign

10 Conduct

marketing 30

Produce prototype

10

Perform sales calls

25

Determine new

product features

5

186 Part 2 Planning Projects

SECOND OR BACKWARD PASS The second pass is sometimes called the backward pass. The backward pass is “a critical path method technique for calculating the late start and late finish dates by working backward through the schedule model from the project end date.”24 When performing the backward pass, teams start at the end and work backward asking, “How late can each activity be finished and started?” Unless there is an imposed date, the late finish for the last activity during planning is the same as the early finish date. In our example, we know the earliest we can finish the entire project is 70 days, so we will use that as the late finish date for the last activity. If the activity “Per- form sales calls” must end no later than 70 and it takes 25 days, then it must start no later than day 45. In other words, calculate the late start by subtracting the duration from the late finish (LF – duration = LS). The confusing part of calculating the second pass is when there is more than one successor. In Exhibit 7.13, one place this occurs at the first activity, “Determine new product features,” since two activities are immediate successors. Enough time must be left for all of the successors, so whichever one must start soonest dictates the late finish date of the predecessor. In this example, “Design marketing campaign” must start no later than after day 5; therefore, five days is the late finish for the first activity.

FLOAT AND THE CRITICAL PATH Once both passes are complete, the early and late start dates for every activity and the amount of time the entire project will take to com- plete are known. However, the team also wants to know the critical path. This is calcu- lated easily by first determining each activity’s float (sometimes float is called slack).

EXHIBIT 7.13 SCHEDULE EXAMPLE SECOND PASS COMPLETE

5 15

Legend

0 5

0 5

A

B

D

5 25

25 35C

15 25

15 45

5 15

15 35

35 45

35 45

15 45

E G

F

45 70

45 70

Activity code ES

LS

EF

LF

Float Activity name

Duration

Design graphics

10

Acquire prototype materials

20

Design marketing campaign

10 Conduct

marketing 30

Produce prototype

10

Perform sales calls

25

Determine new

product features

5

Chapter 7 Scheduling Projects 187

Float can be total float, which is “the amount of time a schedule activity may be delayed or extended from its early start date without delaying the project finish date”25 or free float, which is “the amount of time a schedule activity can be delayed without delaying the early start of any successor.”26 A project manager wants to know how much float each activity has in order to determine where to spend her time and attention. Activities with a great deal of float can be scheduled in a flexible manner and do not cause a man- ager much concern. Activities with no float or very little float, on the other hand, need to be scheduled very carefully.

Float is calculated by the equation Float = Late start – Early start (Float = LS – ES). The critical path is the sequence of activities from start to finish in the network that have no float. In Exhibit 7.14, activities A, D, F, and G have no float and, therefore, create the critical path. It is typical to mark the critical path in red or in boldface to call attention to it. Activities B, C, and E each have float and are not on the critical path. If activity B is delayed, it will delay the start of activity C; therefore, activity B has total float. While activity B can be delayed up to 10 days without delaying the entire project, any delay to activity B would delay the start of activity C. On the other hand, activities C and E can be delayed by 10 and 20 days, respectively, without causing any other activity to be delayed. Therefore, their float is free float—impacting neither the overall project nor any activity in it.

Project managers carefully monitor the critical path activities. They also closely watch activities with little float—think of these as “near-critical” activities. A project with many

EXHIBIT 7.14 TWO-PASS COMPLETE SCHEDULE EXAMPLE

0

0

0

10

10

200

ES

LS

EF

LF

Float Activity name

Duration

5 15

Legend

0 5

0 5

A

B

D

5 25

25 35C

15 25

15 45

5 15

15 35

35 45

35 45

15 45

E G

F

45 70

45 70

Activity code

Design graphics

10

Acquire prototype materials

20

Design marketing campaign

10 Conduct

marketing 30

Produce prototype

10

Perform sales calls

25

Determine new

product features

5

188 Part 2 Planning Projects

activities that have little float is not very stable. Even small delays on near-critical activi- ties can change the critical path. Project managers can sometimes “borrow” resources from an activity with plenty of float to use first on an activity that is either already criti- cal or nearly critical. Chapter 8 discusses resource scheduling in detail.

7-8b Enumeration Method The second method of determining the critical path is the enumeration method. To complete this, a person lists or enumerates all of the paths through the network. The advantage of this method is that since all of the paths are identified and timed, if a team needs to compress the project schedule, they will know both the critical path and the other paths that may be nearly critical (or those with very little float). It is imperative to keep track of both critical and near-critical paths when compressing a schedule. In Exhibit 7.15, three paths are identified, and the total duration for each is calculated. ADFG is the critical path with an expected duration of 70 days, just as was determined with the two-pass method. Now, however, we also know that path ABCG is expected to take 60 days (10 less than the critical path), and path ADEG is expected to take 50 days (20 less than the critical path).

EXHIBIT 7.15 ENUMERATION METHOD EXAMPLE SCHEDULE

Legend Activity code

Path ABCG ADEG ADFG

Total Duration 60 50 70

Activity name

Duration

Acquire prototype materials

20

Design marketing campaign

10

Design graphics

10

Conduct marketing

30

Produce prototype

10

Perform sales calls

25

A

B

D

C

G

F

E Determine

new product features

5

Chapter 7 Scheduling Projects 189

7-9 Uncertainty in Project Schedules On some projects, it is easy to estimate durations of activities with confidence. On others, so many uncertainties exist that managers have far less confidence in their ability to accurately estimate. However, project managers still need to tell sponsors and clients how long they believe a project will take and then be held accountable for meeting those dates. One common strategy for handling this potential problem is to construct the best schedule possible and then manage the project very closely. A different strategy is to estimate a range of possible times each individual activity may take and then see what impact that has on the entire schedule. PERT and Monte Carlo are two methods some- times used for this approach.

7-9a Program Evaluation and Review Technique Program evaluation and review technique was developed during the 1950s to better understand how variability in the individual activity durations impacts the entire project schedule. To use PERT, a project team starts by sequencing the activities into a network as described above. However, instead of creating one estimate for the time to complete each activity, they would create three estimates: optimistic, most likely, and pessimistic. For example, the first activity, “Determine new product features,” will most likely take five days, but it could take as little as four days if everything works well and as long as 12 days if a variety of things interfere. The person scheduling the project then calculates the estimated time to perform each activity as shown in Exhibit 7.16 using the following equation:

Estimated time ¼ Optimisticþ 4 ðMost likelyÞ þ Pessimistic 6

Therefore; for the first activity; the estimated time ¼ 4þ 4ð5Þ þ 12 6

¼ 6

The primary advantage of PERT is that it helps everyone realize how much uncer- tainty exists in the project schedule. When people use single time estimates, sometimes there is a tendency to believe that the estimates foretell exactly what will happen. On many projects, a great deal of uncertainty exists, and PERT helps to make this visible.

EXHIBIT 7.16 PERT TIME ESTIMATE EXAMPLE

ACTIVITY OPTIMISTIC MOST LIKELY PESSIMISTIC EXPECTED

Determine new product features

4 5 12 6

Acquire prototype materials

16 20 30 21

Produce prototype 8 10 12 10

Design marketing campaign

9 10 14 10.5

Design graphics 6 10 20 11

Conduct marketing 28 30 50 33

Perform sales calls 20 25 30 25

190 Part 2 Planning Projects

In addition to making the overall uncertainty more visible, calculations often show that the expected time is actually longer than the most likely time. That is because if many things go very well on an activity, generally only a little time can be saved, but if many things go terribly wrong, a great deal of time can be lost.

However, using PERT involves difficulties. First, it is often hard enough to create one estimate of how long an activity will take, so it takes even more effort (and therefore money) to create three estimates. Second, there is no guarantee on how good any of the three estimates are. Third, PERT can underestimate the risk of a schedule running long because it does not accurately address when two or more activities both need to be accomplished before a third one can begin.27

Since PERT highlights uncertainty in project duration, its logic is useful to project man- agers. However, since it has some problems, only a few project managers actually use it to fully calculate and monitor project schedules. Some project managers informally use three time estimates for a few key activities on the critical path to get a sense for the amount of uncertainty and to better understand the activities that need close monitoring. Other proj- ect managers who want to understand the potential variation use Monte Carlo simulation. Students of project management need to be aware that both PERT and Monte Carlo simu- lations are sometimes used to help understand uncertainty in project schedules.

7-9b Monte Carlo Simulation Monte Carlo simulation is “a process which generates hundreds of thousands of probable performance outcomes based on probability distributions for cost and schedule on individual tasks. The outcomes are then used to generate a probability distribution for the project as a whole.”28 Monte Carlo is more flexible than PERT, in that an entire range of possible time estimates can be used for any activity. The project schedule is calculated many times (per- haps 1,000 or more), and each time the estimate for a particular activity is generated based upon the likelihood of that time as determined by the project manager. For example, suppose a project manager estimated that for a particular activity there was a 10 percent chance of taking five days, a 30 percent chance of taking six days, a 40 percent chance of taking seven days, and the remaining 20 percent chance of taking eight days. Then for each 100 times the computer generated a project schedule, when it came to that activity, 10 times it would choose five days, 30 times it would choose six days, 40 times it would choose seven days, and 20 times it would choose eight days. The output from the computer would include a distribution of how often the project would be expected to take each possible length of time. Many other possible outputs can also be generated from Monte Carlo simulations.

One advantage of Monte Carlo analysis is the flexibility it provides. This allows more realistic estimates. Another advantage is the extent of information it can provide regard- ing individual activities, the overall project, and different paths through the project that may become critical.

A disadvantage of Monte Carlo is the amount of time necessary to estimate not just a most likely duration for each activity, but an entire range of possible outcomes. Another disadvantage is that special software and skill are necessary to effectively use Monte Carlo. This disadvantage is not as large as it once was because more software is available and most students are learning at least the fundamentals of simulation in statistics or operations classes.

A project manager needs to decide when some of the more specialized techniques are worth the extra effort for a project. The old saying that a person should spend $100 to save $1,000, but should not spend $1,000 to save $100 applies. If the savings on a project from using techniques such as learning curves, PERT, or Monte Carlo are significant, project managers should consider using one of them. If not, they should create the best estimates possible without the specialized techniques, incorporate risk management by

Chapter 7 Scheduling Projects 191

carefully identifying and planning for specific risks as discussed in Chapter 10, and man- age the project schedule very carefully as discussed in Chapter 14.

These specialized techniques are sometimes used in research and development (R&D) projects. However, some R&D projects do not need this level of sophistication. Exhibit 7.17 shows an actual R&D project schedule used by D. D. Williamson of Louis- ville, Kentucky, when a Chinese customer asked it to develop a new product somewhat different from any it had previously developed. Once D. D. Williamson decided to take the job, it developed and communicated the project schedule to all stakeholders both in its company and the customer’s company within the first week.

Australian researchers have discovered that two primary causes of late delivery of IT projects are variance in time to complete individual work activities and multiple depen- dencies for some activities. Suggestions for overcoming these two problems are shown in Exhibit 7.18.

7-10 Show the Project Schedule on a Gantt Chart The discussion in this chapter so far has been how to determine the project schedule. While this is necessary, it can be confusing to show people a network diagram. A much easier to understand tool for communicating a project schedule is a Gantt or bar chart. A Gantt chart is “a bar chart of schedule information where activities are listed on the ver- tical axis, dates are shown on the horizontal axis, and activity durations are shown as horizontal bars placed according to start and end dates.”29

The Gantt chart is a horizontal bar chart showing each activity’s early start and finish. The simplest Gantt charts show a bar for each activity stretched out over a time line. Many stakeholders also want to see which activities are critical and the amount of float noncritical activities have. Therefore, critical activities are normally shown in red or boldface, noncritical activities are normally shown in blue or normal face, and the amount of float is shown in a muted or thin line out to the late finish of each noncritical activity. The units of time are the units the project team used in creating the schedule, whether that is hours, days, weeks, or another measure A Gantt chart is shown in Exhibit 7.19. It is easy

EXHIBIT 7.17 NEW PRODUCT DEVELOPMENT SCHEDULE IN CHINA EXAMPLE

Week one—Request is received from the customer for a product that is darker than anything we have in our current offering. Our sales manager forwards the request to our VP sales and our R&D department. A quick review of the potential price versus cost of materials is completed by the VP sales (with finance input), and the product is deemed saleable at an acceptable margin.

Week two—A trial cook in our “baby cooker” is conducted by our R&D department. Within two attempts, a product that is within the customer-requested specs is produced. An additional trial is conducted to quickly check repeatability. The trial product is express shipped to the customer and to our China facility for comparison purposes.

Week three—The formulation and related instructions for cooking are communicated to our China operations with a “red sheet” process. China has anticipated the receipt of this red sheet, and is able to schedule time in production within a week.

Week four—The initial red sheet production is successful and passes the specification tests in China and in Louisville.

Week five—Customer confirms purchase order, and the first shipment is sent. The product contributes significantly to the reven- ues and profitability of the China facility. Success!

Key factors—Strong communication between all the players and a clear understanding of the customer expectations up front.

Source: Elaine Gravatte, D. D. Williamson.

192 Part 2 Planning Projects

to understand when each activity should be performed. However, the basic Gantt chart does not show other useful information such as predecessor–successor relationships, late start dates, and so forth. These can all be easily displayed on a Gantt chart that is devel- oped using scheduling software such as Microsoft Project. The instructions for using MS Project to create and print Gantt charts are covered in the following section.

7-11 Using Microsoft Project for Critical Path Schedules

Remember that five different things can limit how fast a project can be completed: the logical order of the activities, the duration of each activity, the number of key resources available when needed, any imposed dates, and cash flow. It is helpful to use MS Project

EXHIBIT 7.18 INITIATIVES TO IMPROVE ON-TIME SCHEDULE DELIVERY

CAUSE OF LATE DELIVERY INITIATIVE EXPLANATION

Activity variance Increase activity transparency Increase user participation

Reduce project size

Manage expectations, e.g., set realistic goals by drawing from “outside views” Use packaged software

Allows for better planning Ensures that the product delivered meets the user needs Ensures that estimates for tasks are more accurate Mitigates optimism bias and misrepre- sentation Provides a standard within which to develop the system

Activity dependence De-scope Improve requirements definition

Reduce activity coupling

Stage projects (incremental develop- ment or iterative development)

Reduces the number of dependencies Ensures that there is no confusion over what is to be developed and when If activity links are reduced then depen- dencies exert less influence Reduces delay bias by minimizing mul- titasking, merging, queuing (i.e., reduces the dependencies)

Source: Vlasic, Anthony and Li Liu, “Why Information Systems Projects Are Always Late,” Proceedings Project Management Institute Research and Education Conference 2010 (Oxon Hill, MD, July 2010).

EXHIBIT 7.19 GANTT CHART EXAMPLE

0Activity 10 155 20 25 30 35 40 45 50 55 60 65 70

Time in workdays

Determine new product features

Acquire prototype materials

Produce prototype

Design marketing campaign

Design graphics

Conduct marketing

Perform sales calls

Chapter 7 Scheduling Projects 193

to construct schedules by considering each of these limitations in order. That is, first the logical order is determined, and then duration estimates are applied. It is often helpful to confirm the logical order first because if people also apply the estimated durations right away, MS Project generates dates that may not please some decision makers. You may secure approval of a more realistic schedule if you allow people to first concentrate on the order of work and then on how long each activity takes.

This section begins with setting up the project schedule. Then logical order and activ- ity duration estimates are included in the section on building the network diagram. Finally, this section covers understanding the critical path and displaying and printing the emerging schedule. Resource limits and imposed dates are shown in Chapter 8, and cash flow is shown in Chapter 9.

7-11a Set Up the Project Schedule Setting up the project schedule includes defining your organization’s holidays, turning off the change highlighting function, and understanding data types.

DEFINE YOUR ORGANIZATION’S HOLIDAYS MS Project has a calendar system to define working and nonworking time: a default project calendar and a resource calendar for each resource. To avoid unrealistic schedules, you must define holidays in the project calendar and resource vacations in resource calendars. The default project calendar has all days, except Saturday and Sunday, defined as eight-hour working days. The working hours during the day are 8:00 to 12:00 and 1:00 to 5:00. No holidays are defined. Holi- days are blocked out by defining holidays as nonworking days. All project calendar con- tent is copied into all resource calendars. Resource calendars are used to block out vacation days and other resource-specific nonworking days. Resource calendars are then used to determine when a resource assignment can be scheduled. If there is no resource assignment, then the project calendar is used to determine scheduling.

Use the following steps to change a working day to nonworking, as shown in Exhibit 7.20. The legend explains the day shading:

1. On the Project tab, click Change Working Time. 2. In the For Calendar: box, enter Standard (Project Calendar) if not displayed. 3. Move to the month and year using the scroll bar to the right of the calendar display. 4. Click on the day to change. 5. Click the Exceptions tab, then click an empty row. 6. Enter a description in the Name column. 7. Click another cell in the same row to review the results. 8. Repeat these steps until the organizational holidays are defined. 9. Deleting a row restores the previous definition.

10. Click OK.

To change the working time for a day, as shown in Exhibit 7.21:

1. Select the day, enter a description, and then click Details… 2. Click Working Time and modify the From: and To: values. 3. If you wish to eliminate one set of work times such as morning, select those times

and apply the delete key so only afternoon times are working. 4. Click OK twice.

To change a nonworking day to working:

1. Select the day and click Details… 2. Click Nonworking and click OK twice.

194 Part 2 Planning Projects

TURN OFF CHANGE HIGHLIGHTING MS Project automatically shows the impact of any changes you make to a project schedule. While this is useful when managing an ongoing project, it can be helpful to turn this function off until the project schedule is baselined (described in Chapter 11).

1. Click the Task tab. 2. On the Format tab, Text Styles, Item to Change, enter Changed Cells. 3. In Background Color, enter White. 4. Click OK.

UNDERSTANDING TYPES OF PROJECT DATA MS Project works with three types of data: task, resource, and assignment.

TASK DATA Included in this category are two kinds of information using the same dis- play fields and formats: WBS data and task data. MS Project refers to individual work activities as tasks and WBS elements as summary rows. MS Project marks these differ- ently. WBS text is bolded, while task data are not. A WBS graphic is a black bar with each end hanging down. The default for a critical path task is a red bar, and a blue bar is used for a noncritical path task. In this book, critical tasks will be shown in color, and noncritical tasks will be muted grey.

EXHIBIT 7.20 STANDARD CALENDAR WITH TWO HOLIDAYS PLUS A HALF DAY AND

A WORKING SATURDAY

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 7 Scheduling Projects 195

EXHIBIT 7.21 DETAILS DIALOG FOR HALF WORKING DAY

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

SomeWBS element fields contain roll-up data that summarize lower-level elements. For example, the duration value in aWBS element is the number of working days in the standard calendar bounded by the start and finish dates for that element. AGantt chart withWBS and task data is shown in Exhibit 7.22.

Resource Data While a resource is often a person, sometimes a critical machine is also defined as a resource. Each resource is described with information required for control. Resource assignments will be handled in Chapter 8.

Assignment Data Assignment units, work, and cost data are calculated or set when a resource is assigned to a task. The task duration, work values, and cost values are also calculated at the time of the assignment. Cost data will be handled in Chapter 9.

7-11b Build the Logical Network Diagram These instructions build upon those in Chapter 4 for initiating a project and Chapter 6 for setting up a WBS. The six steps to create a realistic logical network diagram in MS Project are as follows:

1. Enter tasks and milestones. 2. Understand task dependencies. 3. Define dependencies using a task table and mouse. 4. Define or delete a dependency series. 5. Understand network diagram presentation. 6. Verify the accuracy of the network diagram.

196 Part 2 Planning Projects

STEP 1: ENTER TASKS AND MILESTONES Tasks can be added with an insert func- tion as follows:

1. Click on the Id field to select the row below where the new row will be. 2. On the Task tab, Insert group, click Insert Task. 3. In the Task Name field, enter the desired name of the added task. WBS elements

(summaries) can also be inserted, one to each row. 4. If both summaries and tasks are inserted, capture all task rows under a summary with

mouse and choose indent (right arrow) to show them as tasks within a summary. 5. Selecting more than one row results in that number of blank rows being inserted. 6. Enter any additional task(s) as above. 7. Inserted rows assume the summary level of the row above the insert location.

STEP 2: UNDERSTAND TASK DEPENDENCIES A task dependency definition includes both a logical link type (finish-to-start, start-to-start, finish-to-finish, or start-to-finish) and any associated lead or lag value. The default link type is finish-to-start. The default lead or lag value is zero days. Both of these defaults were used in the product upgrade example earlier in this chapter. Task dependencies may be established and viewed graph- ically in the Network Diagram view and in several Gantt views (Detail Gantt, Gantt Chart, Leveling Gantt, and Tracking Gantt).

STEP 3: DEFINE DEPENDENCIES USING A TASK TABLE AND MOUSE Dependen- cies can easily be defined using the following four steps.

1. Click on the Id (task name) field to select the predecessor task row. 2. Press and hold Ctl while selecting the successor task.

EXHIBIT 7.22 GANTT CHART VIEW WITH WBS ELEMENTS, TASKS, AND MILESTONES

Summary Values

Project Summary Row

Critical task

Intermediate Summary Row

Noncritical task Milestone

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 7 Scheduling Projects 197

3. On the Task tab, Schedule group, click on Link Tasks (chain icon). 4. Delete a dependency definition by again selecting both tasks, and then on the Task

tab, Schedule group, clicking on Unlink Tasks (broken chain icon).

STEP 4: DEFINE OR DELETE A DEPENDENCY SERIES A series of dependencies can be easily defined by the following three steps.

1. Select (by dragging) all of the tasks to be linked in a series. 2. On the Task tab, Schedule group, click on Link Tasks. 3. Delete the links in a set of tasks by selecting the tasks, and on the Task tab, Schedule

group, clicking on Unlink Tasks.

STEP 5: UNDERSTAND NETWORK DIAGRAM PRESENTATION The project network diagram is presented in the conventional Network Diagram view. This view shows all tasks, milestones, and WBS elements (summaries) as described in the following steps and shown in Exhibit 7.23.

1. On the Task tab, View group, click the arrow and then enter Network Diagram. 2. On the File tab, click Print, then choose appropriate settings and click the Print

control.

Because of the space required by this format, it is best to print the view on a large paper size. The logical links can also be seen in Gantt Chart view as link lines connecting Gantt bars, as shown in Exhibit 7.23.

STEP 6: VERIFY THE ACCURACY OF THE NETWORK DIAGRAM The following steps are useful when verifying the accuracy of the network diagram.

1. Print the network diagram. 2. Find all tasks with no predecessor and justify each. 3. Find all tasks with no successor and justify each. 4. Verify the logic (work flow). 5. Look for opportunities to do activities in parallel or to at least overlap activities. 6. Justify or repair any gaps in the critical path.

EXHIBIT 7.23 PARTIAL NETWORK DIAGRAM

Project Summary

Project Summary

Critical Path Task

Noncritical Path Milestone

Noncritical Path Task

Critical Path Milestone

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

198 Part 2 Planning Projects

Network diagrams will be easier to understand if all logical links are between tasks and not between tasks and summary bars.

7-11c Understand the Critical Path Once the logic of the network is confirmed, it is time to develop and understand the critical path. This is accomplished by first assigning duration estimates and then by instructing MS Project to identify the critical path.

ASSIGN DURATION ESTIMATES The first principle to keep in mind is to use the same unit of time for each task. Mixing up hours, days, or weeks will probably create confusion. The default time unit is days, so these instructions use days. The second prin- ciple is to only assign duration estimates to tasks and milestones. Milestones consume zero time; they reflect a moment in time when something is complete. MS Project calcu- lates the duration for WBS summaries based upon the durations selected for the tasks that comprise each summary.

To assign the duration to a task, click the Duration cell of the task and enter the duration value. If days are being used, an adjustment can be made up or down with the arrows. A number can also be deleted and then another number typed in the cell. If using hours or weeks, simply type the number and then “h” for hour or “w” for weeks. If a milestone needs to be shown, zero duration should be assigned to it. To create a milestone, enter zero in the Duration cell of the milestone.

IDENTIFY THE CRITICAL PATH In most graphical task views, MS Project marks Gantt bars of critical path tasks and network diagram task nodes in red. But, as shipped, MS Project does not display the critical path marking on the Gantt Chart graphical view. This marking is easily added. To do so, click the Task tab and then on the Format tab, Bar Styles group, click Critical Tasks.

7-11d Display and Print Schedules with MS Project In the contemporary work environment, many people are accustomed to e-mailing work associates a file and having the associate open the file to read it. This works very well with word processing and spreadsheets. Often, it does not work with project scheduling software, however, because in many organizations only a few people have copies of the software. Therefore, it is useful to be able to create an output that can be saved as a PDF or printed and easily read.

A Microsoft Project schedule example is shown in Exhibit 7.22. Several things can be noted in this example. First, the critical path is clearly highlighted. Second, calendar dates are used, and the weekends are shown in grey with no work scheduled. Third, the activities are listed in a WBS with WBS code shown in the left-most column. The overall project and each summary level are shown by a black bar. Using page setup, timescale, and a bit of editing, it is easy to create a schedule people can understand. As an older reviewer of project schedules, your author adheres to the 40-40 rule of schedule displays. More than 40 lines per page should not be shown if anyone who needs to read it is over 40 years old! Some people even insist on no more than 35 rows per page. This will help keep your sponsor and clients happy.

Summary Project schedules are created by listing all of the activi- ties that need to be performed. This information should be derived from the work packages at the lowest

level of the work breakdown structure. Each work package may require one or more activities to be com- pleted to create the required deliverable. Each activity

Chapter 7 Scheduling Projects 199

needs to be defined in enough detail that it can be assigned to one person who can accurately determine how it will be accomplished and by whom, estimate how long it will take and how much it will cost, and then be held accountable to ensure it is accomplished.

Once all of the activities have been defined, they need to be sequenced—that is, the team must deter- mine which activities must go first (predecessors) and which activities depend on others to be accomplished before they can start (successors). Many people find that determining these relationships is easiest with Post-it Notes and a large work space.

A person on the planning team needs to estimate how long each activity will take. This is greatly dependent on who will do the work, which is discussed in the next chap- ter. Care should be taken when creating the estimates since some people tend to be optimistic and many things can interfere with the ability to work on a specific activity. Other people tend to pessimistically pad their estimates to make sure they can finish early and look good.

The three time management processes described above—activity definition, activity sequencing, and activity duration estimating—need to be accomplished even if scheduling software will be used. The next step is schedule development. Some teams use Post-it Notes to develop this schedule manually by making two logi- cal passes through the network to determine both the earliest and latest any activity can be started and ended. However, this requires tedious calculations and is greatly simplified by use of software such as MS Project.

Schedule development is an iterative process. Once an initial schedule is developed, it needs to be com- pared to resource limits, imposed dates, and cash flow. Often, a sponsor or customer wants the project sooner than the original schedule suggests. In these cases, many approaches may be considered to expedite the schedule. These schedule adjustments will be con- sidered in Chapters 8 and 9.

Key Terms from the PMBOK ® Guide plan schedule management, 172 activity, 172 define activities, 172 sequence activities, 172 estimate activity resources, 172 estimate activity durations, 172 develop schedule, 172 control schedule, 172 critical path method (CPM), 173 precedence diagramming method (PDM), 174 predecessor activity, 178 successor activity, 178 mandatory dependency, 178 discretionary dependency, 179 finish-to-start (FS), 179 lead, 180 lag, 180

finish-to-finish (FF), 180 start-to-start (SS), 181 start-to-finish (SF), 181 duration, 181 velocity, 184 critical path, 184 forward pass, 185 early start date (ES), 185 early finish date (EF), 185 late start date (LS), 186 late finish date (LF), 186 backward pass, 187 total float, 188 free float, 188 Monte Carlo simulation, 191 Gantt chart, 192

Chapter Review Questions 1. When can the first draft of a project schedule be

constructed? 2. What is the difference between an activity and a

work package? 3. What is another name for activity on node

diagramming? 4. What purpose do project milestones serve?

5. Describe the relationship between a predecessor activity and a successor activity.

6. Describe the four most common types of logical dependency.

7. One potential problem that can occur with activity duration estimating is having omissions.

200 Part 2 Planning Projects

What are three potential remedies for this problem?

8. According to the learning curve, performing an activity frequently results in it taking ____________ time to complete the same activity in the future.

9. What two methods can be used to determine the critical path of a schedule?

10. If an activity on the critical path falls behind schedule, what effect will this have on the entire project?

11. If a painted room must dry for four hours before work can continue, the result is a delay in the successor activity. The wait for the paint to dry is an example of a ____________.

12. A professor cannot grade his students’ exams until the students have completed taking the test. What kind of relationship is this?

13. What is one advantage and one disadvantage of Monte Carlo analysis for predicting a project schedule?

14. How can a Gantt Chart be helpful in project planning?

15. A lead is a change in the logical relationship that results in the ____________ of the successor activity.

16. What is a lag in a project schedule?

Discussion Questions 1. Describe the five factors that may limit how fast a

project can be completed. Give an example of each.

2. Think of one thing you have to do today. Describe how it does or does not meet all five parts of the definition of an activity?

3. List at least four potential problems in creating accurate duration estimates for activities. Describe at least two methods for dealing with each potential problem.

4. Describe how a WBS and a schedule work together.

5. You are the project manager assigned to build and decorate a model home. What might be an example of a lead you encounter when schedul- ing work activities? A lag?

6. Describe the process used to calculate float. Describe how you can tell if it is total float or free float.

Exercises 1. Label the box below to create a two-pass schedule

legend.

2. If the learning rate is 60 percent and the first time the activity was performed took 200 min- utes, the second time performing the activity should take ____________ minutes and the fourth time should take ____________ minutes.

3. In the example below, label which activities are predecessors and which activities are successors.

4. Create a logical network using the activities listed below. Planting a Flower Bed

_ Purchase flowers, potting soil, and tools.

_ Water flowers.

_ Prepare soiling by weeding and adding fertilizer.

_ Plant flowers.

_ Dig hole.5. Calculate early start, early finish, late start, late finish, and float for each of the activities in the

Chapter 7 Scheduling Projects 201

network below. The duration of each activity is given.

6. Identify the critical path for the network in Exercise 5. How long should the project take?

7. Display the schedule from Exercise 5 on a Gantt chart showing critical activities, noncritical activities, and float.

8. Given the information for Problem 07.07, create the project schedule network. Then, using the two-pass method, calculate and show the early and late starts and float for each activity and the critical path. Show the schedule on a Gantt chart showing critical and noncritical activities and float.

9. Given the information for Problem 07.08, create the project schedule network. Then, using the enumeration method, calculate and show all of the paths through the network. Show how long each path will take. Identify the critical path. Show the schedule on a Gantt chart showing critical and noncritical activities and float.

10. Using the data for Problem 07.09, schedule the problem in MS Project. Display and print the schedule in a Gantt chart showing the critical path and the predecessors.

11. Using the data for Problem 07.10, schedule the problem in MS Project. Display and print the schedule in a Gantt chart showing the critical path and the predecessors.

12. Using the information for Problem 07.07, input the data into MS Project. Display and print the schedule in Gantt chart format as shown in Exhibit 7.19.

13. Using the information for Problem 07.08, input the data into MS Project. Display and print the schedule in Gantt chart format as shown in Exhibit 7.19.

PMBOK® Guide Questions 1. The Midlands Company is eager to develop a

project schedule. They have already completed the scope statement, work breakdown structure, and schedule management plan. What is the next thing they should do in order to start creating a project schedule? a. define activities b. nothing; they are ready to proceed c. sequence activities d. estimate activity durations

2. Which of the following is NOT a characteristic of an activity? a. It is a distinct, scheduled portion of work

performed during a project. b. It has clear starting and ending points. c. It is defined using a verb/noun format. d. It is one of the deliverables at the lowest level

of the WBS. 3. The “method used to estimate the minimum

project duration and determine the amount of

scheduling flexibility on the logical network paths within the schedule model” is called the ____________: a. Gantt chart method b. critical path method c. PERT method d. critical chain method

4. Another term for “activity on node,” the most commonly used technique for constructing a schedule model, is: a. precedence diagramming method (PDM) b. arrow diagramming method (ADM) c. activity on arrow (AOA) d. activity attribute method (AAM)

5. Nick has time, budget, and adequate supplies and equipment to finish his project. However, there is only one trained engineer assigned to the project team. According to his schedule model, Nick needs at least three engineers. He will need to adjust the start and finish dates for schedule

202 Part 2 Planning Projects

activities to compensate for this constraint, which is ____________? a. logical order of activities b. activity duration c. cash flow concerns d. availability of key resources

6. A critical path activity has ____________ float during the planning process. a. the most b. zero c. negative d. positive

7. The Bluestar Creative Agency is developing a new marketing campaign for a client. They have determined that the client’s marketing plan must be completed before the graphic design can begin. This situation describes what type of dependency? a. start-to-start (SS) b. start-to-finish (SF) c. finish-to-start (FS) d. finish-to-finish (FF)

8. What is an advantage of using the “program evaluation and review technique” (PERT) when estimating the duration for an activity? a. It uses historical data from a similar activity or

project to calculate the duration.

b. It uses brainstorming techniques to reach a team consensus for the duration.

c. It helps to clarify the range of uncertainty around the expected duration.

d. It is less costly and time consuming than other estimating techniques.

9. What is a disadvantage of using Monte Carlo analysis to estimate ranges in durations for individual activities, and thus the project as a whole? a. It requires special software and skill to be

effective. b. It is difficult to collect the three estimates

needed for the analysis. c. The results of the analysis are highly

subjective. d. It requires a subject matter expert with a PhD

to use the tool. 10. A Gantt chart represents project schedule infor-

mation in an easy-to-read, graphical format. Which of these is NOT a component of a Gantt chart? a. activities b. budget data c. start and end dates d. durations

Example Project Take the WBS you have already developed. Define all of the activities that will be necessary to create each deliverable in your WBS. Create a schedule for your sample project. First, create the schedule by hand using Post-it Notes and then put the information into MS Project. Create a printed copy of the schedule on a

Gantt chart with no more than 40 lines per page. Do not use more pages than necessary. Sponsors do not like to flip pages. Be sure to include all of the summary rows (including the first row for the project title) and any key milestones. Make sure the critical path is easy to see.

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Douglas, Edward E., III, “Schedule Constructability Review,” AACE International Transactions (2008) PS.16.1–PS.16.6.

Gray, Neal S., “Secrets to Creating the Elusive ‘Accurate Estimate,’” PM Network, 15 (8) (August 2001): 54–57.

Haugan, Gregory T., Project Planning and Scheduling (Vienna, VA: Management Concepts, Inc., 2002).

Hulett, David T., “Project Schedule Risk Analysis: Monte Carlo Simulation or PERT?” PM Network 14 (2) (February 2000): 43–47.

Hulett, David T., “Project Schedule Risk Assessment,” Project Management Journal 26 (1) (March 1995): 21–31.

Kelley, J. F., “Critical Path Planning and Scheduling: Mathematical Basis,” Operations Research 9 (3) (1961): 296–320.

Leach, Larry, “Schedule and Cost Buffer Sizing: How to Account for the Bias between Project Performance

Chapter 7 Scheduling Projects 203

and Your Model,” Project Management Journal 34 (2) (June 2003): 34–47.

Lukas, Joseph A., “Top Ten Scheduling Mistakes and How to Prevent Them,” AACE International Transactions (2009): PS.10.1–PS.10.11.

Malcolm, D. G., et al., “Applications of a Technique for R and D Program Evaluation (PERT),” Operations Research 1 (5) (1959): 646–669.

McGary, Rudd, Passing the PMP Exam: How to Take It and Pass It (Upper Saddle River, NJ: Prentice Hall PTR, 2006).

Moder, Joseph J., “Network Techniques in Project Man- agement,” in David I. Cleland and William R King, eds., Project Management Handbook, 2nd ed. (New York: Van Nostrand Reinhold, 1998): 324–373.

Moder, J. J., C. R Phillips, and E. W. Davis, Project Management with CPM, PERT, and Precedence

Diagramming, 3rd ed. (New York: Van Nostrand Reinhold, 1983).

Salem, O., J. Solomon, A. Genaidy, and M. Luegr-ring, “Site Implementation and Assessment of Lean Construction Techniques,” Lean Construction Journal (2) (October 2005): 1–21.

Vlasic, Anthony and Li Liu, “Why Information Systems Projects Are Always Late,” Proceedings Project Management Institute Research and Education Conference 2010 (Oxon Hill, MD, July 2010).

Waterworth, Christopher J., “Relearning the Learning Curve: A Review of the Derivation and Applications of Learning-Curve Theory,” Project Management Journal 31 (1) (March 2000): 24–31.

Webster, Francis W., Jr., “They Wrote the Book: The Early Literature of Modern Project Management,” PM Network 13 (8) (August 1999): 59–62.

Endnotes 1. PMBOK® Guide 526. 2. Adapted from Gregory T. Haugan, Project Planning

and Scheduling (Vienna, VA: Management Con- cepts, Inc., 2002): 52.

3. PMBOK® Guide 141. 4. PMBOK® Guide 536. 5. PMBOK® Guide 551. 6. Ibid. 7. PMBOK® Guide 450. 8. PMBOK® Guide 545. 9. PMBOK® Guide 538.

10. PMBOK® Guide 540. 11. PMBOK® Guide 544. 12. Ibid. 13. Ibid. 14. PMBOK® Guide 564. 15. Ibid. 16. PMBOK® Guide 538.

17. PMBOK® Guide 566. 18. PMBOK® Guide 536. 19. PMBOK® Guide 541. 20. PMBOK® Guide 538. 21. Ibid. 22. PMBOK® Guide 544. 23. Ibid. 24. PMBOK® Guide 529. 25. PMBOK® Guide 565. 26. PMBOK® Guide 541. 27. David T. Hulett, “Project Schedule Risk Assess-

ment,” Project Management Journal 26 (1) (March 1995): 21–31; and David T. Hulett, “Project Sched- ule Risk Analysis: Monte Carlo Simulation or PERT?” PM Network 14 (2) (February 2000): 43–47.

28. PMBOK® Guide 547. 29. PMBOK® Guide 542.

204 Part 2 Planning Projects

PROJECT MANAGEMENT I N ACT I ON

Bank Project Schedule

This is an actual schedule of a subproject from the bank. The holding banking group in Europe is rolling out a project management tool to all its regions (countries in Europe and Africa). They have developed the tool over the past few years, and this schedule reflects the activities to take on regional users and projects. There is no software implementation on employee computers as such, as the single instance of the tool resides in Europe and is accessed via the company network.

Exhibit 7.24 shows the overall subproject with all details hidden. This overall view is useful when discussing the project with senior managers who want to understand the big picture and as a starting point in discussing with other stakeholders who will want to see details in one or more specific areas. Several

things can be noted from the partial schedule shown in Exhibit 7.24. The task ribbon is displayed showing available choices. The project timeline just under the ribbon shows the summary for the entire project. A person can read the dates just under the timeline. Intermediate summaries are shown. The detail is shown for start-up and initiation, but is hidden for execution and closure. Project managers can show or hide as much detail as their sponsors and other stakeholders wish. Critical activities are shown in color. Work breakdown structure numbering is shown in the leftmost column. Note this company chose to display the predecessor–successor relationships with arrows and did not choose to show the amount of float for each activity.

EXHIBIT 7.24 BANK PROJECT WITH STARTUP AND INITIATION DETAILS

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 7 Scheduling Projects 205

EXHIBIT 7.25 BANK PROJECT WITH EXECUTING AND CLOSING ACTIVITIES

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Exhibit 7.25 shows the schedule with activities for executing and closing visible. It displays the project ribbon.

206 Part 2 Planning Projects

CHA P T E R 8 Resourcing Projects

How does a more than fifty-five-year-old prepress company transform its business from that of a manufacturer to a service provider? Schawk, Inc. was founded in 1953 in the basement of a Chicago home by entrepreneur Clarence W. Schawk. The product being manufactured was printing plates. More than fifty years and fifty acquisitions later, Schawk, with offices all over the world, is recognized as a global leader in brand point management.

How did we get here? Schawk capitalized on its knowledge and skills in streamlining processes and managing color. Today, one of the key challenges for product manufacturers is bringing new and/or modified products to market quickly, accurately, and consistently. This is especially challenging in high-growth, emerging markets where additional challenges, such as counterfeiting and trademark infringement, cost manufacturers 10 to 15 percent of their revenue. Being agile enough to respond to evolving consumer demand while demand is high can be key to achieving category

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Create a Human Resources Management Plan including role descriptions and staffing management plan.

• Show resource assignments on a RACI chart, Gantt chart, and resource histogram.

• Describe methods of resolving resource overloads.

• Compress a project schedule using crashing and fast tracking, and describe the advantages and disadvantages of both.

• Compare and contrast various alternative scheduling methods.

• Using MS Project assign resources, pinpoint overloads, and describe methods of dealing with them.

© w av eb re ak m ed ia /S hu tte rs to ck .c om

208

Topics:

• Estimate activity resources

• Plan human resource management

• Develop schedule

leadership and maximizing sales. Being first to market can confer long-lasting benefits to the brands seen as “the original.” Ultimately, bringing products to market that help brands win at the shelf—where the consumers votes with their wallets—delivers measurable, long-lasting benefits to brand owners.

Many of the world’s most respected organizations struggle with managing projects globally. While their products and marketing strategies may be innovative, their go-to-market processes are often linear, time- consuming, and very inefficient. Their progress toward achieving strategic business goals through the launch of new brands and products is thwarted by many factors, including “silo-ization” and heterogeneous cultures, languages, government regulations, and time zones.

Schawk has adapted by integrating our strategic, creative, and executional capabilities, which are supported by BLUE, our primary brand management technology product. BLUE enables global companies to unite their stakeholders (internal and external), projects, and processes into a single, streamlined workflow management system regardless of geographic boundaries. While workflows are unique to each company, they often combine on-, near-, and off- site project teams around the world.

Increasingly, companies outsource their non-core competencies such as internal design and production departments to Schawk, because that is a core competency of ours, and we can manage these functions more efficiently. This allows the client’s project manager to manage a single Schawk point of contact, allowing him or her to spend more time focusing on higher-value strategic issues.

We identify and help remove process bottlenecks, offer online collaborative project management tools, and provide knowledgable human talent to deliver what we call brand point management. Brand point management helps companies create compelling and consistent brand experiences across brand touch points.

Patti A. Soldavini, director, Corporate Marketing, Schawk, Inc.

209

PMBOK® Guide

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative Closure

Planning Executing Closing RealizingInitiating

RealizedResultTo proceed

How do you decide who you need to work on your project? How do you know when you need each worker? How do you secure the services of those people? How do you make sure each worker has a steady amount of work to do, but not an overwhelming amount at any time? How do you make sure your project schedule is realistic, considering who will do the work?

These and many other related questions are answered when you correctly resource a project. Resources include people (human resources) along with machines, space, and other things you need to get the project done. In this chapter, we will primarily discuss human resources.

8-1 Abilities Needed when Resourcing Projects Project managers need two types of abilities to correctly resource a project. The first type of skill needed is technical. Various techniques can be used to estimate resource demands, create a staffing management plan, assign one or more persons to each activity, identify when a person is assigned too much work at a point in time, schedule a project with limited numbers of key people and other resources, and compress (speed up) a project schedule.

The second type of skill needed is behavioral. As you might guess, many behavioral issues are involved in completing project resourcing tasks such as:

• Selecting the right people • Identifying exactly what each person needs to accomplish • Ensuring each person either has the capability needed or developing that person

to be capable • Dealing with difficult individual work schedules • Getting people to work overtime when there are conflicts • Making honest and open estimates of the amount of work required to complete an

activity • Assembling an effective team • Dealing with people from diverse backgrounds • Deciding where each person will work • Deciding how a team that is geographically split can work in an effective virtual manner

8-1a The Science and Art of Resourcing Projects The science and art of project resourcing are to perform the technical and behavioral aspects together in a manner that reinforces both. A resource-based schedule that is technically brilliant, but has little acceptance from those who must do the work, has little value. Likewise, an effective project team whose members have impractical resource assignments is still likely to struggle. If one needs to choose between the two, a motivated team with poor assignments is more likely to be successful. However, when both are done well, the project has wonderful prospects.

This chapter covers both technical and behavioral aspects of determining and secur- ing effective human resources for a project. While each specific skill and behavioral consideration is introduced separately, keep in mind that people are inclined to support what they have helped to plan. Therefore, when possible, identify your key people as soon as possible and get them engaged in the planning.

8-1b Considerations when Resourcing Projects As we cover the specific skills and behavioral aspects of resourcing projects, the following ideas should be kept in mind:

• If some of the key people on a project do not have the skills to participate, managers should help them develop those skills.

210 Part 2 Planning Projects

• Projects always have tradeoffs; with regard to resources, time versus human resources versus other costs versus scope should be considered. Which of these takes precedence on the project you are planning?

• Project managers need to understand resource limitations to prevent over-promising. Often, after activities are tentatively scheduled as discussed in the previous chapter, it appears that the project can be completed by a particular date. However, the schedule may be unrealistic if enough resources are not available at key points in time.

• People are often a large portion of total project cost. This is especially true when a project requires special knowledge.

8-1c Activity- versus Resource-Dominated Schedules All project schedules are based in part on the individual activities (both the estimates of how long each activity will take and their logical order, as discussed in Chapter 7) and in part on the number of human resources who are available when needed (the topic of this chapter). However, in some circumstances, the schedule is based more on the activities, and in others it is based more on the resource limits. Exhibit 8.1 lists situations where schedules are based more on activities or more on resources. Some organizations use critical chain (explained in Section 8.8) or agile in situations where the schedule is dominated more by resources.

Agile techniques are often used when the client does not really understand their needs at the project start, it is expected that a rapid rate of change will exist on the project, multiple short deliveries are possible, and the client and project team can collaborate to reduce the impact of activities being dependent on each other.

8-2 Estimate Resource Needs A starting point in resourcing a project is to estimate how many resources of each type and skill or knowledge level are needed. The PMBOK task estimate activity resources is “the process of estimating the types and quantities of material, human resources, equipment, or supplies required to perform each activity.”1 This can be accomplished at either a detailed or an overview level. When a project team deter- mines a detailed list of activities that must be performed, it makes sense to ask what type of person (by specific knowledge or skill) is needed to perform each of the activ- ities. However, when a project team does not identify individual activities, they still

A G I L E

EXHIBIT 8.1 ACTIVITY– VS. RESOURCE–DOMINATED SCHEDULE BASIS COMPARISON

MORE ON ACTIVITY

MORE ON RESOURCE

Time in project when scope is determined Early Late

Confidence in duration estimates Great Little

Rate of resource learning Small Extensive

Specialization of resources Commodity Unique

Availability of resources Easily available Tight availability

Firmness of activity predecessors (order) Absolute Optional

Concurrency of activities Little Significant

Chapter 8 Resourcing Projects 211

need to determine how many resources and what knowledge and skill each needs to complete the project. If the team uses rolling wave planning, they probably develop detailed resource requirements for the early part of the project for which they have identified specific activities, and less detailed requirements for later project phases for which the activity detail is not yet as specific.

When estimating resource needs, the team needs to make sure they have considered support needs as well such as information systems and human resources. Some types of workers have specific constraints placed upon how they are hired, scheduled, and released. Co-located teams and highly skilled resources often require more detailed resource planning. Many issues may be involved in securing specific knowledge or skills. When estimating resource needs, it is wise to include time to communicate between activities as well as time to perform activities. “Handoffs” occur when one person or group passes work on to another group.

8-3 Plan Human Resource Management Plan Human Resource Management is “the process of identifying and documenting project roles, responsibilities, required skills, reporting relationships, and creating a staff- ing management plan.”2 Roles and responsibilities for project participants can be docu- mented in role descriptions. These often include title, assigned duties, and limits of authority as shown in Exhibit 8.2.

A staffing management plan is “a component of the human resource plan that describes when and how project team members will be acquired and how long they will be needed.”3 The staffing management plan addresses how to identify potential internal and/or external human resources for the project; determine the availability of each; and decide how to handle timing issues with regard to building up, developing, rewarding, and releasing the project team.

8-3a Identify Potential Resources Identifying people who might work on a project differs significantly from one organiza- tion to another. Many organizations are staffed in a lean manner and have few people from which to choose. In a small organization, one particular person may often be the logical choice for certain types of work on a project. However, in larger organizations and in situations where outside resources may be hired, identifying potential people becomes a bigger issue. Whatever the situation, a project manager needs to understand who is potentially available to work on her project. A project manager keeps in mind the

EXHIBIT 8.2 ROLE DESCRIPTION

Role

Assigned Duties

Limits of Authority

212 Part 2 Planning Projects

estimated resources needed when identifying the people who could potentially work on the project. This information can include factors such as:

• Work functions (may include job titles and range of responsibilities) • Professional discipline (may include degrees and professional certifications) • Skill level (may include experience and performance ratings) • Physical location (may include willingness to relocate and travel) • Organizational/administrative unit (may include costs and contractual issues)4

Once this information is identified for the most likely pool of people, a project manager can compare the available people to the estimated resource needs to identify both gaps in specific skills that are needed and gaps in the number of people available versus those needed. If it is clear that more and/or different people are needed, then the project manager needs to look elsewhere. That could mean other departments or divisions of the company, or it could mean looking outside the organization. A project manager, perhaps with help from the sponsor, continues the identification of potential resources until an adequate number and mix of potential people have been identified.

Key people should be identified as early as possible. The project core team is ideally iden- tified and assigned soon enough to participate in chartering the project. Beyond the core team, it is helpful to get key subject matter experts (SMEs) on board early if possible, not only to help plan the project, but also to help develop the project culture and get it off to a quick start. People are more likely to be enthusiastic about performing work they helped to plan, and this motivation often comes in handy during difficult stretches in a project.

When possible, create options for people—try not to assign people who are unwilling participants. Experienced project managers understand that the better they take care of people who work with them on one project, the easier it is to recruit capable and enthu- siastic people for their next project.

Make opportunities equally available to qualified candidates. First of all, project managers need to do this both from a legal and an ethical perspective. Successful project managers also find many advantages in having diverse teams. Different perspectives should be considered in making decisions and may help avoid major risks that a single perspective would not have uncovered. More creative approaches are undertaken. More stakeholders are effectively man- aged since different project team members sometimes relate better to particular stakeholders.

8-3b Determine Resource Availability Once the potential resources have been identified and compared to the estimated resource needs, it is necessary to discover if the identified people are available and to

secure their commitment. This is necessary even for internal projects because multiple projects often choose resources from the same resource pool. A schedule is preliminary until needed resources are committed to the project.

In terms of resource availability, full- and part-time resources as well as internal and exter- nal resources may be available. If the new project is of higher priority than an existing project, resources that were already committed may be freed up. Regarding ability to commit at a very detailed level, some people have individual calen- dars with specific vacation or other unavailable times. Exhibit 8.3 shows how a consulting com- pany determines resource availability.

Building a committed staff is a crucial step in resourcing projects.

© Ro n Ch ap pl e/ Ta xi /G et ty

Im ag es

Chapter 8 Resourcing Projects 213

8-3c Decide Timing Issues when Resourcing Projects Projects, because of their temporary nature and unique outputs, have timing issues unlike those of ongoing operations. Early in the project, one timing issue is when to bring people on board. Bringing them on before they are needed can be costly. However, if the project manager takes a chance with an important resource and that person is not available, the schedule will probably be delayed. The general solution to the first timing issue is to assign key players as quickly as possible. This helps establish good project planning, effective proj- ect culture, and early project progress. Of course, a project manager may need to negotiate not just for who will be assigned to his project, but when they will be assigned.

As members are brought on board, timing issues involve getting the team functioning effectively and keeping them motivated and on schedule. Team development is covered in Chapter 13.

Near the end of a project, timing issues include rewarding, recognizing, and releasing project team members. How are they rewarded? Under what circumstances are they released from the project, and what provision is made for them to be assigned to new work and/or promoted? These issues are addressed in Chapter 15.

The staffing management plan deals with these three issues: how the project planners identify potential people for the project, how they determine which people are available and secure their services, and how to deal with timing issues of building up and then releasing the project workforce.

EXHIBIT 8.3 MANAGING RESOURCE AVAILABILITY

Under pressure to complete the next phase of a new product being developed, a product development team urgently needed talented manpower. The existing team consisted of mostly technical talent (engineers, designers, and technicians). A review was performed by the product development team to find potential resources. Potential sources included:

• Existing staff • Within their department • Within their company but outside their department

• Staff misfit but talented • Staff burned out and in need of a fresh challenge • Temporary staff • External supplier and customer staff

To the team’s frustration, requests for additional staff were declined. To their surprise, upon further investigation, multiple opportunities developed:

• Product development staff working on separate projects had some idle time. Staff members thought to be dedicated to only a specific project were available for part-time support due to gaps in their schedule.

• Product development staff disinterested or “burned out” with their current project were eager for a different challenge. • Underemployed staff members (at large) were found to be eager to step up to the plate. Existing projects did not keep

them fully challenged. • Some of the work required for completion of the next project phase was highly technical, requiring advanced knowledge,

computer hardware, and very costly analysis software. To the team’s delight, dedicated supplier staff was available to help with development. Advanced computer hardware and software, otherwise unreachable by the core team, were available if potential sales would justify the time investment. A balance was struck where the manufacturer and supplier effectively met each other’s needs for mutual benefit. The product development team could overcome their technical hurdles, while the supplier could grow the business through new sales.

Source: Jeff Flynn, ILSCO Corporation.

214 Part 2 Planning Projects

8-4 Project Team Composition Issues Project teams are often composed of people from many sources—both within and out- side a parent company. Several of these issues, such as who will be on the project and where each will be physically located, are best considered when selecting team members. These issues are introduced here, and the management of teams with these compositions is discussed in Chapter 13.

8-4a Cross-Functional Teams Projects often require cross-functional teams since the work of many projects requires input from multiple disciplines. When people from different backgrounds work together, misun- derstandings often arise. An engineer may be predisposed to look at an issue one way, while an accountant may look at the same issue a different way. This may be due to education, experience, and/or personality. A project manager may feel sometimes that she is a translator between various functions that are working on the project. It is useful for project managers to develop an ability to understand and speak effectively with various technical experts. The project manager is not the expert, but she must understand the experts, be able to communi- cate with them, and have the experts trust her judgment.

8-4b Co-Located Teams Another team issue is where everyone physically sits. Teams are co-located if the members are assigned work spaces near each other. Project managers and teams can often take advantage of many modern methods for communicating from anywhere on the planet. These methods are used often, especially for larger decisions. However, many minor deci- sions are made every day on projects. Many times, a person might not feel that something is important enough to create a document or make a phone call. That same person might ask the person sitting in the next desk or a person he runs into in the hall. Sometimes a person does not want to interrupt her thought process, but would casually ask a person right next to herself a question. Co-location helps to create these opportunities for easy communications. On some projects, members of a supplier company and/or representa- tives from the customer may have a desk in the project work space.

8-4c Virtual Teams Virtual teams are also common and represent the opposite approach. Members of virtual teams do not meet face to face very often. Sometimes a project requires the expertise of many far-flung people, and it is impractical to have them all work in the same area. These teams require many forms of communications. Many people report that if they have met another person face to face even once, they feel they can relate better to that person. Therefore, even for far-flung teams, it is common to bring people together once for a chartering or project kickoff session. Of course, some project managers travel frequently to allow for regularly scheduled face-to-face contact with important team members, customers, and suppliers.

8-4d Outsourcing Many project managers are faced with the prospect of not finding the necessary talent within their organization. When that is the case, project managers often need to hire expertise from one or more other organizations. This is discussed in Chapter 12. The author remembers one project where he worked for a European consulting firm that was hired to establish project management discipline at the IT headquarters of a large accounting firm. The accounting firm had fired its own internal consultants and replaced them with those of the European company, yet it decided to keep one of its own

Chapter 8 Resourcing Projects 215

consultants from each of its Boston and New York offices on the team for political rea- sons. This was an awkward arrangement, but this type of situation occurs fairly often. Outsourcing can allow a project to bring in talent from anywhere in the world, but it can also lead to some tense situations.

8-5 Assign a Resource to Each Activity Once you have identified the workers you want, sometimes you will be able to easily get them. This is especially true if your project is a high priority for your organization and if you have already developed a reputation as a project manager with whom many people want to work. However, a project manager is unlikely to secure all the necessary highly qualified resources he needs. He can expect to negotiate for the desired people.

Hopefully, the core team was assigned during the initiating stage and participated in chartering the project. Now is the time to ensure that the core team is complete and without undue overlaps. It is also the time to assign workers to each activity. On small projects, most of these assignments may be to core team members. On larger projects, many other individuals may be involved as subject matter experts. It is also helpful to specify exactly what each person is responsible for and what authority that person has.

8-5a Show Resource Responsibilities on RACI Chart A responsibility assignment matrix (RAM) is “a grid that shows the project resources assigned to each work package.”5 A RACI is “a common type of responsibility assign- ment matrix that uses responsible, accountable, consult, and inform to define involve- ment of stakeholders in project activities.”6 The first column on the RACI is usually the WBS coding of work packages and activities. The second column includes the names of the work packages and project activities that correspond to the WBS. The remaining columns each represent a person who is involved with the project. A partial RACI chart example is shown in Exhibit 8.4.

In Exhibit 8.4, many activities have more than one person who has some involvement. For example, for the activity “conduct student surveys” Dan is responsible to complete the work, but the project manager, is the one person who is accountable for the results. Dan needs to consult with team member Ben and the students and needs to inform everyone else. In a RACI chart, only one person should have primary accountability for any activity. If more than one person has accountability, it is too easy for them to blame each other if something goes wrong.

RACI charts are extremely useful for assigning activities to project core team mem- bers, subject matter experts, and the project manager. They are also useful in managing project communications. They go further than the original communications plan in that they identify every project activity and specify the exact involvement of each stakeholder.

8-5b Show Resource Assignments on Gantt Chart Once it has been decided who will perform each activity, it is an easy matter to show the assignments on a project schedule. For example, the responsible person for each activity for a portion of the Alternative Breaks project is listed right next to the activity in the Gantt chart schedule in Exhibit 8.5. Showing the responsibilities directly on the schedule is a simple, visual way to communicate responsibilities. For simplicity’s sake, each person has been assigned to work on most activities 75 percent of their time. In some projects, some people will spend 75 percent of their time for the duration of a specific activity, while other activities may require only a small fraction of their time across the activity’s duration. Generally people are available for work on a project less than 100 percent of

216 Part 2 Planning Projects

their time for many reasons (such as those described in Exhibit 7.9). Nevertheless, this demonstrates how to keep track of all of the time a person spends working on a project. Directions for how to construct each of the exhibits regarding resources in MS Project are given in Section 8.9.

EXHIBIT 8.4 PARTIAL RACI CHART

WBS WORK PACKAGES AND ACTIVITIES

SPONSOR (LYNDA)

PROJECT MANAGER (JOE)

TEAM MEMBER (ALI)

TEAM MEMBER (BEN)

TEAM MEMBER (DAN) STUDENTS PARENTS

0.0 High School Recruitment Plan

1.0 Project Management

1.1 Manage Key Stake- holder Expectations

A R C C C I I

1.2 Develop Operating Methods

A C R C

1.3 Create Communica- tions Plan

I A R R R

1.4 Control Progress I A C C R

2.0 Information Assessment

2.1 Conduct Campus Visit

C A R R R I I

2.2 Conduct Students Surveys

I A I C R C I

2.3 Lead Group Discussion

I A C C C C

3.0 Workshop/Activities

3.1 Develop Ideas C A C C R C

3.2 Analyze Possible Techniques

C A C C R C C

3.3 Compile Activities/ programs

C A C C R C I

3.4 Respond to Sponsor Feedback

R A I I I

3.5 Reassess Activity Plan C A C C C I I

3.6 Secure Sponsor Approval

R A I I I I I

Chapter 8 Resourcing Projects 217

8-5c Summarize Resource Responsibilities by Time Period with Histogram Once it is clear who is responsible for each activity, it is time to understand how the multiple demands add up on each worker. Are any of the workers overloaded? To answer this question, the demands for each worker at each time period should be added. Exhibit 8.6 shows the responsibilities for Patrick for the various activities.

When looking at overloaded workers, it is easiest to consider each worker individu- ally. For this example, the person in question is the project leader. Remember, we assigned the project leader to work on each activity 75 percent of his time so that we could see how the total demands add up. Exhibit 8.6, shows Patrick is grossly overloaded at several points. In fact, through much of the schedule, Patrick is scheduled to work 150 percent of his available time!

EXHIBIT 8.5 SCHEDULE WITH RESOURCES EXAMPLE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

EXHIBIT 8.6 RESPONSIBILITY HISTOGRAM EXAMPLE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

218 Part 2 Planning Projects

8-6 Dealing with Resource Overloads Once it is obvious that a particular person has been overloaded at a given point in time, it is helpful to pinpoint exactly which activities are involved. One easy way to do that is to compare the resource histogram, such as the one in Exhibit 8.6, to the Gantt chart schedule, shown in Exhibit 8.5. It is helpful to view both charts together using the same time scale, as shown in Exhibit 8.7. Remember Patrick is available 75 percent of the time (30 hours per week), so you can see where and by how much he is overloaded.

Clearly, Patrick is scheduled to perform several activities at the same time and is overloaded much of the time. Project scheduling software helps to deal with resource overloads by pinpointing when the overloads occur for each worker and by identifying which activities that worker is assigned to perform. How should this be resolved? Soft- ware greatly assists in identifying and understanding the problem, but it takes manage- ment decisions to solve the problem.

8-6a Methods of Resolving Resource Overloads Once a project manager understands who is overloaded and what activities are involved, she can employ many possible methods to rework the project schedule so the worker is not too overloaded. Some of these methods are as follows:

• Assign certain activities to other workers. In our example, perhaps “identify goals of program” could be handled by the directors, and perhaps “document the trip plans” could be handled by Tori. This new schedule is shown in Exhibit 8.8. Note Patrick is still overallocated, but only for three weeks much later in the project. While this is an improvement, perhaps other means should also be used.

• Sometimes an activity can be split into two activities, with the first part being per- formed as scheduled and the last part delayed. This is probably not a good strategy in our example project because it would probably only delay the overload rather than resolve it. This is often not an attractive strategy since many activities when split take more total time. It often takes people a little time to remember where they left off when they resume work.

EXHIBIT 8.7 PARTIAL SCHEDULE AND RESOURCE HISTOGRAM EXAMPLE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 8 Resourcing Projects 219

• Another method of resolving the overloads is to reorder the activities. This may include questioning the logic that was used when creating the schedule. One means of reordering activities, fast tracking, is covered in Section 8.7 on compressing schedules.

• Sometimes when people understand how badly overloaded a resource is, they decide they need to acquire or borrow additional resources.

• If a resource is impossibly overloaded, perhaps the project scope needs to be reduced or the schedule needs to be extended.

• If there is a severe overload and one of these strategies needs to be employed, it usually makes sense to inform the sponsor. The project manager needs to under- stand who is overloaded, when the overload occurs, and what activities cause the overload. Good project managers will then be able to determine possible courses of action. However, it may be up to the sponsor to make the final decision on how to resolve the overload.

• It is often helpful to resource-level the overloaded person’s schedule as described below.

Resource leveling is “a technique in which start and finish dates are adjusted based upon resource constraints with the goal of balancing demand for resources with the available supply.”7 The most common form of resource leveling is when activities are delayed so the person does not need to perform as many activities at the same time. Normally, noncritical activities are delayed by an amount no more than their slack in the hope that the overloads can be resolved without extending the project schedule. However, if none of the alternatives discussed above is feasible and delaying the noncrit- ical activities within their slack is not sufficient, the project schedule will slip. Essentially, this delay reduces peak demand and smoothes the period-to-period resource usage. An example follows, starting with Exhibit 8.9.

EXHIBIT 8.8 SCHEDULE WITH REASSIGNMENTS EXAMPLE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

220 Part 2 Planning Projects

In this example, Jane has been assigned all of the activities. They will require 40 percent, 55 percent, or 75 percent of her time as marked. During the middle part of the schedule, Jane has too many activities to perform at the same time. Therefore, any activities scheduled at that time that are not critical should be considered for delay. The easiest way to understand the work demands and be able to adjust the schedule within the limits of their available work time starts with creating a critical path schedule, as shown in the top portion of Exhibit 8.9. It is helpful to clearly mark the critical path and to “front load” the schedule—that is, to show every activity starting as soon as the activities that precede it are complete. Then, a resource histogram can be built for each person who may be overloaded. Start by putting the critical path activities on the bottom, because those activities need to be completed as scheduled or the entire project will be late. In our example, those are activities 1, 3, 6, and 7. Next, add all of the noncritical path activities above at the earliest time they can be scheduled. In our example these are 2, 4, and 5. With the 75 percent line showing Jane’s maximum available time, it is easy to see that she cannot complete everything as scheduled.

The first conflict is activities 2 and 3. Since activity 3 is on the critical path, activity 2 should be compromised. If Jane waited until there was no conflict to schedule activity 2, how- ever, the project would be delayed. Notice that activity 2 is currently scheduled for 40 percent of Jane’s time for three working days, for a total of 1.2 days of work. If Jane can work on activity 2 for 20 percent of her time during the six days she is working the other 55 percent on activity 3, she would complete both after six work days. Activities 4 and 5 would both then be delayed until activity 2 is complete. This partially leveled schedule is shown in Exhibit 8.10. Notice that Jane has time to finish activity 4 without delaying activity 7 (and, therefore, the critical path). Part of activity 5 could be worked after activity 4 and before activity 7 without overloading Jane, but a portion of activity 5 would still force an overload situation.

If the noncritical activities must be completed at the rate of effort shown in the original schedule, some of them may need to be assigned to another worker. Resource leveling can be as much art as science. The combination of the critical path schedule and resource histo- gram allows a project manager to understand who is overloaded, at what time, and by what specific activities. Then, the project manager seeks to move some of the noncritical activities within their slack to level the demand for that worker. If enough leveling can be done, the

EXHIBIT 8.9 RESOURCE LEVELING EXAMPLE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 8 Resourcing Projects 221

project can proceed as scheduled. If not, some activities must be accomplished by other means, the schedule will slip, or perhaps the scope will need to be reduced.

8-7 Compress the Project Schedule Now that the project manager knows how long the project schedule is expected to take, he can compare it with what the sponsor or customer wants. If the expected time is too long, he will need to reduce the critical path (remember that because the critical path is the longest, it dictates the total project duration).

8-7a Actions to Reduce the Critical Path A variety of actions can be taken to reduce the critical path as follows:

• Reduce the project scope and/or quality. • Overlap sequential activities using finish-to-finish (FF), start-to-start (SS), or start-

to-finish (SF) relationships. • Partially overlap sequential activities by using time leads. • Increase the number of work hours per day or work days per week. • Schedule activities that are normally in sequence at the same time. • Shorten activities by assigning more resources. • Shorten activities that cost the least to speed up.

The first item, reducing scope and/or quality, normally requires permission from the sponsor and/or customer. Scope reductions are fairly common. Sometimes, the original scope includes features that are nice to have but are not essential, which people are will- ing to give up when they understand the schedule impact. Quality reductions are far less common and are discussed in Chapter 11.

The next two items, time leads and alternative dependencies, are discussed in Chapter 7. The last four items, on the other hand, apply to two other techniques used to compress schedules, namely crashing and fast tracking. Crashing is “a technique used to shorten the schedule duration for the least incremental cost by adding resources.”8 Fast tracking is “a schedule compression technique in which activities or phases normally done in sequence are performed in parallel for at least a portion of their duration.”9

EXHIBIT 8.10 PARTIALLY LEVELED RESOURCE SCHEDULE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

222 Part 2 Planning Projects

One simple way to understand the differences between crashing and fast tracking is to determine what is given up in return for the faster schedule. Crashing almost always costs more money to speed up the schedule. Fast tracking almost always increases the risk to speed up the schedule. Both make management more difficult since either more activities take place at the same time and/or more activities have workers on overtime. Let us turn to the specifics of each.

8-7b Crashing When crashing a project schedule, certain activities are performed at a faster- than-normal pace. This often requires overtime pay, but could also require extra charges for expedited deliveries, more expensive machinery, or other methods. When deciding which activities to speed up, two questions must be asked. First, which activities are on the critical path? Since the critical path determines how long the project takes, speeding up any activity not on the critical path makes no difference. Second, which critical path activity costs the least on a per-day basis to speed up? There is no sense in paying more than necessary. We will use the project in Exhibit 8.11 to illustrate crashing.

Note that the enumeration method was used to identify each path and its duration. Path ABEG at 25 days is the critical path. This example is in days, but it works equally

EXHIBIT 8.11 CRASHING EXAMPLE SET UP

PROJECT DURATION

25

ACTIVITY(IES) CRASHED

-

INCREMENTAL CRASH COST

0

CUMULATIVE CRASH COST

0

Legend Activity Code

Duration

A

5

C

2

B

8

D

6

G

9

E

3

PATH DURATION

ABEG 25

ACEG 19

ACFG 20

ADFG 24

Activity Normal Time Normal Cost Crash Time Crash Cost Crash Cost per Day A 5 $300 5 B 8 250 5 C 2 100 2 D 6 300 3 E 3 150 2 F 4 275 3 G 9 700 8

$300 400 100 600 300 300 900

N/A 50

N/A 100 150 25

200

F

4

Chapter 8 Resourcing Projects 223

well with weeks or any other unit of time. Also note that three small tables of informa- tion are included in Exhibit 8.11 to help us keep track of times and costs as we make the crashing decisions. The first table is the list of the paths with the time each is expected to take. Remember, we only want to crash activities on the critical path. Every time we reduce the length of an activity, we record the impact on the affected path(s).

The second information table lists each activity along with the normal time and cost (the expected time and cost if this activity is not crashed), the crash cost and time (the fastest the activity could be accomplished and the total cost incurred if it is crashed), and the crash cost per unit of time (in this example, per day). The activities that are on the critical path are identified by a triangle symbol. Two activities, A and C, have the same crash time as normal time. This means they cannot be crashed and are crossed out. We need the information in this table to identify which critical path activities cost the least to speed up.

We use the third small table to keep track of how long the project is, which activity(ies) we choose to speed up, and how much it costs. Using the normal time for all activities, the project is expected to take 25 days. We crash activities one day at a time. Note that path ADFG requires 24 days—only one day less than the critical path.

Activities A, B, E, and G are on the critical path. Activity A cannot be crashed. Some activities are impractical to speed up, even for extra cost. Activity B at $50 is the least expensive of the choices, so that is the one to crash first. Note that activity F only costs $25 to speed up, but it is not on the critical path so it is not chosen. Once we speed up B by one day, the resulting information is placed into the tables, as shown in Exhibit 8.12.

EXHIBIT 8.12 CRASHING EXAMPLE AFTER ONE ROUND

PROJECT DURATION

25 24

ACTIVITY(IES) CRASHED

- B

INCREMENTAL CRASH COST

0 $50

CUMULATIVE CRASH COST

0 $50

Legend Activity Code

Duration

A

5

C

2

B

8

D

6

G

9

E

3

PATH DURATION

ABEG 25 24

ACEG 19

ACFG 20

ADFG 24

Activity Normal Time Normal Cost Crash Time Crash Cost Crash Cost per Day A 5 $300 5 B 8 7 250 5 C 2 100 2 D 6 300 3 E 3 150 2 F 4 275 3 G 9 700 8

$300 400 100 600 300 300 900

N/A 50

N/A 100 150 25

200

F

4

• •

224 Part 2 Planning Projects

In the first table, path ABEG has been reduced to 24 days since B is now being crashed. In the second table, activity B is now shown as seven days since it has been crashed one day. In the third table, the duration is now 24 days, B is crashed, the incremental cost is $50, and so is the cumulative cost because that is the only activity crashed so far. Now there are two critical paths of 24 days each. The activities on the second critical path, ADFG, are identified by a circular symbol. To further crash the project, both paths need to be shortened. This could be accomplished by crashing one activity on each critical path, such as B or E on the first path and D or F on the second path. It could also be accomplished by crashing one activity that is on both paths, such as activity G. The least expensive of these alternatives is B and F for a total cost of $75. The results of this are shown in Exhibit 8.13.

After two rounds, both critical paths are 23 days. Note that path ACFG is also reduced, as F is on it and F was crashed. Since F cannot be crashed any further, a line is drawn through it. The cumulative cost of crashing the project two days is $125. Exhibit 8.14 shows the choices of continuing to crash activities until it is no longer worthwhile. That is called an “all-crash” schedule. Note that even in that circumstance activity D is not reduced the full amount possible since reducing it further would not make a difference in the length of the overall project.

EXHIBIT 8.13 CRASHING EXAMPLE AFTER TWO ROUNDS

PROJECT DURATION

25 24 23

ACTIVITY(IES) CRASHED

INCREMENTAL CRASH COST

CUMULATIVE CRASH COST

Legend Activity Code

Duration

A

5

C

2

B

8

D

6

G

9

E

3

PATH DURATION

ABEG 25 24 23

ACEG 19

ACFG 20 19

ADFG 24 23

Activity Normal Time Normal Cost Crash Time Crash Cost Crash Cost per Day A 5 $300 5 B 8 7 6 250 5 C 2 100 2 D 6 300 3 E 3 150 2 F 4 275 3 G 9

3 700 8

$300 400 100 600 300 300 900

N/A 50

N/A 100 150 25

200

F

4

• •

0 $50 125

$50 0

75 (50+25)

- B B & F

Chapter 8 Resourcing Projects 225

Many questions can be answered with this information, such as the following:

• How fast can the project be completed? • To crash the project one day, what activity would be crashed, and what would it

cost? • To crash the project two days, what activities would be crashed, and what would it

cost in total? • If there is a bonus of $125 per day for finishing early, what activities would be

crashed, and how fast would the project be completed? • If there is a bonus of $225 per day for finishing early, what activities would be

crashed, and how fast would the project be completed?

8-7c Fast Tracking Fast tracking occurs when activities that are normally performed in series (one after the other) are performed at the same time. In Exhibit 8.15, fast tracking could potentially be accomplished at several points. For example, while A is being done, B could also be per- formed. This certainly can speed things up as more things can be done at the same time. There is a risk, however. For example, if activity A is to design a part and activity B is to order material for the part, the normal routine would be to wait until the part is

EXHIBIT 8.14 CRASHING EXAMPLE IN “ALL-CRASH” MODE

PROJECT DURATION

ACTIVITY(IES) CRASHED

INCREMENTAL CRASH COST

CUMULATIVE CRASH COST

Legend Activity Code

Duration

A

5

C

2

B

8

D

6

G

9

E

3

PATH DURATION

ABEG 25 24 23 22 21 20

ACEG 19 18 17

ACFG 20 1819

ADFG 24 23 22 21 20

Activity Normal Time Normal Cost Crash Time Crash Cost Crash Cost per Day A 5 $300 5 B 8 7 6 5 250 5 C 2 100 2 D 6 5 4 300 3 E 3 150 2 F 4 275 3 G 9

2 3 8 700 8

$300 400 100 600 300 300 900

N/A 50

N/A 100 150 25

200

F

4

• •

0 $50 125 275 475 725

0 $50

75 (50+25) 150 (50+100) 200 250 (100+150)

- B B & F B & D G D & E

25 24 23 22 21 20

226 Part 2 Planning Projects

designed to be sure to order the correct materials. By performing both at the same time, there is a risk that the design will call for different materials than expected and the materials will need to be reordered. One strategy to gain benefits of fast tracking while attempting to control risk is to use a combination of alternate dependencies with time leads and lags to only partially overlap activities, as described in Chapter 7. Partial activity overlaps entail less risk than full overlaps. Another strategy is to only overlap a few activities so you can manage them closely. One would ordinarily look for long- duration activities on the critical path for this overlapping.

8-8 Alternative Scheduling Methods Several alternative approaches are used in certain industries or certain situations to cre- ate project schedules, including critical chain, reverse phase, agile, auto/manual, and roll- ing wave scheduling. These approaches are not mutually exclusive—a person can use some of the logic from more than one of these methods on the same project.

8-8a Critical Chain Project Management (CCPM) There are several problems with scheduling projects in many organizations that tradi- tional critical path scheduling, even with resource leveling, does not always address satis- factorily. Some of these problems are as follows:

• Many people make conservative duration estimates. Often, people are punished for completing work late, so they give themselves plenty of time in their estimates.

• Durations of some activities vary greatly. The part of this variation that is due to specific possible events taking place can be managed by risk management techniques as discussed in Chapter 10. The other part of the variation, known as common cause or random variation, sometimes is just difficult to accurately estimate.

• Many project workers tend to use all of the time available to them. Instead of fin- ishing early and getting the work to the next person, they keep fine-tuning their work and turn it in on time.

EXHIBIT 8.15 FAST TRACKING EXAMPLE

Legend Activity Code

Duration

A

5

C

2

B

8

D

6

G

9

E

3

F

4

Chapter 8 Resourcing Projects 227

• To keep multiple projects moving, many workers are asked to multitask. Up to a point, multitasking is helpful in keeping multiple projects moving and keeping the workers stimulated. However, many people are asked to multitask far beyond that point; by not focusing on a limited number of things, they sometimes cannot give adequate attention to any.

One approach to address problems such as these is called critical chain project man- agement (CCPM). CCPM is also sometimes known as the critical chain method. The critical chain method is “a schedule method that allows the project team to place buffers on any project schedule path to account for limited resources and project uncertainties.”10

Simply put, rather than calculate the critical path based upon predecessor–successor relationships alone, it also incorporates calculations on resource availability. Once the resource that is most in demand is identified, efforts are made to keep that resource appropriately busy on critical chain activities (those critical both because of the predecessor–successor relationships and because of resource shortages) but not over- loaded. Other components of the CCPM system include the following:

• Avoiding multitasking • Estimating aggressively how quickly each activity can be completed • Putting a feeding buffer of time directly in front of critical chain activities to ensure

they will not be delayed • Putting the time normally reserved for the uncertainty in each individual activity at

the end of the project as a total project buffer that the project manager can use as needed

• Finishing activities early if possible and passing the work on to the next worker

Proponents of critical chain say it is a major innovation that helps to overcome some of project management’s most difficult scheduling and resourcing problems. Detractors say it is another approach that may work in certain circumstances. It requires a great deal of reeducation and communication on everyone’s part to make it successful, and when resources are reallocated from the buffer to a task in trouble, more work may be created.

8-8b Reverse Phase Schedules Another alternative scheduling method that is sometimes used in the construction indus- try is called a reverse phase schedule or Last Planner System. The reverse phase schedule is developed by the people closest to the work (often either the hands-on workers or the forepersons who directly supervise work) by starting with the final project deliverables and continually asking what needs to be completed prior to starting work on this deliv- erable. As each activity is defined, its order is established, and the person proposing it verifies that their company has the worker(s) to complete the activity as shown in the tentative schedule.

Using this method, the team systematically thinks from the end of the project toward the beginning. This is also a good practice to help ensure that both all of the project deliverables and the list of activities are complete because by working backward missing deliverables and activities tend to be easier to identify.

8-8c Rolling Wave Planning The idea behind rolling wave planning is to plan the first part of the project in as much detail as needed and to plan later portions only at a high level. This allows the project team to focus on the near term without ignoring the longer term. It means the project team needs to plan progressively more detail as information becomes available. Rolling

228 Part 2 Planning Projects

wave planning is illustrated near the end of Chapter 9 by showing a dummy activity for a late project phase. The extreme of rolling wave planning is agile.

8-8d Agile Project Planning The fundamental ideas behind agile project planning are to use a collaborative approach with workers and other stakeholders heavily involved in planning; to recognize that while it may be difficult to scope the entire project at the outset, stakeholders do want to have a ballpark idea of total cost, schedule, and functionality before approving a proj- ect; and to understand that while uncontrolled change is bad, too strenuous change con- trol often means valid emergent stakeholder wishes are not met. These ideas permeate the contemporary project management approach of this book. They have been intro- duced in several earlier chapters and identified with margin icons and are explained in more detail in the Project Management in Action example at the conclusion of this chapter.

8-8e Auto/Manual Scheduling Microsoft Project now includes a feature called manual scheduling to enable users to more closely emulate MS Excel. This may be comforting for users who are more familiar with Excel than Project. When people are chartering a project and want to show the few milestones without committing to dates, manual scheduling may be a good starting point. Also, for projects with few predecessor–successor relationships, manual scheduling may sometimes be useful. However, for the majority of projects, the ability of MS Project to plan and track activities based upon logical relationships is useful and suggests manual scheduling is not enough.

8-9 Using MS Project for Resource Allocation Up to this point, a project manager has created a file with a project in MS Project, cre- ated the WBS for the project, defined the predecessor–successor relationships among the tasks, entered the expected duration for each task, and shown the critical path in red. This covers the first two ways in which a project schedule may be constrained—namely the logical order of tasks and the expected duration of each. Now we consider the third way in which a schedule may be constrained—the number of key resources available when needed. For the final constraints on schedules, cash flow will be covered in Chapter 9 and imposed dates will be covered in Chapter 11. Using MS Project to under- stand resource limitations includes four steps:

1. Define resources. 2. Assign resources. 3. Identify overallocated resources. 4. Deal with overallocations.

We can perform the first three steps very well with MS Project alone, but need to consider managerial options as well as options MS Project can identify to deal with the overallocations.

8-9a Step 1: Defining Resources For a resource to be available to a project, it must be described in Microsoft Project’s database. A resource may be a single unit, such as a person, or a resource may be a pool of like units, such as five welding machines. Resources may include people, build- ings, materials, facilities, or supplies—anything necessary for the completion of a task.

A G I L E

Chapter 8 Resourcing Projects 229

If possible, resource information should be entered in advance of the time of assign- ment to a task. If entered at the time of assignment, only minimal information is sup- plied, and the resource detail information must be completed later.

While many fields can be used for defining resources, at a minimum, the Resource Name and Max Units fields need definition. If costs are to be modeled, then the Std. Rate, Ovt. Rate, Cost/Use, and Accrue At values must also be defined. See Exhibit 8.16. Steps in defining resources include:

1. On the View tab, Resource Views group, click Resource Sheet. 2. In the first blank row, enter the resource name in the Resource Name cell. 3. In the Initials cell, enter the initials of the resource. 4. Click the Max Units cell and enter the resource’s maximum availability.

Max Units defines the availability of a resource for project work. The default is 100 percent, but individual resources are not 100 percent available even if they are working full time on a project. Availability will be something less than eight hours if that is the normal working day. The unavailability includes general tasks required of employees. It can also include ongoing process work such as a part-time help desk role. For example, a person assigned primarily to one project may be available about six hours per day (or 75 percent) for that project. If so, 75 percent would be the Max Units for that resource. Note in Exhibit 8.16 that Chris is available up to 75 percent of his time for the project, while Uma is only available 50 percent of her time.

Things to consider when determining each resource’s Max Units value are as follows:

• Determine what is considered project work. • Determine what is not considered project work (100 percent Max Units). • Organizational holidays are accounted for in the Standard (MS Project) calendar. • Vacation days are accounted for in each resource calendar.

CALENDARS If a different project calendar is needed because one or more resources are working different days or shifts, or are subject to a different holiday schedule, the Base Calendar field is used to specify that different project calendar.

Resource calendars are used to block out vacation days and other resource-specific nonworking days. Resource calendars inherit project-wide working day definitions from the standard (MS Project) calendar at the time the resource is first defined. Resource calendars are used by MS Project to determine when a resource assignment can be scheduled. If a task has no resource assignment, then the project calendar is used to determine task scheduling.

EXHIBIT 8.16 DEFINING RESOURCES

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

230 Part 2 Planning Projects

8-9b Setting Up a Resource Calendar 1. Double click a resource row to activate the Task Information dialog for the resource

whose calendar needs revision. 2. On the General tab, click Change Working time… (see Exhibit 8.17). 3. Confirm the correct resource is chosen. The resource name is near the top of the

dialog. 4. Make revisions in the manner described in Chapter 6.

8-9c Step 2: Assigning Resources During resource assignment, a project manager allocates one or more resources to an activity. Microsoft Project then generates assignment information based on activity infor- mation, resource information, switch settings, and possible data overrides. Assigning a resource to an activity with no existing resource assignments (using default settings) includes the following steps and is illustrated in Exhibit 8.18.

1. On the Task tab, View group, click Gantt Chart. 2. Right click in the Start column header, click Insert Column and enter Work to add

the Work column.

EXHIBIT 8.17 RESOURCE INFORMATION DIALOG BOX, CHANGE WORKING TIME TAB

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 8 Resourcing Projects 231

3. On the view tab, in the Split View group, click on Details. 4. Right click the form in the lower pane and select Resources and Predecessors (if not

already present). 5. In the upper pane, click the activity row needing a resource assignment. 6. Click the next blank row in the Resource Name column in the lower pane’s form. 7. Enter the resource name from the drop-down list. 8. Repeat steps 6 and 7 to add additional resources to the assignment list. 9. Enter a units value if the Max Units value is not correct for any assignment.

10. Click the OK button. No assignment is made until the OK button is clicked. 11. Note that Work is calculated and the activity duration value did not change. Verify

that the assignment work and task work values reconcile with the estimated dura- tion value.

The following data are necessary for creating assignments:

• Duration is the number of time units between the activity start and end. The default display value is in days. Each day spans eight work hours, plus one nonworking hour after four hours have passed.

• Units represent the availability of a resource for work each day. This value is the same as the resource Max Units value unless it is overridden.

• Work (assignment) is calculated by multiplying the Duration value (converted to hours) by the Units value.

• Task type is a switch that determines which of three values (duration, units, and work) changes when one of the other two is modified. The switch settings are Fixed Units (default), Fixed Duration, and Fixed Work.

EXHIBIT 8.18 RESOURCE ASSIGNMENT

Select the activity (Step 5)

Enter a resource (Step 7)

Enter units value (Step 9)

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

232 Part 2 Planning Projects

BASIC ASSIGNMENT CALCULATION WITH FIXED UNITS SELECTED (DEFAULT SETTINGS) When an assignment is made, MS Project uses the Duration and Units values to calculate the number of hours a resource will work on the activity. The activity Duration and Work fields may be adjusted. The Work field value in an activity row (Task Usage view) is the sum of all of the assignment Work field values. The Work field value in a resource row (Resource Usage view) is the sum of all of the resource assignment work values.

• Activity with no prior resource assignments—MS Project uses the Duration and Units values to calculate the assignment work value and sums the assignment Work values into the activity Work field. The assignment of a 100 percent available resource (Units = 100%) to a two-day-duration activity (eight-hour days) results in sixteen hours of resource work across the two-day duration. An assignment of two 75 percent available resources (Units = 75%) results in twenty-four hours of work assigned across the two-day duration.

• Activity with one or more resources already assigned—when yet another resource(s) is added, MS Project holds the activity Duration value constant and adjusts the activity Work value. The addition of a 100 percent available resource (Units = 100%) to a two-day duration activity that has a 100 percent available resource already assigned results in thirty-two hours of activity work across the two- day duration activity, with each resource assigned sixteen hours of assignment work.

• Removal of resources works in reverse of the above. Removal of the resource from an activity with one resource assigned results in zero task work. Removal of one resource from an activity with two resources assigned results in the activity duration held constant, work calculated for the remaining resource assignment, and the activity work value the same as the assignment value.

MODIFYING AN ASSIGNMENT After an assignment is made, MS Project maintains a relationship among the Duration, Units, and Work values. With the Fixed Units as the Task Type:

1. Change the Duration, and MS Project changes the assignment work and task work values. 2. Change the Task Work, and MS Project changes the duration and assignment work

value(s). 3. Change an assignment units value, and MS Project holds the assignment work value

constant and changes the task duration.

Tips include the following:

• If you don’t like MS Project adjusting the Duration value as you add and remove resources assignments, an alternative is to switch the Task Type setting to Fixed Work. On the File tab, Options, Schedule page, enter Fixed Duration. Also on the same page, on the Scheduling Options for this Project field, enter All New Projects.

• When trying different resource assignments on an activity, it is easy to lose the original duration value, so save your original estimated duration value in a user- defined Duration or Work field. On the Task tab, click Gantt Chart, right click the Duration column heading, click Insert column and enter Duration 1. Then right click the Duration 1 heading, click Field Settings, and enter Estimated Duration in the Title box to name the column.

8-9d Step 3: Finding Overallocated Resources A resource overallocation usually occurs when a resource is assigned to two or more activities whose start and finish dates overlap, if only for a very small duration. An

Chapter 8 Resourcing Projects 233

overallocation can also occur if an assignment Units value is greater than the resource’s Max Units value.

MS Project has a good set of tools to help find and understand each overallocation. Once understood, you can make a management decision about an appropriate solu- tion. Most solutions cannot be automatically implemented. There is an MS Project feature (Level Resources) that resolves most overallocations by delaying the start of all but one of the conflicting activity assignments. This may produce an unacceptably lengthened schedule, so consider this as just one of many solution options. The Gantt Chart Indicators field will display a red stick figure symbol if an assigned resource is overallocated.

RESOURCE ALLOCATION VIEW With slight modification, the Resource Allocation view is very helpful. The Show in menu checkbox makes this view available in the View menu. The Detail Gantt marks the critical path (bold red) and graphically displays free slack following each activity, which shows how much the activity can be delayed before creating a new, longer critical path.

1. On the Task tab, View group, Gantt Chart drop-down menu, click More Views… 2. On the More Views dialog, scroll the Views display, enter Resource Allocation, and

click Edit. 3. On the View Definition dialog, click the Details Pane drop-down menu and enter

Detail Gantt. 4. On the View Definition dialog, click Show in menu. 5. Click OK, then click Apply. 6. In the upper pane, right click the Work column header and enter Insert Column. 7. Enter Max Units, then click Enter. 8. Add the activity Work column in the lower pane’s table to the left of the Leveling

Delay column (as above). 9. Hide the assignment rows in the upper pane’s table: right click in the Resource Name

field header to select all rows. On the View tab, Data group, Outline, enter Hide Subtasks.

The results of these steps can be seen in Exhibit 8.19.

EXHIBIT 8.19 VIEW DEFINITION DIALOG BOX

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

234 Part 2 Planning Projects

The Resource Allocation view is a combination view with the Resource Usage view in the upper pane and the Detail Gantt view in the lower pane. The time scale in the upper pane is synchronized with the Gantt graphic in the lower pane. Adjusting the zoom affects both panes.

The Gantt bars in the lower pane represent the duration of the work hours displayed in the upper pane. Selecting a resource in the upper pane’s table displays the assignments of that resource in the lower pane. Selecting a resource assignment in the upper pane displays information about that assignment in the lower pane.

Resource data displayed in red in the upper pane’s table mark that resource as over- allocated. In addition, if a yellow diamond with an exclamation mark is displayed in that resource’s Indicator field, the overallocation is probably more serious.

Project uses the resource Max Units value and a basis value (the default is day-by-day). If a resource is momentarily overloaded, the resource is marked overallocated. If the resource has enough time in one day to complete all assignments, the yellow diamond does not dis- play. If not enough time is available, then the yellow diamond is displayed.

In a task view, a red stick figure is displayed. In Exhibit 8.20, both Chris and Patrick are marked as overallocated. The total assignment hours are displayed in the upper pane. The Gantt bars in the lower pane represent each assignment.

A straightforward method of finding overallocated resources is as follows:

1. Set the timescale to the start of the schedule. 2. Slowly scroll the timescale toward the end of the schedule. 3. Analyze each instance of cell values displayed in red for cause and severity.

8-9e Step 4: Dealing with Overallocations Once overallocations have been identified, there are many possible things a project man- ager can do. The point to remember at this time is that MS Project is a tool only. It is very helpful in identifying overallocations, but the project manager is responsible for deciding what to do once the overallocation is found. Below are a few choices.

• Keep MS Project’s resource leveling function set to Manual (Resource Leveling dia- log box).

• Protect the schedule’s critical path. • Replace an overallocated resource with one that has time for the assignment. • Reduce the Units assignment, extending the activity duration.

EXHIBIT 8.20 RESOURCE USAGE AND DETAILED GANTT VIEWS

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

Chapter 8 Resourcing Projects 235

• De-scope the activity(ies). • If some assigned resources are performing little work, remove them. • Use the Leveling Delay task field to delay the start of one of the conflicting activities;

the duration value is in the elapsed duration form, in which all calendar days are included, not just working days. Continue adding delay until the delay creates a new critical path.

• Check the Network Diagram for accuracy—correcting errors may remove the conflict.

• Ignore the overload if the resource impact is temporary.

Tips include the following:

• Note the project finish date, work, and cost values. • Be aware of resource vacation days and organizational holidays. • If changing assignments, note the duration and work values for the task. • If swapping resources and there is a mix of units values among assigned resources, it

may be easier to remove all resource assignments and then reassign them. • Try Level Now (Resource Leveling dialog box, Tools menu); if the plan is suitable,

then go forward (delay is imposed). • Work from beginning to end. One fix may break something else.

Summary Resourcing projects goes hand in hand with scheduling (Chapter 7) and budgeting (Chapter 9). To ensure that adequate human and other resources are assigned to a project, first the project manager needs to look at the listed activities and estimate the resources needed to perform each. Potential resources need to be identified, and their availability needs to be confirmed. The proj- ect manager may need to negotiate to secure the ser- vices of the needed people. Usually, some people assigned to the project are ready to go, while others need training and/or mentoring. Project teams some- times need to rely on co-located and/or outsourced team members.

Several tools are useful in identifying and schedul- ing people. A human resource management plan with role descriptions and staffing management plan as components helps the team plan. Resource assign- ments are often posted directly on a Gantt chart schedule. RACI charts are matrices that depict work activities on the vertical scale (often in the form of a WBS) and the various people who are involved on the horizontal scale. Work responsibilities are shown by code in the cells. Once workers have been assigned, responsibility histograms can be developed for each worker to determine whether he or she is overloaded at any point.

The combination of the critical path schedule with resource assignments and the resource histogram

allows project planners to determine who is over- loaded, at what time, and by what activities. Resource leveling is the method of using this information to reduce the peak demands for workers by postponing some of the noncritical activities within the amount of available slack. Sometimes this solves the problem. If not, some work might be assigned to a different per- son, the schedule might be delayed, the project scope might be reduced, and/or other methods might be employed. Often, the sponsor will want to be involved in making these decisions.

Once the project schedule is established and resources are assigned, it sometimes appears that the hoped-for completion date is not attainable. In these cases, it is com- mon to look for methods of accelerating (or compressing) the project schedule. One frequently usedmethod is crash- ing, in which a decision is made to pay extra money (often in the form of overtime pay) to speed up certain activities on the critical path. Another frequently used method is fast tracking, whereby activities that are normally con- ducted in sequence are either overlapped or performed in parallel. Fast tracking can lead to faster schedules. How- ever, the risk is increased because the activity that normally is a successor depends on the output of its predecessor, and if that output is not as expected, the successor activity may need to be reworked.

Several alternative methods of scheduling can be used by themselves or combined with traditional

236 Part 2 Planning Projects

scheduling and resourcing. These methods include crit- ical chain, reverse phase, rolling wave, agile, and auto/ manual scheduling. Experienced project managers attempt to use the best ideas from several of these alternative approaches.

Project scheduling software such as Microsoft Proj- ect is extremely useful when determining the resources for a project. This software helps pinpoint exactly when

each worker is needed, for what activity, and where there are overloads. Despite the power of these sched- uling systems, they do not make all of the decisions for a project. The project manager needs to understand the output of the software and may be able to ask a number of what-if questions. Ultimately, the project manager needs to make the decisions—often in conjunction with the sponsor.

Key Terms from the PMBOK® Guide estimate activity resources, 211 plan human resource management, 212 staffing management plan, 212 responsibility assignment matrix, 216 RACI chart, 216

resource leveling, 220 crashing, 222 fast tracking, 222 critical chain method, 228

Chapter Review Questions 1. In addition to technical skills, what other skills

must a project manager have in order to suc- cessfully resource a project?

2. Why is it important to involve workers in the planning phase of a project when possible?

3. What does a staffing management plan address? 4. What are the three “r” activities that take place

near the end of a project, regarding team mem- bers and timing issues?

5. What does RAM stand for, and what is its purpose?

6. What does each column of a RACI chart depict? 7. Why is it best to only have one person assigned

primary accountability for an activity? 8. What can a project manager use to help deter-

mine if workers are overloaded?

9. Whom should the project manager consult when performing resource leveling?

10. What will happen to a project’s schedule if an activity on the critical path is delayed?

11. In regard to resource leveling, why are noncritical path activities generally the first to be delayed?

12. What are two techniques used to compress a project schedule?

13. When crashing a project, what two criteria are considered when deciding which activities to speed up?

14. In addition to predecessor–successor relation- ships, what does critical chain project manage- ment (CCPM) factor in to its scheduling?

15. Who develops the schedule when using Reverse Phase Scheduling?

Discussion Questions 1. Identify three examples of when a project man-

ager uses technical skills and three examples of when she uses behavioral skills.

2. Describe instances in which a project schedule is limited mostly by activities. Describe instances in which a project schedule is limited mostly by resources.

3. Describe the importance of activity resource estimating.

4. List at least four factors a project manager should consider when identifying individuals to work on a project. Why is each important?

5. Describe a potential timing issue that can occur early in a project and a potential timing issue that can occur at the end of a project. How would you address each of these issues in your project?

6. Describe two ways a project manager can resolve resource overloads. Under what circumstances should each be used?

7. Describe how to perform resource leveling. 8. Give an example of what is given up in a

project when it is crashed and when it is fast- tracked.

Chapter 8 Resourcing Projects 237

9. List problems with traditional project scheduling techniques and why some organizations might opt to use critical chain project management.

10. List three common problems that can occur when traditional critical path scheduling is used. How would you address each?

Exercises 1. A certain project has three activities on its critical

path. Activity A’s normal completion time is five days. It can be crashed to three days at a cost of $500. Activity B’s normal completion time is six days, and it can be crashed to four days at a cost of $50. Activity C’s normal completion time is eight days. It can be crashed to three days at a cost of $1,000. Which activity should the project manager crash and by how many days? How much will it cost?

2. Using the data for Problem 08.02, create the project schedule using normal times. Determine the order in which you would crash the project one day, two days, and so on until it is in an all- crash mode. Identify how much it would cost for each day you crash the schedule.

3. Using the data for Problem 08.03, create the project schedule using normal times.

Determine the order in which you would crash the project one day, two days, and so on until it is in an all-crash mode. Identify how much it would cost for each day you crash the schedule.

4. Using the data for Problem 08.04, create the project schedule in MS Project. Be sure to use both the predecessor relationships and the re- source assignments. Use a split screen to show both the Gantt chart with critical path and resource assignments with overloads.

5. Using the data for Problem 08.05, create the project schedule in MS Project. Be sure to use both the predecessor relationships and the resource assignments. Use a split screen to show both the Gantt chart with critical path and resource assignments with overloads.

PMBOK® Guide Questions 1. When planning the resources needed for a proj-

ect, the project manager typically focuses on: a. people b. equipment c. material d. all of the above

2. A ______ addresses when and how project team members will be acquired and how long they will be needed. a. resource histogram b. staffing management plan c. project organization chart d. responsibility matrix

3. The process “Estimate Activity Resources” involves identification of the ___ and ___ of resources required for each activity within a work package. a. types; quantities b. costs; quantities c. names; locations d. types; costs

4. Recognition and rewards _____________. a. should be used on rare occasions, for excep-

tional performance b. are the responsibility of the functional manager c. should be included in the project’s Staffing

Management Plan d. are perquisites reserved for the project man-

ager and project sponsor 5. A “schedule compression technique in which

activities or phases normally done in sequence are performed in parallel for at least a portion of their duration” is referred to as ______. a. critical path b. critical chain c. crashing d. fast tracking

6. In a RACI chart the single individual who will have to provide an explanation if something goes wrong is indicated with a(n) ___: a. R—Responsible b. A—Accountable

238 Part 2 Planning Projects

c. C—Consult d. I—Inform

7. The “process of identifying and documenting project roles, responsibilities, required skills, reporting relationships, and creating a staffing management plan” is called: a. Identify Stakeholders b. Create Stakeholder Management Strategy c. Plan Human Resource Management d. Acquire Project Team

8. After creating a Staffing Management Plan, the project manager and team might create a chart that provides a visual representation of project resource needs by type of resource and time period (weeks, months etc.) This chart is called a _______. a. project Gantt chart b. resource histogram c. network diagram d. organization chart

9. An iterative planning technique where “the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level” is referred to as _______: a. three point estimating b. rolling wave planning c. parametric estimating d. analogous estimating

10. When the demand for resources is greater than the available supply, the project manager can use a scheduling method that adjusts the start and finish dates of activities in order to address resource limits or constraints. This technique is called: ___________. a. fast tracking b. crashing c. resource leveling d. critical path method

Example Project For your example project, create the following:

1. A Human Resource Management plan including role descriptions and staffing management plan

2. RACI chart

3. Gantt chart with resource assignments 4. Histogram of demands on each key participant’s

time 5. Plan for resolving resource overloads

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Brown, David, “Top 10 Steps to Schedule Manage- ment,” Electrical Construction and Maintenance (March 2008): C22–C28.

Butler, Charles W., and Gary L. Richardson, “A Vari- able Time Project Planning and Control Model,” Journal of Management Policy and Practice 12 (6) (2011): 11–19.

Gagnon, Michel, “A Method of Integrating Personnel into the Project Schedule,” Proceedings, PMI Research Conference 2006 (Montreal, July 2006).

Grant, Kevin P., and Michael R. Baumann, “Leveraging Project Team Expertise for Better Project Solutions,” Proceedings, PMI Research Conference 2006 (Mon- treal, July 2006).

Haugan, Gregory T., Project Planning and Scheduling (Vienna, VA: Management Concepts, Inc., 2002).

Leach, Larry P., “Critical Chain Project Management Improves Project Performance,” Project Manage- ment Journal 30 (2) (June 1999): 39–51.

Piney, Crispin, “Critical Path or Critical Chain: Combining the Best of Both,” PM Network 14 (12) (December 2000): 51–55.

“PMI Code of Ethics and Professional Conduct,” PMI Today (December 2006): 12–13.

Rad, Parviz, and Vittal Anantatmula, Project Planning Techniques (Vienna, VA: Management Concepts, Inc., 2005).

Trietsch, Dan, “Why a Critical Path by Any Other Name Would Smell Less Sweet?” Project Manage- ment Journal 36 (1) (March 2005): 27–36.

Tsou, Chi-Ming, “On the Project Management Scheduling Based on Agent Technology and Theory of Constraint,” International Journal of Electronic Business Management 10 (4) (2012): 286–295.

Chapter 8 Resourcing Projects 239

http://www.ambysoft.com/essays/agileProjectPlanning. html, accessed May 22, 2013.

http://www.youtube.com/watch?v=IExA5fuWFgg, accessed May 22, 2013.

http://jbep.blogspot.com/2010/01/rolling-wave-plan- ning-or-sliding.html, accessed August 3, 2010.

http://www.brighthub.com/office/project-management/ articles/8717.aspx, accessed August 3, 2010.

http://office.microsoft.com/en-us/project-help/fast- track-tasks-to-shorten-your-project-schedule- HA010036399.aspx, accessed August 3, 2010.

http://en.wikipedia.org/wiki/Critical_Chain_Project_ Management, accessed August 3, 2010.

Endnotes 1. PMBOK® Guide 539. 2. PMBOK® Guide 550. 3. PMBOK® Guide 563. 4. Adapted from Parviz Rad and Vittal Anantatmula,

Project Planning Techniques (Vienna, VA: Manage- ment Concepts, Inc., 2005): 68–72.

5. PMBOK® Guide 559.

6. PMBOK® Guide 557. 7. PMBOK® Guide 559. 8. PMBOK® Guide 535. 9. PMBOK® Guide 540.

10. PMBOK® Guide 536. 11. Ken Schwaber and Mike Beedle, Agile Software

Development with Scrum (Prentice Hall, 2001).

PROJECT MANAGEMENT I N ACT I ON

Managing Software Development with Agile Methods and Scrum

The Scrum process was described for use in agile software development by Ken Schwaber and Mike Beedle. Exhibit 8.21 illustrates the Scrum process.

In practice, many agile methods and variations are utilized, but they all share a basis in iterative development, extensive verbal communication, team interaction, and the reduction of resource-intensive

intermediate products. Agile software development methods attempt to minimize risk via short time boxes called iterations or Sprints. Typically, the time boxes are from one to a maximum of four weeks and usually include numerous subtasks. Each Sprint is frequently like a software development project in and of itself and includes planning, requirements analysis, design,

EXHIBIT 8.21 SCRUM APPROACH TO NEW PRODUCT DEVELOPMENT PROJECTS

5–20 Day Cycle with Daily SCRUM

Sessions

Incremental Product

Prioritized Backlog

Sprints Integration

& QA Testing

Source: Adapted from Ken Schwaber and MikeBeedle, Agile Software Development with SCRUM (Prentice Hall, Upper Saddle River, NJ 2001).

240 Part 2 Planning Projects

coding, testing, documentation, and validation of deliverables. Some iterations may generate new products or capabilities, but most are integrated into larger groups to be released as new products. Scalability is one of the benefits of the approach, and another is the opportunity to reevaluate priorities in an incremental fashion. This technique, therefore, can be used effectively for software maintenance and enhancements, as well as new product development.

Scrum is facilitated by a scrum master who organizes the project like any good project manager. This person has the primary task of removing impediments to the ability of the team to deliver the Sprint goal and project objectives. The scrum master is not necessarily the leader of the team in the traditional formal sense (as the teams are self-organizing), but acts as a productivity buffer between the team and any destabilizing influences. This encourages the emergence of informal leadership and team cohesiveness. Scrum includes the following elements, which define the process:

• A dynamic backlog of prioritized work to be accomplished

• The use of short iterations or Sprints

• A brief daily meeting or Scrum session during which progress is explained, upcoming work is described, and impediments are identified and if possible immediately resolved

• A brief planning session during which the prioritized backlog of items for the Sprint is identified and fur- ther defined by the team

• A brief retrospective during which all team members reflect about the past Sprint and any design or other influences on future Sprints or objectives

This approach keeps everyone on the team engaged and focused. It works very well when everyone is co-located to facilitate verbal communications, but has been shown to work well in virtual teams or geographically dispersed teams as well. The emphasis on verbal communications has proven to be particularly useful for international teams where written communications alone may not be clearly understood. The use of video conferencing and virtual development environments is also beneficial in these situations.

Agile software development teams include all resources necessary to accomplish the tasks and finish the software product. This includes designers, architects, analysts, testers, technical writers, managers, and customers (the people who define the final product).

The primary metric for progress in this environment is working software based on the scope as identified in the Sprints. Schedules and other resources are based on accomplishing the Sprints and removing impediments. With their preference for verbal communications, agile methods produce little written documentation relative to other methods. That is not to say that the team produces no documentation, as it is important to have requirements, design, and other aspects of the software product documented to facilitate maintenance and support and in some cases to meet industry regulatory compliance requirements. This reduced emphasis on documentation has resulted in criticism of agile methods as undisciplined or, as some have called it, “cowboy coding.” As a rule, this does not seem to be the case in practice because, if properly implemented, the requirements are documented in the prioritized backlog; the design is documented in the Sprints and Scrum sessions; and the testing, user, and technical documents complete the documentation set. It is important to note that the use of a scribe during Scrum sessions, planning, or retrospective sessions is vital to capture what is transpiring, since the sessions tend to be short and intense by nature.

Many companies have now embraced the agile methods to reduce development time, foster innovation, and reduce development risk. One example is a Seattle-based company that has utilized Scrum to shorten development cycle time and improve quality for software deliveries to its clients. It uses Sprints to group similar requirements and provide a two-week window of work for its developers. Daily Scrum sessions help it stay focused and deal immediately with impediments. This works ideally, in that it keeps task scope to a minimum for the developers, and everyone on the team is aware of what is transpiring throughout the development process. This has shortened development time and led to more rapid release of products and enhancements to the clients, thus reducing development costs and improving margins.

Chapter 8 Resourcing Projects 241

Another example is an Ohio company that utilizes agile methods and Scrum for software development for clients in the highly regulated pharmaceutical, bio-tech, and medical device industries. A recent software system developed to be used in manufacturing data acquisition and control for products requiring complete traceability, including raw materials and processes, was designed and developed in five months to beta delivery. The software will ultimately track and control all of the company’s production when fully implemented. The system was put into a pilot manufacturing line. It was working within thirty minutes of software installation and processed product through the pilot production facility the same day without a glitch. The system was delivered essentially bug-free. This was unheard of previously using traditional development methods and would have taken a year or more to get to beta delivery,

with many more issues. The company accounts for this success due to the use of the agile process, Scrum, and thorough quality testing. The requirements in this regulated environment were developed in a traditional manner; however, once the requirements were approved by the client management, the Scrum approach was used, which represented a departure from the traditional waterfall approach. Each module of the system was developed separately using the Scrum approach by focusing on developing a few design elements at a time rather than trying to focus on the entire system design at once. In this way, the development team could focus and accomplish a few things at a time and leave the big picture design and architecture to the scrum master and development management. Use of this approach exceeded all expectations.11

Source: Warren A. Opfer, CCP, PMP®.

242 Part 2 Planning Projects

CHA P T E R 9 Budgeting Projects

I sold escalators and elevators for my first job out of business school. As part of my training, before I was sent to the field, I would look over the estimates made by the sales staff. This served to double-check their math so the company had confidence in their estimates. It also served to teach me many of the little nuances that more experienced estimators used. I had my training manuals, lists of standards, main methods of calculation, and so forth, but learning from others’ experience instead of making all my own mistakes helped.

One of the last parts in my training was to spend eight weeks at the Denver branch to get seasoned a little bit. Construction was booming in Denver during the late 1970s. In fact, some days I needed to bid more than one job. The first part of putting together a bid was to go the office where the requests for proposals, plans, specifications, and the like were stored. Then, armed with that information, I would put together an estimate. Finally,

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Define project cost terms and tell how each is used in estimating project cost.

• Compare and contrast analogous, parametric, and bottom-up methods of estimating cost.

• Describe issues in project cost estimatingandhowto deal with each.

• Create a time-phased, bottom-up budget for a project.

• Show both summary and bottom-up project budget information with cumulative costs using MS Project.

© Di eg o Ce rv o/ Sh ut te rs to ck .c om

244

Topics:

• PlanCostManagement

• Estimate cost

• Determine budget

• Control cost

the actual bidding took place—usually over the phone. The problem was that creating a detailed estimate would generally take at least half a day. If that was my only duty (it was not), I would still have had a hard time when multiple jobs were let for bid on the same day. Something had to give.

Every morning around 10 A.M., I met the construction superintendent for coffee. We would discuss each bid that was due. What other job was it like? How was it bigger or smaller than a recently completed job? What features did it include more or less than a previous job? Did we make money on that job? We used these questions to compare an upcoming job to other recently completed jobs. We would also ask, “What do we think our competition will bid?” By the end of the conversation, we had determined our strategy for bidding the job. If we won the bid, we would complete a detailed cost estimate to see if we were close.

After my training, I was transferred to Kansas City. Kansas City had less construction than Denver. I had enough time to perform detailed cost estimates before I submitted bids. Therefore, we were more certain that if we got the bid, we would have a good chance of making money.

I worked for the same company in both cities. However, we used two very different methods of estimating cost. Both made sense where they were used. In Denver, if we wanted to bid every job (and you cannot win the job if you do not bid on it), we needed a fast method. In Kansas City, we had the time to develop detailed cost estimates, and so we took the time. There are many methods of estimating project costs and each has its place.

Timothy J. Kloppenborg

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative Closure

Planning Executing Closing RealizingInitiating

RealizedResultTo Proceed

PMBOK® GuidePMBOK® Guide

245

9-1 Plan Cost Management This chapter starts with estimating project costs. Once the overall cost is estimated, the next step is to develop the budget by aggregating the costs and determining the project’s cash flow needs. Project managers also need to establish a system to report and control project costs. The final chapter section deals with how to use Microsoft Project to aid in cost management activities.

Cost and schedule are closely related. Sometimes, the two move in the same direction. For example, when a schedule calls for materials to be delivered, or for workers to perform, money needs to be available to pay for the materials or workers. Sometimes, they move in opposite directions. For example, if a project needs to be completed earlier than planned, more money will probably need to be found to pay for overtime.

Plan cost management is “the process that establishes the policies, procedures, and documentation for planning, managing, expending, and controlling project costs.”1 Cost planning entails developing a cost management plan for your project. The cost manage- ment plan is “a component of the project management plan that describes how costs will be planned, structured, and controlled.”2 On small projects, this can be as simple as ensuring accurate estimates are made, securing the funding, and developing cost report- ing procedures to ensure that the money is spent correctly. On large projects, each of these processes can be much more involved; in addition, developing and using accurate cash flow estimates become critical. A project cost management plan includes descrip- tions, procedures, and responsibilities for:

• Costs included (such as internal and external, contingency, etc.), • Activity resource estimating, • Cost estimating, • Budget determination, and • Cost control, including metrics, reporting, and change approvals.

A project cost management plan needs to be consistent with the methods of the parent organization. In many organizations, project managers are provided with specific guidance on setting up their cost management plan. The plan provides guidance to the project manager and other stakeholders in order to serve several purposes:

• First and most fundamentally, it shows how to develop and share relevant, accurate, and timely information that the project manager, sponsor, and other stakeholders can use to make intelligent and ethical decisions.

• It provides feedback, thereby showing how the project’s success is linked to the business objectives for which it was undertaken.

• It provides information at a detailed level for those who need details and at appropriate summary levels for those who need that.

• It helps all project stakeholders focus appropriately on schedule and performance as well as cost.3

9-2 Estimate Cost Estimate cost is “the process of developing an approximation of the monetary resources needed to complete project activities.”4 Cost estimating is linked closely with scope, schedule, and resource planning. To understand cost well, a project manager needs to understand what the work of the project includes, what schedule demands exist, and what people and other resources can be used. As more of this detail becomes known, the cost estimates can be more precise.

246 Part 2 Planning Projects

The first principle in dealing with project costs is for the project manager to never lie to himself. Many times, in dealing with project costs, the project manager will need to negotiate with sponsors, customers, and other stakeholders. If he does not understand what the project costs really are, he is just trading meaningless numbers. That is neither an effective nor an ethical method of establishing and committing to sensible budgets.

The second principle in dealing with project costs is for the project manager to never lie to anyone else. Since sponsors, customers, and other stakeholders can often drive hard bargains, it is sometimes tempting to shade the truth to secure necessary funding. This is wrong on two counts. First, it is ethically wrong. Second, as a practical matter, a project manager’s reputation goes a long way for good or for bad. People are more inclined to work with project managers who are viewed as being honest and trustworthy.

To estimate project costs accurately, the project manager must understand the various types of cost, the timing and accuracy of cost estimates, the different methods that can be employed to estimate costs, and a variety of cost estimating issues.

9-2a Types of Cost Costs can be better understood by considering various types of classifications such as those shown in Exhibit 9.1.

FIXED VERSUS VARIABLE COSTS Cost can first be classified as either being fixed or var- iable. Fixed costs are those that remain the same regardless of the size or volume of work. For example, if you need to buy a computer for your project, the cost is the same regardless of how much you use it. Variable costs are those that vary directly with volume of use. For example, if you were building a cement wall, the cost of the cement would vary directly with the size of the wall. To understand the importance of fixed versus variable costs, a proj- ect manager ideally structures costs and the impact of changes on those costs. When a project manager understands how big a project is likely to be, she will try to determine how to complete all of the project work for the least cost. On many projects, there are choices of how to perform certain activities. Some of these choices reflect a high-fixed-cost and low- variable-cost alternative such as buying an expensive machine that can make parts with low variable costs versus a more manual process of inexpensive machines but high labor costs. These choices require both some fixed and some variable costs. Ideally, the cost curve for

EXHIBIT 9.1 COMPARISON OF COST TERMS

Fixed Variable

Direct Indirect

Recurring Nonrecurring

Regular Expedited

Internal External

Lease Purchase

Labor Material

Estimate Reserve

Source: Adapted from Kim LaScola Needy and Kimberly Sarnowski, “Keeping the Lid on Project Costs,” in David I. Cleland, ed., Field Guide to Project Management, 2nd ed. (Hoboken, NJ: John Wiley & Sons, 2004): 145–147.

Chapter 9 Budgeting Projects 247

the expected project volume appears as shown in Exhibit 9.2. This reflects the lowest possible total cost at the size the project is expected to be. Unfortunately, problems may occur if the volume of the project work is substantially larger or smaller than first expected. If the volume drops a little bit, the total costs may drop very little. If the volume expands a little, the costs may go up significantly. Therefore, when considering fixed and variable cost choices, it is important to understand the project scope.

DIRECT VERSUS INDIRECT COSTS A second classification divides project costs into direct and indirect costs. Direct costs are those that only occur because of the project and are often classified as either direct labor or other direct costs. For example, direct labor includes workers who are hired specifically to work on the project and who will be either assigned to a new project or released when the project is complete. Other direct costs may include such items as materials, travel, consultants, subcontracts, purchased parts, and computer time.

Indirect costs are those that are necessary to keep the organization running, but are not associated with one specific project. The salaries of the company executives and the cost of company buildings, utilities, insurance, and clerical assistance are examples. These costs are allocated among all of the projects and other work that benefit from them. The methods of allocating these costs have evolved in recent years thanks to activity-based costing, as described in the cost estimating issues section. Exhibit 9.3 shows both direct and indirect costs for a work package.

RECURRING VERSUS NONRECURRING COSTS The third cost comparison is recur- ring versus nonrecurring costs. Recurring costs are those that repeat as the project work continues, such as the cost of writing code or laying bricks. Nonrecurring costs are those that happen only once during a project, such as developing a design that, once approved, guides the project team. Nonrecurring costs tend to occur during project planning and closing, while recurring costs tend to occur during project execution.

REGULAR VERSUS EXPEDITED COSTS A fourth cost comparison is regular or expedited. Regular costs are preferred and occur when progress can be made by normal work hours and purchasing agreements. Expedited costs occur when the project must be conducted faster than normal and overtime for workers and/or extra charges for rapid

EXHIBIT 9.2 PROJECT COST AND VOLUME CURVE

Total cost

Expected project volume

Volume

248 Part 2 Planning Projects

delivery from suppliers are necessary. The comparison of these costs shows why it is vital to understand schedule pressures and resource demands as costs are estimated.

OTHER COST CLASSIFICATIONS The next several cost comparisons require little explanation. They are helpful to understand both in structuring the cost estimates and as checklists to help remember items that may be forgotten. One comparison is costs internal to the parent organization versus those external to it. Major external cost items such as equip- ment can be either leased or purchased. Direct cost items are often labor or materials.

Estimate versus reserve costs form the next comparison. The estimate is “a quantified assessment of the likely amount… It should always include an indication of accuracy.”5

The reserve is “a provision in the project management plan to mitigate cost and/or schedule risk. Often used with a modifier (e.g., management reserve, contingency reserve) to provide further detail on what types of risk are meant to be mitigated.”6

Management reserve is “an amount of the project budget withheld for management control purposes… for unforeseen work that is within the scope.”7 By contrast, contin- gency reserve is “budget within the cost baseline that is allocated for identified risks that are accepted and for which contingent or mitigating responses are developed.”8

Just as uncertainly exists when estimating how long an activity will take, there is uncertainty regarding how much an activity will cost. Some activities are easy to estimate with precision. Other less familiar activities have many uncertainties, and estimating their cost is more like guessing. If one were to estimate conservatively on each uncertain activity, the total estimate for the project would likely be too high to be approved. To overcome this problem, project managers are encouraged to estimate at least a bit more aggressively. That means some activities will run over their estimates, while others will cost less. Project managers frequently add contingency reserve to cover the activities that run over their aggressive estimates.

EXHIBIT 9.3 DIRECT AND INDIRECT COSTS IN A WORK PACKAGE

PROJECT: ACCOUNTS PAYABLE REFINEMENT

WORK PACKAGE: INSTALL MODULE 1

Description: Install accounts payable refinement application and related hardware.

Deliverable(s): Installed and functioning accounts payable module.

Cost Categories Quantity Total

Direct Labor

Programmer 120 hrs @ $ 75/hr 9,000

Systems Analyst 40 hrs @ $ 100/hr 4,000

Systems Architect 20 hrs @ $ 120/hr 2,400

Other Direct

Hardware 20,000

Software 8,400

Consultant Services 12,000

Direct Overhead (.6 * DL) 9,240

Total 65,040

Source: Kevin P. Grant, University of Texas, San Antonio. Adapted with permission.

Chapter 9 Budgeting Projects 249

9-2b Accuracy and Timing of Cost Estimates Project managers need to understand when cost estimates should be developed, how accurate they need to be, and how they will be used. During project initiation, many project managers need to develop cost estimates to have their project charters approved. At this point, very little detail is understood regarding the project, so the estimates are only approximate. However, as the scope becomes well defined in the work breakdown structure (WBS), schedules are planned, and specific resources are assigned, the project manager knows much more and can estimate more precisely. Many organizations have specific names and guidance for their estimates and these vary widely. Normally, estimates should be documented, and the level of confidence in the estimate should be described. Exhibit 9.4 shows several points regarding different types of project cost estimates.

ORDER OF MAGNITUDE ESTIMATES Several things should be noted from these com- parisons. First, estimates go by several different names. For example, order of magnitude estimates that are often used to seek initial charter approval are also sometimes called “ball park,” “conceptual,” “initial,” or “level-one” estimates. These early estimates are often created during the project initiating stage when very little detail is known about the project. At this point, a very rough order of magnitude estimate that could underestimate the project by as much as 100 percent (that is, the final cost could be double the initial estimate) may be the only possible estimate. There is no way to really know how accurate an estimate is until the project has been completed, but with less detailed knowledge concerning the project in the initiating stage, there is likely to be a larger margin of error. Order of magnitude cost estimates and the parallel high-level looks at each of the other planning areas can quickly give enough information to decide whether to approve the project charter and begin to invest time and money into detailed planning.

EXHIBIT 9.4 PROJECT COST ESTIMATE COMPARISONS

Approval

Closing

Admin. Closure

Level of Effort

Stage Initiating

Charter

Planning

Project Plan

Executing

Project Result

Estimate Name

Order of Magnitude Budget Definitive

Accuracy Level

−40% to +100%

−30% to +50%

−10% to +15%

Possible Method

Analogous Parametric Bottom-Up

Rolling Wave

250 Part 2 Planning Projects

BUDGET AND DEFINITIVE ESTIMATES Once a project manager enters into the more detailed planning stage, it is generally possible to create a more accurate cost estimate. This is the same thought that goes into creating a more detailed project schedule, resource estimates, risk profiles, quality plans, and communications plans. Depending on the complex- ity and size of their projects and organizational norms, some project managers can proceed directly to definitive cost estimates at this point. Others may still need to look at one or more intermediate levels of detail before they have enough detailed knowledge to create cost estimates with accuracy. At the end of project planning, cost estimates should have a small enough margin of error that they can be used to create a project budget, show cash flow needs, and be used as a basis for controlling the project. Most project organizations want an accuracy level of no more than plus or minus 10 to 15 percent, and some require consider- ably better, such as plus or minus 5 percent.

Especially on complex projects such as research and development of major new products, project managers may use rolling wave planning to estimate costs. They do this by creating a definitive estimate for the first stage of the project (and committing to it) and an order of magnitude estimate for the remainder of the project. As the work on the first stage proceeds, the project manager then creates a definitive estimate for the second stage and reevaluates the order of magnitude estimate for the remainder of the project. At each stage, the project manager has more information than at the preceding stage and can create more accurate estimates.

9-2c Methods of Estimating Costs Many methods can be used for estimating project costs. Most of the methods are varia- tions of one of the following techniques. While these methods can sometimes also be used to estimate project scope or duration, in this chapter the discussion centers on using them to estimate project cost. Exhibit 9.4 indicates that as more details of a project are known as planning progresses, more detailed estimating methods may be used. However, Exhibit 9.5 shows that even at the end of project planning, a project manager

EXHIBIT 9.5 WBS DEPICTING ESTIMATING METHODS

PM

Project

AB CD EF

Level 1

2

3

4

5

Work Packages

Bottom-up Analogous Analogous Parametric

Source: Kevin P. Grant, University of Texas, San Antonio. Adapted with permission.

Chapter 9 Budgeting Projects 251

may sometimes use a combination of cost estimating methods. If the organization has accurate enough analogous and parametric estimating methods and capable estimators, sometimes portions of a project can be estimated by those methods instead of the more detailed (and time-consuming) bottom-up methods. The method used should account for the extent of complexity, risk, interdependencies, work force specialization, and site-specific issues of the project.9

ANALOGOUS ESTIMATING Analogous estimat- ing is “a technique for estimating the duration or cost of an activity or a project using historical data from a similar project.”10 Analogous estimating was the method used in Denver in this chapter’s open- ing vignette. To create a bid for a project—in this

case, the installation of elevators—a similar project was considered as the starting point. Immediately, questions were asked regarding how this job compared in size and complexity with the previous job. Several things need to be in place for analogous estimates to be effective. First, the organization needs to have experience in performing similar projects and know how much each of those projects actually cost (not just what they were estimated to cost). Second, the estimator needs to know how the proposed project differs from the previous project. Third, the estimator needs to have experience with the methods by which the project will be performed. In the example, sales and construction people jointly discussed how much the project would cost.

PARAMETRIC ESTIMATING Parametric estimating is “an estimating technique in which an algorithm is used to calculate cost or duration based on historical data and project parameters.”11 A bit more information is needed to complete a parametric cost estimate. Exhibit 9.5 shows this graphically by suggesting that another level of detail in the WBS might be used. In the chapter opener example of estimating the cost of elevator installation projects, parametric estimates might involve finding a bit more information regarding the project. For example, one might want to know how tall the elevator was, how fast it needed to travel, how large the platform would be, the trim level, the complexity of the controls, and the like. Each of those factors would have an impact on the elevator installation cost. For example, the cost per foot trav- eled might be calculated (this would cover the cost of providing and installing guide rails, wiring, etc.). Another cost might be associated with speed because faster eleva- tors require bigger motors, more stability, stronger brakes, and so on.

BOTTOM-UP ESTIMATING Bottom-up estimating is “a method of estimating project duration or cost by aggregating the estimates of the lower-level components of the WBS.”12 For a bottom-up estimate, the WBS needs to be broken down to the most detailed level, and the specifications need to be very clear. In the elevator example, bottom-up estimates were created in Kansas City. Details to be estimated included exactly how many buttons the control panel had, exactly what kind of light fixtures were mounted in the ceiling, what kind of finish was requested, and so on. The cost was estimated for each item. For example, for the process of installing the guide rail, first

Parametric estimating can be used to determine the impact of variables on project costs.

© Ro be rt N ic ke ls be rg /G et ty

Im ag es

252 Part 2 Planning Projects

there was a small amount of time, such as one hour, to set up or get everything in place to do this step. Then, it took a certain fraction of an hour of labor to secure each foot of the rail into position. A material charge was incurred for the guide rails themselves and the fasteners that held them in place. The cost of supervision was charged for the fore- person who ensured the work was scheduled and performed properly. Finally, overhead costs (indirect costs) were allocated to each dollar of fixed costs.

Bottom-up estimating is the most detailed, time-consuming, and potentially accurate way to estimate. Many projects use this method eventually to serve as a basis for estimat- ing cash flow needs and for controlling the project. One important caution on bottom- up estimating is to ensure that every item is included. If a portion of the project is left out, that portion is underestimated by 100 percent! Some organizations first create a bottom-up estimate and then compare it to a top-down view to consider adjusting it if the top-down view yields a much higher number. Exhibit 9.6 summarizes differences in cost estimating methods.

9-2d Project Cost Estimating Issues Regardless of what method is used to estimate project costs, several issues need to be considered. Some of these issues are pertinent to all projects; others only pertain to certain projects. These issues are shown in Exhibit 9.7.

SUPPORTING DETAIL Supporting detail for project cost estimates includes describing the scope, method used to create the estimate, assumptions, constraints, and range of possible outcomes. The project scope tends to be the least well defined at the project out- set and becomes increasingly well-defined throughout project planning. Each estimate should state exactly what scope it involves. Version control is critical for this.

The method used might be analogous, parametric, or bottom-up. The name of the method and exactly how the method is used should be described.

When creating an estimate, many assumptions and constraints are used. Assumptions should be outlined because two different people coming from two different backgrounds

EXHIBIT 9.6 COST ESTIMATING METHOD COMPARISON

ANALOGOUS PARAMETRIC BOTTOM-UP

Amount of Information Required Least Middle Most

Amount of Time Required Least Middle Most

Accuracy Obtained Lowest Middle Highest

EXHIBIT 9.7 ISSUES IN PROJECT COST ESTIMATING

Supporting detail Activity-based costing

Causes of variation Life cycle costing

Vendor bid analysis Time value of money

Value engineering International currency fluctuations

Chapter 9 Budgeting Projects 253

may assume that two different things will happen. Even if everyone involved with plan- ning a project assumes the same thing, it still may not happen. Assumptions that are not true often cause more work or other problems for a project. As more detail becomes known, a project manager may review assumptions with an eye toward uncovering assumptions that have now proven to be false. When this happens, the project manager can investigate any impact this may have on the project budget (and schedule and scope). Examples of assumptions that may arise when estimating the cost of direct labor might include the following:

• Workers will be paid at the prevailing wage rate of $14 per hour. • Workers are already familiar in general with the technology being used on the

project. • Workers will be paid for 40 hours per week whether there is always that much work

for them or not. • Overtime will never be authorized. • The project schedule can be delayed if the only alternative is to pay overtime.

Constraints are also important to bring to the surface since they often dictate the methods available for performing the project work. Examples of constraints include:

• Only in-house workers will be used. • No extra space will be provided. • No extra budget will be allowed. • The current version of the XYZ software will be incorporated into the design.

The range of possible outcomes should always be stated with any project cost esti- mate. If the range is not stated, people may lock onto the first number they hear. If the actual project costs could be 100 percent higher than the order of magnitude estimate, the project manager had better state that loud and clear, or she may find herself contin- ually explaining why she is grossly over budget. In fact, many estimators resist giving an order of magnitude estimate because they fear they will be held to it. A natural tension exists between managers who try to effectively manage their departments by establishing budgets as soon as possible and project managers who try to provide budget estimates as late as possible (once they know more about the project).

CAUSES OF VARIATION There are many causes of variation in project costs. On rou- tine projects using proven technology and an experienced and well-known project team, the causes may be relatively few and easy to categorize. On other projects where some of these factors are not true, more causes of uncertainty in project costs may exist, and some of those may be from unknown sources. Statisticians classify variation as coming from either normal or special causes, as shown in Exhibit 9.8.

Variation occurs in all work processes. The more routine a process is and the more work is driven by machines, the less variation occurs. Projects, however, tend to have novel work and high human interaction, so there are many opportunities for variation. Normal variation comes frommany small causes that are inherent in a work process. For instance, the variation in the productivity of a programmer writing code could be from phone calls, instant mes- sages, and in-person interruptions that occur each day. Special cause variation, on the other hand, is when something out of the ordinary occurs. For example, a lightning strike could cause such a large power surge that it overwhelms the normal protectors and destroys some of the computers. Most causes of variation are of the normal variety, and improving work methods (as discussed in Chapter 11) can help to reduce this type of variation. Special causes, however, are handled more as risks as discussed in Chapter 10. Both types of variation add to project costs and need to be considered.

254 Part 2 Planning Projects

VENDOR BID ANALYSIS On some projects, most or all of the cost is internal to the parent organization. On other projects, a substantial portion of the budget goes to se- curing services and supplies from vendors. Vendor bid analysis is used to determine whether the price being asked by the vendors appears to be reasonable. If several ven- dors compete for the work, it is reasonable to believe that the lowest responsible offer is fair. In the absence of competition, however, other methods may be needed to en- sure a fair price. On some items, prices are determined in the marketplace and re- ported in business papers and websites for anyone to read. On specialized services and products, one often must negotiate with a vendor. In the absence of any other method, for an expensive item, a project manager may need to develop a should cost estimate. That is, try to determine how much effort the vendor may need to expend and add a fair profit margin to arrive at the price you believe the vendor should charge.

VALUE ENGINEERING Value engineering is “an approach used to optimize project life cycle costs, save time, increase profits, improve quality, expand market share, solve problems, and/or use resources more effectively.”13 Value engineering can be a very powerful method of double-checking all of the chosen methods for accomplishing work and the features of the project deliverable. Frequently, stakeholders find a feature that was in the specifications costs more money to create than they wish to pay. In a project to update an older church, the litur- gical committee proposed many controls for special lighting that would only be used on special occasions. The general contractor suggested simplifying the controls, while retaining all of the new lights, at a savings of $100,000! While the liturgical committee was disap- pointed, the church council readily agreed. Value engineering is so common in some indus- tries that a separate stage is incorporated late in the project planning to ensure that time is spent in this effort to reduce project cost and/or time and to improve project quality and/or usefulness.

EXHIBIT 9.8 NORMAL AND SPECIAL CAUSE VARIATION

Normal Cause Variation

+/−3 Sigma

Special Cause Variation

Special Cause Variation

Average

Chapter 9 Budgeting Projects 255

ACTIVITY-BASED COSTING (ABC) Another issue project managers need to under- stand when estimating costs is what type of accounting system the organization uses. Historically, most companies used functional-based accounting systems. When using these systems, overhead (indirect) costs are assigned to a cost pool, which is allocated to direct costs based most frequently on volume. When direct costs were a large percentage of total costs, this made sense. In more contemporary times, indirect costs form a much larger percentage of total costs, so careful allocation of them is neces- sary both for selecting the projects that truly will contribute the most profit and for ensuring a focus on controlling the highest costs. ABC is another accounting approach, by which indirect costs are allocated to fixed costs based upon four different types of drivers. The cost drivers are number of units produced (frequently, the only method used in functional-based accounting), number of batches run, number of product variations, and amount of facility utilized. ABC requires more involved methods for allocating indirect costs, but yields more accurate cost information. By furnishing more specific information on cost drivers, ABC also helps to support process improvement and justify spending money on expensive equipment. Project managers need to understand how costs are allocated in their organization so they can accurately estimate the amount of indirect costs that will be assigned to their projects.

LIFE CYCLE COSTING Life cycle costing is another concept project managers need to understand when estimating their project costs. Many project selection decisions are made based upon the total costs of both creating the project and of using the result of the project during its useful life. This total cost is called the life cycle cost. Many times, tradeoff decisions are considered that might involve spending more during the project to create a product that costs less to operate during its useful life. In an age when environ- mental concerns are appropriately being considered more heavily, to calculate total life cycle costs, a project manager may also need to consider disposition costs of the product after its useful life is complete. This can entail designing more recyclable parts (even at a higher cost) into the product.

TIME VALUE OF MONEY AND INTERNATIONAL CURRENCY FLUCTUATIONS When considering costs in the future, project managers need to understand how to cal- culate the time value of money. One dollar today is presumably worth more than one dollar next year. Discounting the value of future revenue and cost streams to account for this enables better project decisions. Project managers need to discount future dollars by the appropriate factor. Often, the finance department at a company tells the project manager what rate to use. The rate depends upon the underlying inflation rate plus the cost of capital. On international projects, it can also depend upon international currency fluctuations.

9-3 Determine Budget Once the project costs have been estimated, it is time to establish the project budget. Determine budget is “the process of aggregating the estimated costs of individual activities or work packages to establish an authorized cost baseline.”14 To develop the budget, the project manager starts by aggregating all of the various costs. Once those are totaled, it is time to determine how much money is required for reserve funds. Finally, the project manager must understand cash flow—both in terms of funding and requirements for costs.

256 Part 2 Planning Projects

9-3a Aggregating Costs When the entire project costs, both direct and indirect, have been added up, the result is a cost baseline, which is “the approved version of the time-phased project budget, excluding any management reserves, which can be changed only through formal change control procedures and is used as a basis for comparing actual results.”15

The work packages that are identified when creating a WBS not only take time, but they also cost money. The project budget can be aggregated from the work packages. Exhibit 9.9 shows how six work packages appear on a Gantt chart with the cost of each work package listed on a monthly basis. The total cost for the month is shown and the cumulative cost for the project below that. Finally, a graph appears at the bottom that shows the cumulative cost of the project at each point in time. This represents the time-phased project budget. This will be used as the project progresses for control pur- poses. Note the cumulative cost curve approximates an “S” shape with slow expenditures (and progress) early in the project, rapid in the middle, and slow late in the project. This is common as projects often require much planning early and have a variety of activities to finish at the end.

EXHIBIT 9.9 AGGREGATION OF PROJECT BUDGET

WP 1221 WP 1222 WP 1231 WP 1232 WP 1233 WP 1241

WP 1221 ($10,000) WP 1222 ($10,000) WP 1231 ($45,000) WP 1232 ($20,000) WP 1233 ($15,000) WP 1241 ($20,000)

FEB MAR APR MAY JUN

$10,000

$20,000 $15,000 $10,000 $10,000

$120K $100K $80K $60K $40K $20K

0

$20,000

$35,000

$50,000

$85,000

$25,000

$110,000

$10,000

$120,000

$15,000

$15,000

Cost per month

Cumulative cost

$5,000 $5,000 $30,000$15,000

Source: Kevin P. Grant, University of Texas, San Antonio. Adapted with permission.

Chapter 9 Budgeting Projects 257

9-3b Analyzing Reserve Needs Another view of project cost variation is to consider how well it is understood and how each type is handled. This is displayed in Exhibit 9.10.

Variation in project costs (and schedules) can be partially explained by the presence of certain events. These events are classified as known knowns, known unknowns, or unknown unknowns depending on the extent to which they are understood and predicted. Known knowns are discovered during planning and can be estimated directly. An example could be that when a construction crew takes soil samples, they discover that extra pilings are required to stabilize the new building, and they add the cost into the project estimate to cover that expense.

Known unknowns are events discovered during risk identification that may or may not occur. An example could be snowstorms that cause traffic problems for three days at a critical time, preventing workers from getting to their jobs. In the next chapter on risk, methods for calculating this cost are shown. It will appear as contingency reserves.

Finally, sometimes things that are totally unexpected happen that cause an increase in cost and/or schedule. For example, perhaps a very dependable supplier goes out of busi- ness due to the sudden death of the owner. These unknown unknowns (commonly called unk unks by people who have felt burned by them) also need to be covered in the project budget. The money used to cover them is frequently called management reserve and is usually authorized by company executives.

The amount placed into contingency reserve is calculated during risk analysis. The amount placed into management reserve is determined by how much uncertainty management feels exists in the project. Typical ranges are from 5 percent of project costs for a well-understood, routine project to 30 percent or more of project costs for poorly understood, unusual projects. These costs are not to be used to overcome poor estimating or project execution.

Once the cost baseline is determined and both contingency and management reserves have been added, it is time to determine if sufficient funds are available. On many potential projects, a funding limit exists. The project sponsor for internal projects and the customer for external projects need to be very clear if the necessary funds exceed the limit of what is available. If enough funds are not available, this is the time to look hard at all of the estimates, schedule, and scope to determine what changes need to be made before the project management plan is accepted. It does no good for anyone to deliberately start a project with insufficient funds.

9-3c Determining Cash Flow Projects require cash to keep moving. Suppliers and workers need to be paid in a timely fashion. The difficulty that sometimes occurs is that the project’s customer may not pay for the work until it is completed—often months after project bills need to be paid. Therefore, the timing of cash coming in and going out for a project is just as important as the amount of money required.

EXHIBIT 9.10 ESTIMATING COSTS OF PROJECT VARIATION

HOW VARIATION IS UNDERSTOOD KNOWN KNOWNS KNOWN UNKNOWNS UNKNOWN UNKNOWNS

How It Is Discovered Scope definition Create WBS Risk identification Situation occurs

Stage When It Is Usually Uncovered Initiating or planning Initiating or planning Executing

Method of Estimating Costs Estimate directly Contingency reserves Management reserves

258 Part 2 Planning Projects

Just as the demands on individual workers can be applied to individual activities in the project schedule to determine where overloads may occur, expenses can be applied to individual activities in the schedule to see when cash is needed. Revenue can also be tracked to interim deliverables in the project schedule to show when revenue can be expected. If a project is internal to a company, the timing of cash availability is also important to understand. While workers may work every day and suppliers may deliver frequently, cash may be supplied through organizational budgets only on a periodic basis. A project manager needs to ensure that the cumulative amount of cash coming into the project either from internal budgeting or from customer pay- ments meets or exceeds the demands for paying cash out. This cash flow is shown in Exhibit 9.11 where incoming cash is in large increments, yet outgoing cash is almost continuous. The cumulative revenue at project completion minus the cumulative cost at project completion equals the profit (or surplus) generated by the project.

9-4 Establishing Cost Control The approved project budget with contingency reserves (and any amount of manage- ment reserve that has already been approved) serves as a baseline for project control. The budget shows both how much progress is expected and how much funding is required at each point in time. These are used for establishing project control. Control cost is “the process of monitoring the status of the project to update the project costs and managing changes to the cost baseline.”16 Cost control is discussed in Chapter 14.

When establishing cost control, a typical measuring point is a milestone. Major mile- stones are often identified in the milestone schedule in the project charter, and additional milestones may be identified in constructing the project schedule. Project managers can use the cash flow projections they have made to determine how much funding they expect to need to reach each milestone. This can then be used for determining how well the project is progressing. The sponsor and project manager often jointly determine how many milestones to use. They want enough milestones to keep track of progress, but not so many that they become an administrative burden. Microsoft Project and other software can be used to automate the cost reporting.

EXHIBIT 9.11 PROJECT CUMULATIVE CASH AND REVENUE

Cumulative Cost/Revenue ($)

Time

EndStart

Revenue Cost

Chapter 9 Budgeting Projects 259

9-5 Using MS Project for Project Budgets MS Project supports both bottom-up and summary level cost modeling. Bottom-up cost modeling is primarily based on the cost of each resource assignment. Assignment costs are totaled in the related activity’s Cost field. The resulting activity costs are summarized in the parent WBS levels.

Summary level cost modeling consists of a summary level estimate for all the effort represented by that level, with no underlying detail entered. This can be helpful when the detail is not known, but the schedule must provide an overview of the entire estimated time and cost schedule.

9-5a Develop Bottom-Up Project Budget To develop a bottom-up project budget, a project manager needs to understand four things: assignment costs, activity costs, project total costs, and the different perspectives from which to view costs.

ASSIGNMENT COSTS The following data are used to compute each assignment’s cost value:

• Assignment work hours—calculated when the work assignment is made (Assign- ment units × Resource calendar hours per each day of the activity duration)

• Resource standard rate • Resource overtime rate (only if modeling overtime)

An assignment cost value is the total number of assignment hours times the standard rate. Each resource has a standard cost rate, and some resources may have an overtime cost rate as well. These can be assigned when defining the resource as described in Chapter 8, or assigned later as shown in Exhibit 9.12.

ACTIVITY COSTS The activity cost value is the sum of all assignment cost values plus any activity fixed cost value as shown in Exhibit 9.13, which displays the Task Usage view in the top pane (with the Cost column inserted) and the Resource Work form in the lower pane.

In Exhibit 9.13, row 12 is a summary. Rows 9, 10, 11, and 13 are activities. The unnumbered rows are assignments. Row 9 is the activity “Prepare budgets.” Patrick is scheduled to work 30 hours on that activity. Remembering his cost rate is $30 per hour, it is possible to see how the cost is totaled. The assignment Units and Work values

EXHIBIT 9.12 ASSIGN COST RATES

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

260 Part 2 Planning Projects

for some of the “Select Trip Issues & Sites” activity are shown in the lower pane. To generate the Task Usage view with Resource Work form:

1. On the Task tab, View group, enter Task Usage. 2. On the View tab, Split View group, click Details. 3. On the View tab, Split View group, enter Task Form (if not already displayed). 4. Right click in the form in the lower page and enter “Work.” 5. In the upper pane, expose the Start column and right click in the Start column

header to add a column. Enter “Cost” when prompted.

VARIOUS PERSPECTIVES The preceding discussion has been from the view of the WBS perspective. Cost data may also be viewed from a resource perspective, using the Resource Usage view. In this view, assignment costs are summarized at the resource level.

In Exhibit 9.14, the most indented rows are activities. The “Unassigned” set represents activities with no assigned resources. Resources with no show/hide control have no assignments. The zoom scale is set to month over weeks.

9-5b Develop Summary Project Budget Early in planning, sometimes detail is not yet known for later project phases. However, stakeholders still want an ongoing projection of the completion date and cost. A solution is to add a dummy activity under each phase summary for which not enough informa- tion to plan in detail is known yet. Estimate both the phase duration and the phase cost. Put the duration estimate in the dummy activity’s Duration field. Put the cost estimate in the dummy activity’s Cost field. Remember to remove each dummy activity when detail is added.

On agile projects, it is common to use a dummy activity to summarize the work for future iterations that is not yet defined. Since the number of workers is often known and the length of the iteration is known, the amount of cost can be seen, but the exact work activities are only determined in iteration planning.

EXHIBIT 9.13 TASK USAGE VIEW WITH RESOURCE WORK FORM

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

A G I L E

Chapter 9 Budgeting Projects 261

In Exhibit 9.15, the “Process Improvement” row has a dummy activity, “Assessment & Process changes.” No resources are assigned to it.

EXHIBIT 9.14 RESOURCE USAGE VIEW

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

EXHIBIT 9.15 DUMMY ACTIVITY FOR LATE PHASE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

262 Part 2 Planning Projects

Summary The cost management plan outlines how to structure and control project costs. On a small project, it can be very simple. On a large, complex project, it may need more structure. It guides the project manager during the project.

Cost estimating can be challenging because some activities may have a great deal of variation. Many methods are available to assist in cost estimating. Use a simple method if it will suffice, and more rigor if necessary. Generally as project planning identifies

more specifics, more detailed and accurate cost esti- mates can be made.

Cost budgeting includes aggregating individual costs, analyzing needs for cost reserves where uncer- tainty exists, and determining cash inflow and outflow. Establishing cost controls includes establishing cost reporting systems. MS Project can assist in developing either bottom-up project budgets or summary project budgets.

Key Terms from the PMBOK® Guide plan cost management, 246 cost management plan, 246 estimate cost, 246 estimate, 249 reserve, 249 management reserve, 249 contingency reserve, 249

analogous estimating, 252 parametric estimating, 252 bottom-up estimating, 252 value engineering, 255 determine budget, 256 cost baseline, 257 control cost, 259

Chapter Review Questions 1. What type of costs does not depend on the size of

a project? 2. During which phase of a project do recurring

costs typically occur? 3. What are some examples of expedited

costs? 4. What is the purpose of an order of magnitude

cost estimate? 5. Under which conditions can analogous estimat-

ing be effective? 6. Which method of estimating can produce

the most accurate estimate: parametric or bottom-up?

7. What are some examples of supporting detail pertaining to cost estimates?

8. Is it possible to completely avoid variation in a project? Why or why not?

9. What can be used to determine whether a vendor’s bid is reasonable?

10. What is value engineering? 11. What is the “time value of money,” and why is it

relevant to project management? 12. For a routine project, what is a typical percentage

of total project costs that should be placed into contingency reserves? For an unusual project?

13. What is used to compare actual project spending with planned expenditures to determine if corrective action is needed?

14. What three types of data does Microsoft Project use to compute each assignment’s cost value?

Discussion Questions 1. Explain the importance of creating a cost man-

agement plan. 2. Why is it important for project managers to under-

stand the fixed and variable costs of a project? 3. Describe the difference between direct and indi-

rect project costs. 4. During which phase(s) of a project do nonre-

curring costs typically occur? Give an example of a nonrecurring cost.

5. The project manager at a software company predicts her project’s costs based on previous projects she has worked on that were similar. (She takes into account the differences between her current and previous projects, as well.) What type of cost estimating is she using?

6. Why is it important for assumptions to be listed in the cost estimate?

Chapter 9 Budgeting Projects 263

7. What is the difference between contingency reserves and management reserves? When would each be used?

8. You are the project manager in charge of construc- tion of a new school building. Give one possible example each of a known known, known unknown, and unknown unknown you might encounter.

9. Using the same project described in #8, what are a few examples of milestones at which you might measure cost control?

10. Give an example of how a project manager could run into problems with cash flow, even when he is within budget on the overall project.

Exercises 1. A baker has a contract to bake three dozen

chocolate chip cookies for a customer’s party. Create a bottom-up estimate that includes both items needed for the project and the cost. According to your estimate, how much should the baker charge for the cookies?

2. Using the data for Problem 09.02, create a time- phased budget for the project. Show how much

the daily and cumulative costs for the project are just as the monthly and cumulative costs are shown in Exhibit 9.9.

3. Using the data for Problem 09.03, create a time- phased budget for the project. Show how much the daily and cumulative costs for the project are just as the monthly and cumulative costs are shown in Exhibit 9.9.

PMBOK® Guide Questions 1. The “process that establishes the policies, proce-

dures, and documentation for planning, manag- ing, expending, and controlling project costs” is referred to as: a. determine budget b. estimate costs c. plan cost management d. control costs

2. Activity cost estimates, the basis of estimates and other supporting detail are outputs of which process? a. determine budget b. estimate costs c. plan cost management d. control costs

3. As the project progresses from initiation through planning and executing, and additional detail is gathered, the range of values for the project cost estimate will: a. broaden b. stay the same c. narrow d. be replaced with a single number

4. is “the process of aggregating the estimated costs of individual activities or work packages to establish an authorized time-phased project budget or cost baseline.” a. Determine cash flow b. Determine budget

c. Determine cost estimates d. Determine funding requirements

5. A(n) is used to compare actual project spending with planned expenditures over time to determine if corrective action is needed. a. cost baseline b. funding limit reconciliation c. reserve analysis d. activity resource estimate

6. Jason, a project manager, is working with his team to estimate the total cost of developing a web-based CRM system. After reviewing the planned scope of work with Jason, his sponsor suggests that Jason use the budget from a previ- ous, similar project as the basis for his project budget. The estimating process that Jason’s sponsor is using is called . a. three point estimating b. parametric estimating c. analogous estimating d. single point estimating

7. One of the principle benefits of creating a bottom- up estimate during planning is that the estimate: a. can be created quickly b. is very accurate c. matches the high level estimate in the project

charter d. will not change once the project is in flight

264 Part 2 Planning Projects

8. The amount of project budget reserved for un- foreseen project work that addresses the “un- known unknowns” that can affect a project is the . a. project buffer b. funding limit c. contingency reserve d. management reserve

9. Ellen is estimating how much it will cost to re-carpet the executive conference room. After selecting the grade and pattern of carpet, Ellen multiplies the carpet price per square yard times the number of square yards in the conference

room to derive the total price of the material. This estimating method is called . a. expert judgment b. analogous estimating c. parametric estimating d. three-point estimating

10. The budget within the cost baseline that is allo- cated for identified risks, for which mitigating responses are developed, is called the . a. contingency reserve b. management reserve c. control account d. activity cost estimate

Example Project Create a time-phased budget for your example project using bottom-up estimating. To the extent your sponsor supplies rates for workers, use those. Approximate rates for ones you cannot get. Ask your sponsor how they treat indirect costs. Be sure to include direct labor costs for your- self and your teammates. Budget your costs at the starting salary you expect to receive when you graduate (or your current salary if you are employed). Divide your annual

salary by 2,080 hours and add 20 percent for fringe. State all assumptions and constraints you have used when creating your budget. State how confident you are in your estimates and what would make you more confident. Give examples of known knowns and known unknowns on your project. Tell how you have budgeted for both of them as well as how you have budgeted for unknown unknowns.

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Good, Gordon K., “Project Development and Cost Estimating: A Business Perspective,” AACE International Transactions (2009) TCM.01.01– TCM 01.14.

Goodpasture, John C., Project Management the Agile Way: Making It Work in the Enterprise (Fort Lauderdale, FL: J. Ross Publishing, 2010).

Hansen, Don R., and Maryanne M. Mowen, Manage- rial Accounting, 9th ed. (Mason, OH: Cengage South-Western, 2010).

Kim, Byung-Cheol, and Kenneth F. Reinschmidt, “Combination of Project Cost Forecasts in Earned Value Management,” Journal of Construction Engi- neering and Management 137 (11) (November 1, 2011): 958–966.

Kim, Yong-Woo, et al. “A Case Study of Activity-Based Costing in Allocating Rebar Fabrication Costs to Projects,” Construction Management and Economics 29 (May 2011): 449–461.

Kinsella, Steven M., “Activity-Based Costing: Does It Warrant Inclusion in A Guide to the Project Man- agement Body of Knowledge (PMBOK® Guide)?” Project Management Journal 33 (2) (June 2002): 49–56.

Kwak, Young Hoon, and Rudy J. Watson, “Conceptual Estimating Tool for Technology Driven Projects: Exploring Parametric Estimating Techniques,” Technovation 25 (12) (2005): 1430–1436.

Li, Huimin, et al. “Factors That Affect Transaction Costs in Construction Projects,” Journal of Con- struction Engineering and Management 139 (1) (January 1, 2013): 60–67.

Milosevic, Dragan Z., Project Management Toolbox: Tools and Techniques for the Practicing Project Manager (New York: John Wiley & Sons, 2003).

Needy, Kim LaScola, and Kimberly Sarnowski, “Keep- ing the Lid on Project Costs,” in David I. Cleland, ed., Field Guide to Project Management, 2nd ed. (Hoboken, NJ: John Wiley & Sons, 2004).

Rad, Parviz F., Project Estimating and Cost Management (Vienna, VA: Management Concepts, Inc., 2002).

Chapter 9 Budgeting Projects 265

Rad, Parviz F., and Vittal S. Anantatmula, Project Planning Techniques (Vienna, VA: Management Concepts, Inc., 2005).

Tichacek, Robert L., “Effective Cost Management: Back to Basics,” Cost Engineering 48 (3) (March 2006): 27–33.

Todd, Greg, “Five Considerations to Improve Project Estimates,” Information Management (November/ December 2009): 45–47.

Uppal, Kul B., “Cost Estimating, Project Performance and Life Cycle,” AACE International Transactions (2009): TCM.03.01–TCM.03.09.

Endnotes 1. PMBOK® Guide 550. 2. PMBOK® Guide 534. 3. Adapted from Kim LaScola Needy and Kimberly

Sarnowski, “Keeping the Lid on Project Costs,” in David I. Cleland, ed., Field Guide to Project Man- agement, 2nd ed. (Hoboken, NJ: John Wiley & Sons, 2004): 150.

4. PMBOK® Guide 539. 5. Ibid. 6. PMBOK® Guide 558. 7. PMBOK® Guide 545.

8. PMBOK® Guide 533. 9. Greg Todd, “Five Considerations to Improve

Project Estimates,” Information Management (November/December 2009): 47.

10. PMBOK® Guide 528. 11. PMBOK® Guide 548. 12. PMBOK® Guide 530. 13. PMBOK® Guide 566. 14. PMBOK® Guide 537. 15. PMBOK® Guide 534. 16. Ibid.

PROJECT MANAGEMENT I N ACT I ON

The Value of Budget Optimization

At a major midwestern electric utility, budgeting for the ongoing capital expansion of the electric power system represents a process at the core of the organization’s strategy and operations. During extensive annual planning efforts, a three-year capital project portfolio is developed for implementation and budgeted. The budgeting process is used to ensure that available capital is carefully scrutinized by management and applied judiciously to those projects providing the greatest strategic value on a schedule minimizing overall risk. Maintaining the forecasted budget and completing projects as planned ensures the integrity of the electrical system and the financial strength of the business.

The budgeting process itself is actually conducted year-round as planners, engineers, project managers, and financial experts endeavor to balance multiple competing objectives into a rational, achievable, and ongoing capital spending plan. There is little margin for error. Annual spending for major capital projects is typically over $250 million, representing approximately 500 projects to be completed across a five-state area. Underbudgeting means that projects potentially critical

to the reliability of the electrical network may not be completed. Overbudgeting could result in investment dollars not yielding a return and reducing earnings.

As with any enterprise, the electric utility capital budget is restricted by annual spending targets necessary to maintain prudent financial ratios. In the case of capital spending, one key element involves maintaining a targeted debt-to-equity ratio. For this reason, judgments need to be made about the cost versus the value of projects considered for investment and the risks associated with potentially postponing projects to maintain favorable financial ratios.

To enable this entire process to work continuously and effectively, the utility adopted a project portfolio optimization process to create, analyze, and refine the budget for the project portfolio. This process involves executive management in creating a strategic value and risk scoring methodology that is applied during the planning phase for each project. The method assigns a value and risk score based on each individual project’s forecasted impact in five critical strategic areas: financial, reliability, customer, regulatory, and system operations. A computer-based mathematical algorithm

266 Part 2 Planning Projects

is used to optimize all possible spending portfolios to maximize value and minimize risk at specified budget levels. Within hours, the utility can analyze multiple optimized budget scenarios at various annual spending levels involving thousands of projects and nearly $1 billion of investment.

This methodology has several key benefits for the electric utility that can be applied to any organization attempting to make budgeting decisions for complex project portfolios.

• Budget strategy well understood and communi- cated through the organization—The process starts with an annual review by executive management of the strategy categories to which value and risk assessments will be applied. These categories and relative importance weightings can be adjusted to match the organization’s current strategic emphasis. These categories and their relative weightings are published, communicated, and used throughout the organization.

• Budget optimized for strategic objectives—The scores of value and risk for each project are applied to the strategy categories and optimized to provide maximum value and minimum risk for the capital spending available. Computer software allows instant scenario changes and what-if options to be analyzed. The outcome provides management with consistent and well-understood decision-making information.

• Consistent organizational strategy ensured— Projects are submitted for budget consideration in the capital portfolio from throughout the utility’s five-state operating area. There is a diverse array of business and financial reasons for each project to be evaluated. The use of a single enterprise-

wide tool allows all projects to be analyzed on an equal basis, providing assurance that the organiza- tional strategy is universally applied.

• Risk thresholds and tolerance understood— Postponing projects to conserve capital brings with it certain risks. The budget optimization process pro- vides detailed risk analysis information on all deferred projects. Widespread communication of these risks and expert analysis of the consequences and probabil- ity allow management to make calculated and care- fully considered decisions. Importantly, management gains recognition of its own risk tolerance and risk threshold levels as a result.

• Planning horizon and purchasing power expanded— The most significant result of the budget optimiza- tion process is the certainty with which implementa- tion (the project execution phase) of the budget plan can be approached. The high levels of up-front man- agement scrutiny leave little doubt about executive support for the plan going forward. This enables the planning horizon to be significantly expanded into future years and brings with it an enormous level of labor and material purchasing power in the market.

• Project dynamics accounted for—Although the three- year budget plan is updated annually, there are still ele- ments of uncertainty associated with implementation of a large project portfolio. These changes might be items such as significant shifts in public policy or reg- ulations, fundamental changes to the business model, unexpected weather events, and so on. These mid- stream shifts can be dealt with readily, if needed, by changing project scoring criteria, reoptimizing the proj- ect mix, and reevaluating the resulting information for options going forward.

Source: Paul R. Kling, PE, PMP, director of project management and controls, Duke Energy.

Chapter 9 Budgeting Projects 267

CHA P T E R 10 Project Risk Planning

The Texas Medical Center (TMC) is composed of 49 not-for-profit institutions that are dedicated to the highest standards of patient care, research, and education. These institutions include thirteen renowned hospitals and two specialty institutions, two medical schools, four nursing schools, and schools of dentistry, public health, pharmacy, and virtually all health-related careers. People come from all walks of life and from all over the world to have access to the best healthcare anywhere. Member institutions specialize in every imaginable aspect of healthcare, including care for children and cancer patients, heart care, organ transplantation, terminal illness, mental health, and wellness and prevention.

Currently 11 major construction projects are underway, including the Texas Children’s Hospital’s 407,000-square-foot Neurological Research Institute and 720,000-square-foot Maternity Center, along with a 12-story, 27,000-square-foot concrete-frame addition to the M. D. Anderson Cancer Center of the University of Texas Medical Center. Collectively these major

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Describe how to plan for risk management, identify risks, analyze risks, and create response plans for identified risks.

• Identify and classify risks for a project and populate a risk register.

• Describe various risk assessment techniques and tell when each is appropriate to use.

• Prioritize each risk on a project using an appropriate assessment technique and develop and defend at least one strategy for each of the high- priority risks.

• Compare and contrast the various strategies for dealing with risks.

© Lo ga n M oc k- Bu nt in g/ Ge tty

Im ag es

268

Topics:

• Plan risk management

• Identify risks

• Perform qualitative risk analysis

• Perform quantitative risk analysis

• Plan risk responses

projects will add facilities that will be staffed by up to 27,000 additional employees. When complete, TMC will have 40 million square feet of occupied space. If you consider downtown business space, by itself it forms the seventh largest downtown business district in the United States.

With hurricane season approaching, TMC held a conference for over 100 contractors to review how to prepare for a potential hurricane. Contractors must have a plan in place detailing how they are going to secure their construction sites and keep materials from becoming airborne missiles in the event of a hurricane. Conference attendees were given a handout describing TMC’s hurricane guidelines. These guidelines call for storm preparations to be completed twenty-four hours before tropical storm winds are predicted to hit land. Examples of storm preparations include dismantling scaffolds and privacy screens, securing giant cranes, emptying and weighting down dumpsters, photographing all buildings and assets, and unblocking all streets for emergency access.

While project managers cannot prevent hurricanes, through careful risk planning, actions can be taken to greatly mitigate the impact.

Rhonda Wendler, Texas Medical Center News

Imagine you are asked to plan for risks on two different projects. One is a major con- struction project at TMC with hurricane season approaching. The other is planning a small fund-raising event for charity. Would you handle the risks on these two projects the same way? Would you invest the same level of time and energy into planning these two projects? The answers are yes and no. Yes, you would approach the risks in the same way. But you would not spend the same amount of time planning for risk on both projects. You would spend considerably more time and money on risk management planning for the major construction project that is vulnerable to a hurricane than for the small fund-raiser project. Just as in other types of project planning, there is an approach to planning for risks that all projects follow; however, the depth of planning depends greatly on the potential risks of the project. In other words, a smart project manager gladly spends $100 in risk planning to save $1,000 in expected consequences, but does not gladly spend $1,000 to save $100.

The purpose of risk management is to reduce the overall project risk to a level that is acceptable to the project sponsor and other stakeholders. The methods that project

269

PMBOK® Guide

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative Closure

Planning Executing Closing RealizingInitiating

RealizedResultTo Proceed

managers use in risk management start with identifying as many risks as possible. Once the risks are identified, each risk is analyzed so that the project team can concentrate their atten- tion on the most critical risks. Analysis always consists of a qualitative or judgmental approach and sometimes also includes a quantitative approach. In the final risk manage- ment process, the project team decides how to respond to each potential risk. Once all of the risk management planning has initially been accomplished, the response plans are incorporated into the overall project management plan. Changes may need to be made to the schedule, budget, scope, or communication plans to account for certain risks. These risk management planning processes are covered in this chapter. Risk management also includes monitoring and controlling the risks according to plan. These are covered, along with ongoing risk planning, in Chapter 14, Determining Project Progress and Results.

On agile projects, while early risk planning, assessment, and response planning is similar at a high level, more detailed and timely risk management occurs in three places: in planning each subsequent iteration, in daily stand-up meetings, and in retrospectives at the end of each iteration.

10-1 Plan Risk Management Plan risk management is “the process of defining how to conduct risk management activities for a project.”1 To plan for project risks, a project manager must first under- stand the project’s objectives. A project manager develops this understanding initially by realizing what project success in general is and then by understanding the specific priorities of the most important project stakeholders, as discussed in Chapter 5. Exhibit 10.1 summarizes current project success research results.

The first set of general project success measures is meeting agreements. This includes meeting the technical requirements while not going over the cost and schedule agreements. The second set of project success measures focuses on the project’s customers. Specifically, did the project result meet the customers’ needs, was the project result used by the custo- mers, and did it enhance the customers’ satisfaction? The third set deals with the future of the performing organization. The specific measures in this area vary, but essentially they ask whether the project helped the performing organization. The performing organization is “an enterprise whose personnel are most directly involved in doing the work of the project.”2 Typical measures here include market share, new markets and/or technologies, and commercial success of the project output. The final set of project success measures deals with the project team. Did they become better and more dedicated employees?

A G I L E

EXHIBIT 10.1 PROJECT SUCCESS MEASURES

• Meeting Agreements Cost, schedule, and specifications met

• Customer’s Success Needs met, deliverables used, customer satisfied

• Performing Organization’s Success Market share, new products, new technology

• Project Team’s Success Loyalty, development, satisfaction

Source: Timothy J. Kloppenborg, Debbie Tesch, and Broderick King, “21st Century Project Success Measures: Evolution, Interpretation, and Direction,” Proceedings, Project Management Institute Research and Education Conference, July 2012, Limerick, Ireland.

270 Part 2 Planning Projects

The specific priorities of the project’s most important stakeholders can be summa- rized in a table such as Exhibit 10.2. A project manager and team need to understand not only what the project plans call for but also what area(s) the most important stakeholders would like to improve and what area(s) they are willing to sacrifice to enable those improvements. For example, consider a project that calls for building a four-bedroom house of 2,800 square feet. Perhaps the homeowner (the most important stakeholder) insists on keeping the size at 2,800 square feet and insists on the normal quality (no leaks, square walls, etc.), but would like to improve on the cost (pay less money). To improve on the cost objective, one of the other objectives probably needs to be sacrificed. Perhaps the homeowner would be willing to move in a month late if the savings were $5,000.

Once the project team understands the project success measures and priorities, atten- tion is turned to understanding the project risks. All projects have some risk, and the more unique a project is, the more risk may be present. It is impossible to remove all sources of risk. It is undesirable to even try to remove all risk because that means the organization is not trying anything new. A risk is anything that may impact the project team’s ability to achieve the general project success measures and the specific project stakeholder priorities. This impact can be something that poses a threat or “a risk that would have a negative effect on one or more project objectives.”3 The impact, on the other hand, could be something that poses an opportunity or “a risk that would have a positive effect on one or more project objectives.”4

Wise project managers strive to develop a risk management plan, which is “a component of the project management plan that describes how risk management activities will be structured and performed,”5 and have it in place before risk events occur. By documenting risk information in a proactive manner, a project manager can eliminate or reduce the impact of some threats and capitalize on some opportu- nities. The risk management plan is also useful for communicating with the various project stakeholders and for later analysis to determine what worked well and may be good practice to use on future projects, and what went poorly and should be avoided on future projects.

Some risk management plans include all of the topics in this chapter. Others are smaller. For example, a risk management plan template for an IT consulting company is shown in Exhibit 10.3.

EXHIBIT 10.2 SPECIFIC PROJECT STAKEHOLDER PRIORITIES

IMPROVE KEEP

Scope X

Quality X

Time ≤1 month to save $5,000

Cost Want to save

Contribution to Organization

X

Contribution to Society X

Source: Adapted from Timothy J. Kloppenborg and Joseph A. Petrick, Managing Project Quality (Vienna, VA: Management Concepts, Inc., 2002), 46.

Chapter 10 Project Risk Planning 271

10-1a Roles and Responsibilities It is good practice to encourage wide participation in risk management activities. One reason is that everyone has a different perspective. The more perspectives that are con- sidered, the more likely important risks will be uncovered early. Another good reason is that people often resist when they are told what to do, but work with great enthusiasm if they participated in the planning. The surest way to get the various project stakeholders to buy into a risk management approach is to involve them right from the beginning in risk management planning. Potential critics can be turned into allies if their concerns are included.

The risk management plan should define who has responsibility for each risk man- agement activity. On small projects, this is often the project manager or a core team member for most activities. On larger projects, the plan can be more elaborate, with sub- ject matter experts involved at many points.

10-1b Categories and Definitions Most projects have many types of possible risks. Therefore, it is helpful to look at risks in a systematic manner so as to consider as many types of risks as possible. One way to look at risk is by considering when it occurs in the project life cycle. For example:

• Certain types of risks, such as a customer not agreeing on the price, may occur during project initiation.

• Others, such as not finding a capable supplier, may occur during project planning. • Risks such as delivery difficulties from a supplier may occur during project

execution. • Risks such as the project deliverable not actually working properly may even appear

near the project conclusion.

The number and costs of project risks over a project life cycle are graphed in Exhibit 10.4. More project risks are typically uncovered early in the life of a project. However, the cost per risk discovered early is often less since there is time to make changes in plans. Risks discovered late in a project can be very expensive. Experienced project managers work hard to uncover risks as early in the project as feasible. Usually, some risks are uncovered during project chartering. On small, simple projects this may be the biggest risk identification push, but on other projects, a great deal of time and effort may also be expended during project planning.

In addition to being categorized by when they might occur in a project, risks can also be categorized by what project objective they may impact, such as cost, schedule, scope, and/or quality. Risks can also be classified as external to the performing organization and

EXHIBIT 10.3 RISK MANAGEMENT PLAN GUIDANCE FOR AN IT CONSULTING COMPANY

Risk management includes guidance on how to perform three risk management activities:

1. Decide what level of risk premium to charge for the project. The team must rate factors such as project size, complexity, technology, and type. The combined ratings dictate that a risk premium of 0, 10, or 20 percent be added to the estimated project cost or, for very risky projects, that executive approval is mandated.

2. Mitigate risk external to the firm through contract clauses and risk internal to the firm through agreements. 3. Manage the risk very carefully through specifically designed weekly conference call meetings and reports.

Source: Rachana Thariani, PMP®.

272 Part 2 Planning Projects

internal to it; or by operational and strategic. Many organizations have developed lists of risks for certain types of projects they routinely perform. Additionally, many writers have created general lists of risk factors for certain types of projects. For example, Exhibit 10.5 shows the biggest fourteen risks on the Panama Canal expansion (which might be simi- lar on other major construction projects), Exhibit 10.6 shows major risk categories for international projects generally, and Exhibit 10.7 shows common risks for informa- tion systems projects. Any of these categorizations can be shown as a risk breakdown structure—“a hierarchical representation of risks according to their categories.”6

EXHIBIT 10.4 RISKS OVER THE PROJECT LIFE CYCLE

Project Life Cycle Stage

Initiating Planning Executing Closing

Number of Risks Discovered Cost per Risk Discovered

EXHIBIT 10.5 FOURTEEN MOST IMPORTANT RISKS IN PANAMA CANAL EXPANSION

Changes in design and quantities Extreme bad weather

General inflation Inadequate claims administration

Ineffective contracting process Inefficient planning

Insufficient revenues Lack of controls

Lack of skilled and local labor Local labor strikes

Material, equipment, and labor cost Organizational risks

Owner-driven changes Referendum delays

Source: Luis F. Alarcon, et al., “Risk Planning and Management for the Panama Canal Expansion Program,” Journal of Construc- tion Engineering and Management (October 2011): 762–770.

Chapter 10 Project Risk Planning 273

Yet another method of classifying project risk is by what is known about each. Something that is a “known known” can be planned and managed with certainty. Therefore, it is not a risk. An example is that cement will harden. The next level is “known unknowns,”which are risks that can be identified andmay ormay not happen. These risks should be identified, and a contingency reserve needs to be established to pay for them. An example on a long construction project is that bad weather will probably happen at some points, but no one

EXHIBIT 10.7 TOP RISKS IN EACH FACTOR FOR SOFTWARE PROJECTS

EXECUTION MANAGEMENT USER COORDINATION

Configuration management system User evaluation of progress

Formality of status reports User understanding of complexity

Specification approval process Care in user manual preparation

Post-project audits Coordination with user

Regularity of technical reviews Informal communication channels

HUMAN RESOURCE MANAGEMENT PROJECT PLANNING

Flexibility of working hours Frequency of software reuse

Individual performance incentives Planning tools used

Technical assistance availability Minimum cost software design

Recognition for extra work Removal of unnecessary requirements

Enforced attendance system Individual accountability

Source: Sam Thomas and M. Bhasi, “A Structural Model for Software Project Risk Management,” Journal of Management (March 2011): 71–84.

EXHIBIT 10.6 TOP RISKS IN EACH FACTOR FOR INTERNATONAL PROJECTS

CULTURAL VIRTUAL

Number of languages Communication issues

Trust level Number of countries

Economic culture Management experience

Number of religions Number of time zones

POLITICAL REGIONAL

Government desire for project Crime rate

Government unrest Climate/weather

Laws and regulations Housing availability

Relationship with government Safety issues and procedures

Source: Robert W. Steffey and Vittal S. Anantatmula, “International Projects Proposal analysis: Risk Assessment Using Radial Maps,” Project Management Journal (April 2011): 62–70.

274 Part 2 Planning Projects

knows exactly when or how bad it will be. The final level is for the true uncertainties. These are called “unknown unknowns” (or “unk unks” by people who must deal with them). Since they cannot even be envisioned, it is hard to know how much reserve time and money is needed to cover them. They are usually covered by amanagement reserve, and the amount of this reserve is often negotiated based upon the confidence level the project manager and key stakeholders have regarding how well they understand the project. An example could be a 100-year flood that covers a construction site that everyone thought was on high enough ground to stay dry—an event so rare it is expected to happen only once a century.

10-2 Identify Risks Once the risk management planning is in place, it is time to begin identifying specific risks. Identify risks is “the process of determining which risks might affect the project and documenting their characteristics.”7 Project managers are ultimately responsible for identifying all risks, but often they rely upon subject matter experts to take a lead in identifying certain technical risks.

10-2a Information Gathering A large part of the risk identification process is gathering information. The categories shown in Exhibits 10.5, 10.6, and 10.7 and/or project stages can be a good starting point in this information gathering. The project manager either needs to act as a facilitator or get another person to serve as facilitator for information gathering. This is essentially a brainstorming activity, during which time the question “what could go wrong?” is repeatedly asked of everyone who is present. It is helpful to use Post-it Notes and write one risk per note to prepare for further processing the risks during risk analysis.

Classic rules for brainstorming are used. For example, every idea is treated as a useful idea. The risks will be assessed next. If one suggested risk does not prove to be impor- tant, it does not hurt to keep it on the list. Also, sometimes a risk that is obviously not important—or is even humorous—may cause another person to think of an additional risk they would not have considered otherwise.

While it is helpful to have as many stakeholders together as possible to “piggy-back” on each other’s ideas, with the information technology available today, much of the same inter- action can be achieved by global and virtual teams. It just takes a bit more careful planning. Variations and extensions of possible risks can help a team to identify additional risks.

Several other techniques are also used in risk identification. Sometimes, team members interview stakeholders. Other times SWOT analysis is “analysis of strengths, weaknesses, opportunities, and threats to a project”8 might be used. Remember, risks can be both threats to overcome and opportunities to exploit. Yet another method of identifying risks is the Delphi technique, which is “an information gathering technique used as a way to reach a consensus of experts on a subject.…Responses are summarized and recirculated for further comment.”9 Finally, a team can use a structured review to identify risks.

10-2b Reviews A project manager and team can review a variety of project documents to uncover possible risks. Exhibit 10.8 lists some of the documents a project manager may use and typical ques- tions he or she would ask for each. Project teams can often identify risks from each type of review shown. Balance must be given to the extent of the reviews and the amount of useful information regarding risks expected to result. As with the brainstorming mentioned previ- ously, it is better to identify many possible risks and later determine that some of them are not major, rather than to not identify what does turn out to be a big risk.

Chapter 10 Project Risk Planning 275

10-2c Understanding Relationships Project managers can also seek to identify risks by learning the cause-and-effect relation- ships of risk events. One useful technique is a flow chart that shows how people, money, data, or materials flow from one person or location to another. This is essentially what the team does when it reviews the project schedule, provided it looks at the arrows that show which activities must precede others.

A second method of understanding risk relationships is to ask why a certain risk event may happen. This can be accomplished through root cause analysis, which is “an analytical technique used to determine the basic underlying reason that causes a variance or defect or risk. A root cause may underlie more than one variance or defect or risk.”10

A simple approach to root cause analysis is to simply consider each risk one at a time and ask, “Why might this happen?” At this point, since many potential risks have prob- ably been identified, project teams do not spend a large amount of time on any single risk. If necessary, the project team can perform more detailed root cause analysis of the few risks that have been designated as major risks during risk analysis.

One more type of relationship project managers like to understand is trigger condi- tions, or “an event or situation that indicates a risk is about to occur.”11 A trigger can be specific to an individual risk, such as when a key supplier stops returning phone calls, which may jeopardize their delivery of materials.

10-2d Risk Register The primary output of risk identification is the risk register. When complete, the risk register is “a document in which the results of risk analysis and risk response planning are recorded.”12 At this point (the end of risk identification), the risk register includes only the risk categories, identified risks, potential causes, and potential responses. The other items are developed during the remainder of risk planning. An example of a partial risk register is shown in Exhibit 10.9.

The risk register is a living document. As a risk is identified, it is added. More infor- mation regarding a risk can be added as it is discovered. As risks are handled, they can

EXHIBIT 10.8 PROJECT RISK REVIEWS

TYPE OF REVIEW QUESTION

Charter

Stakeholder register

Communication plan

Assumptions

Constraints

WBS

Schedule

Resource demands

Touchpoints

Literature

Previous projects

Peers

Senior management

Is there clarity and common understanding in each section?

What could upset any of them?

Where could poor communications cause trouble?

Can you verify that each assumption is correct?

How does each constraint make the project more difficult?

What risks can you find going through the WBS item by item?

What milestones and other merge points might be troublesome?

At what points are certain people overloaded?

What difficulties may arise when some project work is handed off from one person to another?

What problems and opportunities have been published concerning similar projects?

What projects and opportunities have similar projects in your own organization experienced?

Can your peers identify any additional risks?

Can senior management identify any additional risks?

276 Part 2 Planning Projects

be removed because they are no longer of the same level of concern. On smaller projects, a spreadsheet works fine for a risk register. On larger, more complex projects, some organizations use databases.

10-3 Risk Analysis If a project team is serious about risk identification, they will uncover quite a few risks. Next, the team needs to decide which risks are major and need to be managed carefully, as opposed to those minor risks that can be handled more casually. The project team should determine how well they understand each risk and whether they have the neces- sary reliable data. Ultimately, they must be able to report the major risks to decision makers.

10-3a Perform Qualitative Risk Analysis Perform qualitative risk analysis is “the process of prioritizing risks for further analysis or action by assessing and combining their probability and impact.”13 All project teams should perform this task. If they understand enough about the risks at this point, they proceed directly to risk response planning for the major risks. If not, they use more quantitative techniques to help them understand the risks better.

DIFFERENTIATING BETWEEN MAJOR AND MINOR RISKS The primary questions project teams use in qualitative risk analysis are “how likely is this risk to happen?” and “if it does happen, how big will the impact be?” This was shown in Exhibit 4.8 (see page 96). A somewhat more involved example is shown in Exhibit 10.9. Note that for each dimension—probability and impact—in Exhibit 10.10 a scale of 1 to 5 is used with

descriptions. The scale does not matter as long as it is applied consistently and is easy for everyone to understand. Note also the dark line. This line separates the major and catastrophic risks that need either further analysis and/or specific contin- gency plans from minor and moderate risks that can just be listed and informally monitored. Without making a distinction like this, project teams may be tempted to either ignore all risks or to make contingency plans for all risks. Ignoring all risks al- most guarantees the project has problems. Making contingency plans for even minor risks is a terrible waste of time and draws focus away from the really big risks.

Project teams sometimes also ask, for each risk, when is it likely to occur in the project. This can be useful because those risks that are likely to occur earlier often need to be assigned a higher priority. Teams also sometimes ask how easy it is to notice and correctly interpret the trigger condition. Risks with triggers that are difficult to notice or interpret often are assigned a higher priority.

CAUSE-AND-EFFECT RELATIONSHIPS One additional type of qualitative risk analysis is to determine cause- and-effect relationships. This is part of root cause analysis, which was described in the previous section on understanding relationships. While effects are often more visible, it is often easier to change the effect by changing the underlying cause. For example, assume that a construction worker is not laying

Teams should assess potential risks and predict possible outcomes involved in a project.

© An dr ea s G.

Ka re lia s/ Sh ut te rs to ck .c om

Chapter 10 Project Risk Planning 277

E X H IB

IT 1 0 .9

P A R T IA

L R IS

K R E G IS

T E R

R IS

K D E S C R IP

T IO

N (E

V E N T )

IM P A C T

C A T E G O R Y

P R O B

IM P A C T

S C O R E

M IT

IG A T IO

N S T R A T E G Y -

R E S O L U T IO

N

In co m pl et e re qu

ir em

en ts

w er e id en ti fe d

in th e R FP

an d E xh ib it s

(s ee

R is k 7) .

G re at er

po ss ib ili ty

of ga ps

in fu nc tio

na lit y.

G re at er

po ss ib ili ty of

m is si ng

St at e sp ec fic

fu nc ti on

al it y.

G re at er

po ss ib ili ty

of “S co pe

C re ep ”.

G re at er

po ss ib ili ty

of de la y in

fin al iz in g

re qu

ir em

en ts .

G re at er

po ss ib ili ty

of re w or k in

su bs e-

qu en t ph

as es .

B us in es s

R eq ui re m en ts

5 4

20 M A X IM

U S w ill

be gi n co nd

uc ti ng

th e de ta ile d B A

se ss io ns

09 /2 0/ 20 12 . A dd

it io na l re qu

ir e-

m en ts w ill

be ga th er ed

in th os e

se ss io ns

an d do

cu m en te d in

su b-

se qu

en t ve rs io ns

of th e R eq ui re -

m en ts V al id at io n D oc um

en ta ti on

.

A sc he du

le of fu tu re B us in es sA

rc hi -

te ct ur ea nd

T ec hn

ic al se ss io ns is be in g

de ve lo pe d.

St at e w ill

pr ov id e cl os ur e an d de -

ci si on

s re ga rd in g re qu

ir em

en ts an d

sy st em

sc op

e.

Si nc e th er e ar e va ri ou

s ve nd

or pr od

uc ts

(I B M /C ur am

,C on

ne ct ur e)

ea ch

w it h it s

ow n ru le s en gi ne s, it is no

t cl ea r w hi ch

ru le s en gi ne

ta ke s pr ec ed en ce .

P ot en ti al

du pl ic at io n of

ru le s or

co nf lic t-

in g ru le s th at

le ad

to di ff er en t ou

tc om

es .

T ec hn

ol og y

3 4

12 E ng ag eP oi nt

w ill

pr ov id e an d

ex pl an at io n of

ho w to

m it ig at e th is

ri sk .

(S ee

R is k R es po

ns e P la n fo r

re so lu ti on

.)

D iff ic ul ty

in te gr at in g to

St at es

en d-

to -e nd

In fr as tr uc tu re .

P ot en ti al

di ff ic ul ty

in te gr at in g ne w

te ch -

no lo gy

in to

ex is ti ng

in fr as tr uc tu re .

T ec hn

ol og y

4 4

16 W or k w ith

th e St at e to

de fin

e in fr as tr uc tu re

re qu

ir em

en ts an d

en su re

w e ar e pr ov id in g an y ne ce s-

sa ry

in fo rm

at io n to th e M N -I T st af f.

G oi ng

th ro ug h hi er ar ch ic al

re po

rt in g

st ru ct ur e w ill

im pa ct

re al

ti m e de ci si on

m ak in g.

Po te nt ia lb

ot tle ne ck s in

do cu m en t re vi ew

s an d de ci si on

m ak in g m ay

af fe ct ta sk

co m -

pl et io n ac co rd in g to

th e Pr oj ec t Sc he du

le .

C om

m un

ic at io ns

4 4

16 Id en ti fy in g a P oi nt -o f- C on

ta ct

fo r

ea ch

fu nc ti on

al ar ea

fr om

ve nd

or an d st at e to

el im

in at e bo tt le ne ck s.

St at e fu nc ti on

al P O C ’s m ay

ha ve

co m -

pe ti ng

pr io ri ti es

th at

w ill

hi nd

er th ei r

ab ili ty

to re sp on

se in

a ti m el y m an ne r.

Se co nd

ar y ri sk — re la te d to

R is k 6.

C om

m un

ic at io ns

4 4

16 Id en ti fy in g m ul ti pl e P oi nt s-

of -C

on ta ct fo r ea ch

fu nc ti on

al ar ea

fr om

ve nd

or an d st at e to

el im

in at e

bo tt le ne ck s.

D el ay s in

pr oc ur em

en t pr oc es s m ay

ne ga ti ve ly

im pa ct

pr oj ec t sc he du

le .

In ab ili ty

to ac qu

ir e re so ur ce s in

a ti m el y

m an ne r m ay

ne ga ti ve ly

im pa ct

re la te d

ac ti vi ti es

in th e P ro je ct

Sc he du

le .

P ro cu re m en t

2 5

10 A dd

le ad

ti m e as

ea rl y as

po ss ib le .

E va lu at e pr oc ur em

en t re qu

ir e-

m en ts du

ri ng

th e ch an ge

or de r

pr oc es s. M ak e su re

C om

m er ce

pr oc ur em

en t st af f ar e en ga ge d in

th e P O

de ve lo pm

en t pr oc es s.

So ur ce :h

tt p: // m n. go v/ hi x/ im

ag es /B C 9- 1- IT A tt ac hm

en tN

.p df ,a cc es se d A pr il 26 ,2 01 3.

278 Part 2 Planning Projects

stones evenly for a patio (the effect); perhaps the easiest way to ensure that future stones are placed evenly is to understand why the worker is having problems. The cause may turn out to be inconsistent stone size, incorrectly prepared ground, the cement for hold- ing the stones having bigger gravel than normal, or an improperly functioning level. Once the causes are understood, they can serve as trigger conditions to identify that a risk event may be about to happen. This knowledge is useful when developing responses to risks.

CAUSE-AND-EFFECT DIAGRAM A tool that is useful in this analysis is the cause- and-effect diagram. Many project teams use this diagram to identify possible causes for a risk event. An example is shown in Exhibit 10.11.

The cause-and-effect diagram is also known as the fishbone diagram because the many lines make it look like the skeleton of a dead fish. To construct the cause-and-effect diagram, the project team first lists the risk as the effect in a box at the head of the fish. In this example, it is late delivery. The more specifically the risk is stated, the more likely the team can uncover its

EXHIBIT 10.10 QUALITATIVE RISK ASSESSMENT

PROBABILITY IMPACT

INSIGNIFICANT (1) MINOR (2) MODERATE (3) MAJOR (4) CATASTROPHIC (5)

Almost certain (>90% chance)

high high extreme extreme extreme

Likely (50–90%) moderate high high extreme extreme

Moderate (10–50%) low moderate high extreme extreme

Unlikley (3–10%) low low moderate high extreme

Rare (<3%) low low moderate high high

EXHIBIT 10.11 CAUSE-AND-EFFECT DIAGRAM

Late Delivery

People Machines

Methods Materials

Not working

Not available

Method used

Order of work

Untrained

Over-allocated

Defective materials

Wrong materials

Scheduled on other activities

Scheduled on other projects

Lack prioritization

Too many promises

Safety hazards

Chapter 10 Project Risk Planning 279

real causes. The next step is to name the big bones. In this case, there are four big bones named people, machines, methods, andmaterials. There can be any number of big bones, and they can be named whatever makes sense to the team constructing the diagram. Team members are then encouraged to keep asking the question “why?” For example, why could people be a cause? Because they are not trained properly or because they are overallocated are the two rea- sons shown. Often, a team proposes many possible reasons. The team continues to break down the reasons—that is, asking why until it no longer makes sense to ask why. Cause-and-effect diagrams are frequently much fuller than this small example, with dozens of potential causes. Once the team can no longer think of possible causes, they need to determine which of the many possible causes are true causes. This can be accomplished by first selecting a few likely causes and then testing them.

10-3b Perform Quantitative Risk Analysis Perform quantitative risk analysis is “the process of numerically analyzing the effect of identified risks on overall project objectives.”14 While all projects use qualitative risk analysis, quantitative risk analysis is only used when necessary. Bigger, more complex, riskier, and more expensive projects often can benefit from the additional rigor of these more structured techniques. Quantitative risk analysis is often used when being able to predict with confidence what the probability is of completing a project on time, on bud- get, and with the agreed upon scope and/or the agreed upon quality is critical. Some of the more frequently used quantitative techniques are:

• Decision tree analysis: “a diagramming and calculation technique for evaluating the implications of a chain of multiple options in the presence of uncertainty.”15

• Expected monetary value (EVA) analysis: “a statistical technique that calculates the average outcome when the future includes scenarios that may or may not happen. A common use of this technique is within decision tree analysis.”16

• Failure mode and effect analysis (FMEA): “an analytical procedure in which each potential failure mode in every component is analyzed to determine its effect on reliability… and for all ways a failure may occur. For each potential failure, an estimate is made on its effect on the total system.”17

• Sensitivity analysis: “a quantitative risk analysis and modeling technique used to help determine which risks have the most powerful impact on the project. It exam- ines the extent to which the uncertainty in each project element affects the objective.…The typical display is in the form of a tornado diagram.”18

• Simulation: a technique that “uses a project model that translates the uncertainties spec- ified as a detailed level into their potential impact on objectives.…Usually uses probability distributions of possible costs or durations… and typically use Monte Carlo analysis.”19

Criteria to help select a suitable quantitative risk technique include the following:

• The methodology should utilize the explicit knowledge of the project team members.

• The methodology should allow quick response. • The methodology should help determine project cost and schedule contingency. • The methodology should help foster clear communication. • The methodology should be easy to use and understand.20

10-3c Risk Register Updates The probability of each risk occurring and the impact if it does happen are added to the register for each risk. The priority for each risk is also listed. Some organizations use a “Top 10” list to call particular attention to the highest priority risks. In addition, some

280 Part 2 Planning Projects

organizations choose to place higher priority on risks that are likely to happen soon. Some organizations want to call attention to risks that are difficult to detect—that is, risks with obscure trigger conditions. Any of these means of calling attention to cer- tain risks are also listed in the risk register. If the project team performed any quantita- tive risk analysis, the results are also documented in the risk register.

10-4 Plan Risk Responses Once risks have been identified and analyzed, the project team decides how they will handle each risk. Plan risk responses is “the process of developing options and actions to enhance opportunities and reduce threats to project objectives.”21 This is often a creative time for proj- ect teams as they decide how they will respond to each major risk. Sometimes a team develops multiple strategies for a single risk because they do not believe one strategy will reduce the threat or exploit the opportunity as much as the stakeholders would like. The team may decide that it is not worth the effort to completely eliminate a threat. In those cases, the goal is to reduce the threat to a level that the sponsor and other stakeholders deem acceptable.

10-4a Strategies for Responding to Risks Because so many possible strategies can be developed for dealing with project risks, it helps to classify the strategies. Common risk strategies are shown in Exhibit 10.12.

EXHIBIT 10.12 COMMON PROJECT RISK STRATEGIES

STRATEGY TYPE OF RISK EXAMPLES

Avoid Threat 1. Change project plan and/or scope 2. Improve project communications 3. Decide not to perform project

Transfer Threat 1. Insurance 2. Fixed-price contract 3. Hire expert

Mitigate Threat 1. Lower probability and/or impact of threat 2. Build in redundancy 3. Use more reliable methods

Accept Threat and opportunity 1. Deal with it if and when it happens 2. Establish triggers and update frequently 3. Establish time and/or cost contingencies

Research Threat and opportunity 1. Get more and/or better information 2. Verify assumptions 3. Use prototype

Exploit Opportunity 1. Assign talented resources to project 2. Give more emphasis to project

Share Opportunity 1. Allocate partial ownership to third party 2. Form joint venture

Enhance Opportunity 1. Increase probability and/or positive impact 2. Identify and maximize key drivers 3. Add more resources

Source: Adapted fromAGuide to the ProjectManagement Body of Knowledge (PMBOK® Guide) (Newtown Square, PA: ProjectManage- ment Institute, 2008): 261–263; Paul S. Royer, Project RiskManagement: A Proactive Approach (Vienna, VA:Management Concepts, Inc., 2002): 35; and Eric Verzuh,The Fast ForwardMBA in ProjectManagement, 2nd ed. (Hoboken, NJ: JohnWiley & Sons, 2005): 100–103.

Chapter 10 Project Risk Planning 281

AVOID RISK Many people prefer to avoid a risk if possible, and sometimes that is the best strategy. Sometimes, a project plan can be altered to avoid a risk by deleting the risky section. For example, if the organizers of a parade are told by the local police that traffic patterns on one section of their route are very difficult to control, perhaps they may alter the route. Project risk response strategy decisions often must be made with a thorough understanding of the priorities key stakeholders have of cost, schedule, scope, and quality. In this example, if no powerful stakeholder had a strong interest in the exact route, the change might be easily made. However, project managers need to understand that every decision they make regard- ing risk response strategies may impact something else. Another avoidance strategy is to ensure communications are good, especially concerning risky issues. Many risks can be more easily addressed with prompt and accurate information. The ultimate avoidance strategy is to not perform the project at all. This choice is sometimes made when the risks posed by the project are deemed unacceptably large given the potential benefits. Before a decision is made not to perform a project at all, normally each of the other strategies is considered.

TRANSFER RISK Sometimes, a decision is made to transfer some or all of a project risk to another organization. One common means to do so is through insurance. Project insurance works like any other type of insurance: a premium is paid so another organization will assume a level of risk. Higher premiums need to be paid for more risk to be assumed (think of lower deductibles). Therefore, using insurance as a risk transfer strategy is a two- part decision: Do we transfer risk, and, if so, how much risk do we transfer? The answer generally is “enough so the overall risk is acceptable to key stakeholders.”

A second transfer strategy deals with the type of contract used. An owner wishing to transfer risk to a developer will want to use a fixed-price contract. The developer who accepts the risk would insist on a higher price to cover her uncertainty. A devel- oper who wishes to transfer risk to an owner would prefer a cost-plus contract under which she is compensated for her cost plus a certain amount of profit. The owner, in turn, would prefer to drive for a low cost in such an arrangement because he is assuming the risk. Other types of contracts can be written so that both parties share the project risk.

A third risk transfer strategy is to hire an expert to perform in the area of the risk and to hold that person accountable. None of the transfer strategies eliminate risk; they just force someone else to assume it.

MITIGATE RISK Mitigation strategies are those in which an effort is made to lower risk. In general, this means either reducing the probability of a risk event happening and/or reducing the impact if it does happen. For example, a major risk could be that a key resource may not be available. To reduce the probability of that happening, perhaps the person could be hired well in advance of the project and protected from work on com- peting projects. To reduce the impact if this person was not available after all, perhaps the project team would like to use the second mitigation strategy and build in redun- dancy. They could train another team member to do the work of the key resource. Redundancy is a way of life in systems projects such as developing an aircraft. However, the simple answer is not to continue to build in more and more redundancy, because the aircraft would eventually become so heavy it could not fly and so expensive no one could afford it. Therefore, a third mitigation strategy is often utilized: Use more reliable meth- ods. If the primary way of performing a key activity is highly reliable, there is less need for other mitigation strategies.

ACCEPT RISK A fourth risk response strategy is to accept the risk. This is often used for the risks deemed to be minor. The project team deals with them if and when they happen. If the risks deemed to be minor really are, most of them will not happen, and when they do, most

282 Part 2 Planning Projects

will not cause major disruptions. However, some risks a team chooses to accept can have an unfortunate impact on the project if left untended. Therefore, project teams often define a trig- ger condition for one of these accepted risks. The trigger condition marks the dividing point where, instead of just watching for the risk, the team starts to deal with it. For fruit and vegetable growers in California, the trigger condition may be a weather report predicting cold tempera- tures. Armed with that knowledge, the growers enact strategies to protect their crops to the ex- tent possible and cost effective. The growers are willing to accept the risk of cold weather once in a while because they make enough money at other times to compensate. If they were in a climate with more cold weather, they may choose not to grow sensitive crops during the cold season. One other acceptance strategy is to put contingencies of time and/or money into the project plan to cover the risks that transpire. Each of these acceptance strategies can also be used to take advantage of opportunities. Establishing trigger conditions to notify the team when an opportunity is present, dealing with it as it happens, and having a little extra time and money to alter the project plans to reap the potential benefits all make sense. An example could be when a company develops a new style of hat, a celebrity wears it on TV, and the de- mand then takes off. By using more money to advertise to the unexpected audience, the com- pany may generate many additional sales.

RESEARCH RISK The best way to handle a risk may sometimes be to learn more about it. The first research strategy, therefore, is to secure better and/or more information so the proj- ect team understands what they are dealing with. Projects often are conducted in a rapidly changing environment in which decisions need to be made quickly, often based upon imper- fect and incomplete information. It is unusual to be able to gather and verify all the informa- tion desired; however, sometimes it is useful to improve the information available. Another research strategy is to verify assumptions that have been made. Assumptions that prove to be false become risks. Yet another research strategy is to perform the project on a small scale first to see if it works. This can include constructing a prototype, test marketing a new prod- uct, running new software in one department first, and so on. Project teams can often learn a great deal from trying their ideas on a small scale first. These research strategies work well for both reducing threats and capitalizing on opportunities.

EXPLOIT OPPORTUNITY One strategy that is aimed exclusively at opportunities is exploitation. A project manager may identify trigger conditions that, if reached, will allow her to go to her sponsor to request that the project become a higher priority. If the organiza- tion wants to exploit opportunities, they can assign more or better resources to the project, remove barriers, and give it more visibility in management reviews.

SHARE OPPORTUNITY One additional exploitation strategy deals with the results of the project. Perhaps the project team is able to develop a new product or service so rev- olutionary that the parent organization is not capable of fully exploiting it. In a case like this, the parent organization may spin off a nimble subsidiary, form a joint venture with another firm, or sell the rights to the product.

ENHANCE OPPORTUNITY Essentially, a project team wants to either maximize the prob- ability that an opportunity will occur and/or maximize the impact if it does. The project man- ager wants to identify key drivers of these positive impacts and develop strategies to capitalize upon them. Certainly, adding more or better resources is one way of enhancing opportunities.

10-4b Risk Register Updates The project manager sees that the risk register is updated with the results of the response planning. For each risk, this means the response strategy is noted. It also means that a single person is assigned as the “owner” of each risk. That person is responsible for

Chapter 10 Project Risk Planning 283

understanding the trigger and for implementing the strategy. Finally, any changes that need to be made to the project schedule, budget, resource assignments, and communica- tions plan should be included.

Summary All projects have some risks. More unique projects have more unknowns and, therefore, more risks. A project manager needs to use an appropriate level of detail in risk planning—enough to plan for major risks, yet not so much that a great deal of time is spent on minor risks.

Risk management planning starts with understand- ing what constitutes success for the upcoming project. This may require understanding the tradeoff decisions that key stakeholders are willing to make. Risk manage- ment planning is part of the overall project manage- ment plan and may be performed concurrently with other project planning.

Identifying risks includes gathering information on potential risks. This can be accomplished by having the project core team and selected subject matter experts brainstorm all of the possible risks. Many times, a core team can review documents such as the project charter, communication plan, or schedule to help iden- tify risks. The core team can look outside project documentation for reviews of literature by peers. Once risks have been identified, the core team creates the risk register with each risk categorized. Sometimes,

a team also lists potential causes for each risk and po- tential responses at this time.

The next major activity is to analyze the risks. At a minimum, this involves determining which risks are major—at least from the standpoints of how likely each risk event is and how big of an impact it will have if it happens. Sometimes, more sophis- ticated analysis is performed to identify the root causes of risks, to identify the trigger conditions that signify the risk event is about to happen, or to consider more complex relationships among risks. Quantitative techniques are sometimes used to determine which risks are major.

Risk response planning involves determining in advance how to respond to each major risk. Minor risks are handled by simply being aware of their potential and dealing with them if and when they occur. Eight types of risk response strategies that can be applied to major risks are avoid, transfer, mitigate, accept, research, exploit, share, and enhance. A project manager may decide to use multiple strategies on a large and critical risk. Armed with proper risk planning, a project manager is confident to begin even a risky project.

Key Terms from the PMBOK® Guide plan risk management, 270 performing organization, 270 threat, 271 opportunity, 271 risk management plan, 271 risk breakdown structure, 273 identify risks, 275 SWOT analysis, 275 Delphi technique, 275 root cause analysis, 276

trigger condition, 276 risk register, 276 perform qualitative risk analysis, 277 perform quantitative risk analysis, 280 decision tree analysis, 280 expected monetary value (EMV) analysis, 281 failure mode and effect analysis (FEMA), 281 sensitivity analysis, 281 simulation, 281 planning risk responses, 281

Chapter Review Questions 1. A negative impact is known as a(n) _______,

while a positive impact is known as a(n) _______. 2. To reduce the impact of threats and capitalize

on opportunities, a project manager should create a _________.

3. Should a project manager alone identify potential risks for the project? Why or why not?

4. During which stage of a project are most risks typically uncovered?

284 Part 2 Planning Projects

5. Relative to the project’s life cycle, when is the cost per risk discovered typically highest?

6. When a project manager is gathering informa- tion about risks, is it a good idea for her to set a limit on the number of risks that will be consid- ered? Why or why not?

7. What does a SWOT analysis examine? 8. What is a root cause analysis? 9. A key supplier for your project has not been

returning your calls or responding to your emails. This is an example of a _______, which indicates that a risk is likely to occur.

10. What are the two main criteria used when evaluating risks during qualitative risk analysis?

11. Should every risk, no matter how major or minor, have a contingency plan created to address it? Why or why not?

12. Are both qualitative and quantitative risk analy- ses used on all projects? Why or why not?

13. What is an example of transferring risk? 14. In the risk register, why should only one person

be assigned “owner” of a risk? 15. Which three risk strategies are used specifically

for dealing with opportunities?

Discussion Questions 1. List and describe the four different categories of

project success measures. 2. Give six examples of project stakeholder

priorities. 3. Describe tradeoffs that may need to be made among

them. Why is it helpful to have a wide level of par- ticipation in risk management activities?

4. List three methods that can be used for catego- rizing project risks. For a fund raising project, give examples of risk using each categorizing method.

5. To help identify risks, what are some questions a project manager could ask when reviewing the project charter and WBS?

6. You are hosting a large dinner party. What are two possible risks you would encounter? Identify at least one trigger condition for each.

7. Describe the various types of information that are often contained in the risk register. Why is each included?

8. What is the difference between major and minor risks? How is it calculated?

9. List and describe at least three common quanti- tative risk analysis techniques. Under what cir- cumstances would you find each one useful?

10. List and briefly explain the eight common risk responses that are used. Describe how youmight use two or three of them together on a project.

Exercises 1. For a project in which you are planning a campus

event with a well-known speaker, identify and quantify risks and develop contingency plans for the major risks.

2. For the same campus event project, perform a literature review to identify risks.

3. Engage another student team to perform a peer review of project risks for your project; you per- form a peer review for theirs.

4. For one of the risks identified in Exercises 1 through 3 above, construct a cause-and-effect dia- gram to determine possible root causes. Determine which of the possible root causes are probable.

Describe how you would test each probable root cause to determine if it really is a root cause.

5. For the risks identified in Exercises 1 through 3 above, identify trigger conditions that indicate each risk may be about to happen.

6. Brainstorm and group at least twelve risk factors (as shown in Exhibits 10.5, 10.6, and 10.7) for risks in one of the following types of projects: • Research and development projects • Organizational change projects • Quality improvement projects

PMBOK® Guide Questions 1. A SWOT analysis is an information gathering

tool that helps increase the range of identified risks by examining strengths, weaknesses, _______ and threats to a project.

a. opportunities b. options c. origins d. organizations

Chapter 10 Project Risk Planning 285

2. The _______ is an iterative document in which the results of risk analysis and risk response planning are recorded. a. root cause analysis b. risk register c. risk management plan d. cause and effect diagram

3. While all projects use _______ risk analysis, _______ risk analysis is only used when it is needed, and there is sufficient data to develop appropriate models. a. quantitative, qualitative b. quantitative, opportunity c. opportunity, qualitative d. qualitative, quantitative

4. A team endeavor to list, on individual sticky notes, all of the possible threats and opportu- nities that could occur to an upcoming project might be used during the _______ process. a. plan risk responses b. perform qualitative risk analysis c. identify risks d. perform quantitative risk analysis

5. Avoid risk, mitigate risk, accept risk, and _______ are all strategies for responding to negative risks, also known as threats. a. enhance risk b. prevent risk c. transfer risk d. share risk

6. An analytical technique used to determine the basic underlying source of a variance, a defect, or a risk is called _______. a. qualitative risk analysis b. Monte Carlo analysis c. SWOT analysis

d. root cause analysis 7. The Risk Management Plan describes the meth-

odology, roles and responsibilities, budgeting, timing, and risk categories for potential causes of risk. These risk categories can be structured into a hierarchical representation called a(n): a. organizational breakdown structure (OBS) b. risk breakdown structure (RBS) c. work breakdown structure (WBS) d. requirements breakdown structure (RBS)

8. Risks that have been identified and may or may not happen are referred to as “known unknowns,” and a _______ should be established to cover them if they are triggered. a. contingency reserve b. management reserve c. funding reserve d. risk buffer

9. _______ is a quantitative risk analysis modeling technique used to help determine which risks have the most powerful impact on the project. Using a tool such as a Tornado Diagram, it “examines the extent to which the uncertainty of each project element affects the objective being studied when all other uncertain elements are held at their baseline values.” a. Fishbone diagram b. Monte Carlo technique c. Expected monetary value analysis d. Sensitivity analysis

10. Expected monetary value (EMV) is commonly used within this type of analysis: a. root cause b. decision tree c. Monte Carlo d. cost/benefit

Example Project Create a risk register for your example project. Categorize each risk, list potential causes, and list potential responses for each cause, as shown in Exhibit 10.9.

Describe what each project success measure (from Exhibit 10.1) looks like on your example project. Iden- tify at least three risks to each success measure, deter- mine which are major risks, and for each major risk develop one or more contingency plans. Identify whether the contingency plan is an avoidance plan

(reducing the probability of the risk event), a mitiga- tion plan (reducing the impact of the event), or both.

Facilitate a discussion with the sponsor and other key stakeholders of your project. Have them determine the relative importance of their priorities and docu- ment them, as shown in Exhibit 10.2.

Perform a risk review for your example project. Use at least three types of review, as shown in Exhibit 10.8. Which of these types gave you the most useful infor- mation? Why?

286 Part 2 Planning Projects

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Alarcon, Luis F., et al. “Risk Planning and Management for the Panama Canal Expansion Program,” Journal of Construction Engineering and Management, October 2011: 762–770.

Kloppenborg, Timothy J., Arthur Shriberg, and Jayashree Venkatraman, Project Leadership (Vienna, VA: Management Concepts, Inc., 2003).

Kloppenborg Timothy J., Debbie Tesch, and Broderick King, “21st Century Project Sucess Measures: Evolution, Interpretation, and Direction,” Proceedings, PMI Research and Education Con- ference 2012 (Dublin, Ireland, July 2012).

Kloppenborg, Timothy J. and Deborah Tesch, “Using a Project Leadership Framework to Avoid and Mitigate Information Technology Project Risks,” in Dennis P. Slevin, David I. Cleland, and Jeffrey K. Pinto, eds., In- novations: Project Management Research 2004 (New- town Square, PA: Project Management Institute, 2004).

Kloppenborg, Timothy J., and Joseph A. Petrick, Managing Project Quality (Vienna, VA: Manage- ment Concepts, Inc., 2002).

Krane, Hans Peter, et al., “How Project Manager–Project Owners Interaction CanWorkWithin and Influence Project RiskManagement,”ProjectManagement Journal, April 2012: 54–67.

Lehtiranta, Liisa, “Relational Risk Management in Con- structionProjects:Modeling theComplexity,”Leadership and Management in Engineering, April 2011: 141–154.

Mbachu, Jasper, “Sources of Contractor’s Payment Risks and Cash Flow Problems in New Zealand Construction Industry: Project Team’s Perceptions of Risks and Miti- gation Measures,” Construction Management and Eco- nomics (October 2011) 29: 1027–1041.

Merritt, Guy M. and Preston G. Smith, “Techniques for Managing Project Risk,” in David I. Cleland, ed., Field Guide to Project Management, 2nd ed. (Hoboken, NJ: John Wiley & Sons, 2004).

Milosevic, Dragan Z., Project Management Toolbox: Tools and Techniques for the Practicing Project Manager (New York: John Wiley & Sons, 2003).

Papadopoulos, Thanos, et al., “The Criticality of Risk Factors in Customer Relationship Projects,” Project Management Journal (February 2012): 65–76.

Royer, Paul S., Project Risk Management: A Proactive Ap- proach (Vienna, VA:Management Concepts, Inc., 2002).

Schmidt, Roy, Kalle Lyytinen, Mark Keil, and Paul Cule, “Identifying Software Project Risks: An International Delphi Study,” Journal of Management Information Sys- tems 17 (4) (Spring 2001): 5–36.

Steffey, Robert W., and Vittal S. Anantatmula, “Inter- national Projects Proposal Analysis: Risk Assess- ment Using Radial Maps,” Project Management Journal (April 2011): 62–70.

Thomas, Sam, and M. Bhasi, “A Structural Model for Software Project Risk Management,” Journal of Management (March 2011): 71–84.

Yeh,Chung, et al. “RiskAssessment andAction Selection in Preliminary Design,” International Journal of Innova- tion and Technology Management 8 (1) (2011): 77–94.

Zou, Patrick X. W., Guomin Zhang, and Jiayuan Wang, “Understanding the Key Risks in Construction Projects in China,” International Journal of Project Management 25 (6) (2007): 601–614.

http://international.fhwa.dot.gov/riskassess/ risk_hcm06_04.cfm, accessed August 17, 2010.

http://leadershipchamps.wordpress.com/2009/06/14/ find-how-sensitive-is-your-project-against- variables-tornado-diagram/, accessed August 17, 2010.

Endnotes 1. PMBOK® Guide 550. 2. PMBOK® Guide 549. 3. PMBOK® Guide 564. 4. PMBOK® Guide 548. 5. PMBOK® Guide 560. 6. Ibid. 7. PMBOK® Guide 542. 8. PMBOK® Guide 564. 9. PMBOK® Guide 537.

10. PMBOK® Guide 561. 11. PMBOK® Guide 566. 12. PMBOK® Guide 560.

13. PMBOK® Guide 549. 14. Ibid. 15. PMBOK® Guide 536. 16. PMBOK® Guide 539. 17. PMBOK® Guide 540. 18. PMBOK® Guide 562. 19. Ibid. 20. http://international.fhwa.dot.gov/riskassess/

risk_hcm06_04.cfm, accessed August 2, 2013. 21. PMBOK® Guide 550. 22. Software Engineering Institute, Carnegie Mellon

University, http://www.sei.cmu.edu/risk/main.html.

Chapter 10 Project Risk Planning 287

PROJECT MANAGEMENT I N ACT I ON

Risk Management on a Satellite Development Project

Introduction Proactive risk management is definitely one of the key advantages in implementing and using standardized project management practices today. We always have the balancing act of managing the triple constraint of cost, time, and scope, and on top of that, we need to effectively assure project quality and that we have enough resources to do the job. In this age, we are continuously asked to optimize our performance and “be more efficient”; often, this is because we simply have too much work and not enough people to do it. So, in practice, we work with risks every day—from the risk of not spending enough time planning to the risk of not having enough supplies, or even the risk of not running a thorough enough risk management program.

Some time ago, I worked on a satellite development project that involved a lot of research technologies. There were many unknowns, with variables in the manufacture of components, integration of systems, working with subcontractors, tests, and other areas that made the project full of risk. Additionally, we were on a tight timeline for production and had only limited budget reserves available to handle cost overruns. Thus, we needed a practical way to manage and deal with the risks of the project. By systematically working with the risks of the project, we were better able to prepare responses to the risks if and when they occurred.

Planning For our project, it was essential to have an integrated system and mechanism for risk management. Thus, at the outset of the project, during the planning phase, we developed our risk management plan and established with the team the process for dealing with not only risk but also any subsequent changes that could occur with the project as a result of the risk. This was done during a day-long clinic where we exclusively worked on developing this risk plan, as we knew our project was high risk and we wanted to make sure we could work with the plan. We developed criteria for evaluating probabilities of occurrence and impact for the risk and also for prioritizing risks. Furthermore, we researched and compared our methods to industry standards for risk management such as those from SEI®.22

Execution Once we had a solid approach for risk management in this project, we then went forward with the processes of identifying our project risks, analyzing the risks, developing potential responses for the risks, and deciding upon next steps for the risks. Our approach to all this was an integrated one, using a risk management database tool we developed as its cornerstone. This tool allowed for anyone in the project team to view the risks, enter new risks, and provide input for potential risk responses. An example of a similar type of tool is shown in Exhibit 10.14, where each risk is logged as a record in the database. The database allowed the team to have a single repository for recording and logging all the risks for the project, which was critically important because the risks in satellite development were constantly changing.

Every other month, the project team would hold a risk management review, in which each risk would be discussed and any decisions on actions would be made. Typically, we would meet and review the risks logged in the database in this group setting, and the risk’s assigned owner would talk about the background of the risk, things that occurred since the risk was first logged (or since the last risk review), and what he or she felt the next steps needed to be. Project team members brought up other areas of the project that might have been impacted by the risk or new risks that resulted from the occurrence of the risk, or provided potential ideas for deferring, transferring, mitigating, or accepting the risk. The team also determined whether the risk decision needed to be elevated.

Another reason we held risk management reviews was to make sure that the team was up to date with the overall project’s risks. Based on the criteria we defined in developing the risk management plan, the database tool provided us a prioritized report of all the project’s risks. That risk report was used by the group to make decisions about the project and look at mitigation strategies for the project as a whole. The risk management review provided us with an avenue through which we could work together to resolve the high-priority risks of the project. Often, the high-priority risks were related to overall project drivers, and it was essential to be as proactive as possible in managing

288 Part 2 Planning Projects

PROJECT MANAGEMENT I N ACT I ON

those risks. Moreover, by examining and analyzing the project risks in this manner, potential risks for other related projects, in this case other satellite development projects, were also identified.

The level of risk management necessary for a project can vary greatly. On the satellite development project, it was necessary to have a comprehensive program to address risk because there were many unknowns. We

performed all our duties with the notion of understanding risk, and thus the risk management program addressed both the daily needs of logging and updating risks and the long-term strategic needs of understanding risk implications. However, for a smaller or more well-defined project, having such a detailed level of risk management may be unwieldy and difficult to manage. The key is finding the appropriate level for the project at hand.

EXHIBIT 10.13 RISK MANAGEMENT WORKSHEET

Source: Microsoft product screen shot(s) reprinted with permission from Microsoft Corporation.

Source: Lydia Lavigne, PMP, Ball Aerospace Co. Reprinted with permission.

Chapter 10 Project Risk Planning 289

CHA P T E R 11 Project Quality Planning and Project Kickoff

Founded in 1947, General Tool Company is a Cincinnati-based contract manufacturer of highly engineered defense and aerospace hardware. GTC’s Fortune 500 customers include Lockheed Martin, General Electric, General Dynamics, Raytheon, Boeing, and others.

Performing to the exacting standards of such a demanding clientele is a barrier to entry that few contract manufactures can overcome. A failure to provide objective quality evidence of sound and auditable project, risk, and quality planning systems can (and usually does) exclude would-be subcontractors from the bid and proposal process. For example, most major manufacturers of flight safety hardware are required to adhere to AS 9100c, which incorporates the well-known ISO 9001:2000 quality management system standards. Through various clauses, AS 9100c requires manufactures to connect the dots between project, quality, and risk management systems through a single, auditable system. While a detailed description of the AS

© Yu ri Ar cu rs /S hu tte rs to ck .c om

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Describe the major contributions to contemporary project quality made by each of the quality gurus and by TQM, ISO, and Six Sigma.

• Define each core project quality concept and explain why each is vital in planning and managing projects.

• Describe each of the project quality tools and tell when to use each.

• Explain what may be included in a project quality management plan.

• Compile a complete project management plan, use it to kickoff the project, and then baseline and communicate the plan.

290

Topics:

• Plan quality management

• Perform quality assurance

• Control quality

• Develop project management plan

9100c requirements are beyond the scope of this chapter, suffice it to say they’re extremely challenging to industry newcomers and offer a competitive advantage to companies like GTC who are able to meet them. In short, for GTC, proper quality planning is more than good project management—it is a matter of survival!

Quality and Risk As if manufacturing highly complex, tight-tolerance aerospace and defense hardware is not challenging enough, the majority of related contracts trans- fer the risk to the subcontractor through firm-fixed-price arrangements. Under such arrangements, the subcontractor agrees to manufacture hard- ware at an agreed upon fixed price, assuming all risks associated with schedule and cost overruns (unless otherwise specified through an approved change order process).

In such an environment, it is imperative for the subcontractor to under- stand all quality and technical performance requirements prior to beginning the manufacturing process. Failing to do so can erode profit margins, dam- age customer relationships, and negatively impact the performance of highly engineered projects.

Further, quality and technical performance requirements are typically required to be imposed upon the subcontractor’s supply chain via the “flow-down” process. This commonly occurs when processes are outside of GTC’s core capabilities, yet are required to complete the manufacturing process. Proper quality planning is essential to ensure that all provided ser- vices adhere to the stringent standards of the source documents (Purchase Order, Statement of Work, technical publications, etc.). Within GTC’s quality planning system, vendor selection requires special investigation to ensure the following criteria can be met:

• The vendor is on the GTC “Approved Vendor” list. • When required, the vendor is on the customer’s “Approved Vendor” list

(this is typically referred to as a “Yellow Pages”–approved supplier). • The vendor is capable of providing the service in the required time

frame and has available capacity to meet the demand. • The vendor can meet all the procedural requirements and provide the

required certifications for traceability and part pedigree.

PMBOK® Guide

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative Closure

Planning Executing Closing RealizingInitiating

RealizedResultTo Proceed

291

Failing to “flow-down” all quality requirements at the start of a project can create significant, if not irreversible, challenges to part delivery. This makes the quality planning process especially important to companies oper- ating within firm-fixed-price environments, like GTC.

Few knowledge areas are more important than project quality manage- ment; and this is especially true where the safety of aviation and defense personnel are involved.

Perhaps the best way to understand the contemporary approach to project management is to learn how the contemporary approach to project quality management developed. Many people have influenced the modern approaches to quality, and their contributions have largely been meshed together to give project managers a full understanding of project quality demands, processes, and tools. With this understanding, project managers are ready to perform project quality management—all the necessary work to ensure that project deliverables satisfy their intended purpose. This chapter includes the first part of project quality management, namely plan quality management, which is “the process of identifying quality requirements and/ or standards for the project and its deliverables, and documenting how the project will demonstrate compliance.”1 The remaining parts of quality management are covered in Chapter 14.

This is the final chapter dealing with project planning. Quality planning is often performed simultaneously with other aspects of project planning. Once the various aspects of planning are complete, the project manager leads the team in sorting out any inconsistencies. The team then takes the completed project plan to the sponsor and other stakeholders for approval. Once the plan is accepted, it is communicated widely, and the project execution formally begins. Completing and approving the overall project management plan in this manner demonstrates how contemporary project management is integrative, iterative, and collaborative.

On agile projects, quality is planned at a high level for the entire project at the outset and at a detailed level just before the start of each iteration.

11-1 Development of Contemporary Quality Concepts The contemporary approach to quality management has evolved first from the teachings of several quality “gurus” from the 1950s through the 1980s and then through various frameworks popularized during the last 25 years.

11-1a Quality Gurus Arguably the most influential thought leader in quality was W. Edwards Deming. One concise way to summarize his ideas is his four-part Profound Knowledge System, shown in Exhibit 11.1. Deming started as a statistician, and initially preached that understand- ing variation was essential to improving quality. By the time he had fully developed this system, he also stated that it is important to understand how companies operate as systems; that managers need insight in order to accurately predict the future; and that leaders need to understand individual motivations.

Joseph Juran, who was a contemporary of Deming, also wrote and lectured prolifically for decades. Juran is perhaps best known for his Quality Trilogy of quality planning,

A G I L E

292 Part 2 Planning Projects

quality control, and quality improvement, as shown in Exhibit 11.2. The PMBOK® Guide coverage of quality largely mirrors Juran’s approach.

Many other pioneers in quality, particularly Japanese and American, have added to the body of quality concepts and tools. Several of the most influential, and their contri- butions that apply specifically to project quality, are shown in Exhibit 11.3.

Much of the work of these pioneers and many others has been incorporated into three popular frameworks that many organizations use to define and organize their qual- ity initiatives. These frameworks are Total Quality Management (TQM), the Interna- tional Organization for Standardization (ISO), and Six Sigma.

11-1b Total Quality Management/Malcolm Baldrige TQM came into vogue during the late 1980s when it was becoming more widely apparent that the old way of trying to catch quality problems by inspection was not adequate. Many early advocates of TQM used slightly different ways of describing it. What they had in common was implied by the first word in the name: total. Most serious practitioners included several components in their TQM system. In the United States, government, business, consulting, and academic specialists in quality worked together to develop a common means of describing TQM. This description forms the key areas of the Malcolm Baldrige National Quality Award as shown in Exhibit 11.4.

11-1c ISO 9001:2008 While the Baldrige Award is a framework developed in the United States, ISO represents a framework developed in Europe. The International Organization for Standardization has developed many technical standards since 1947. ISO 9001 is the quality management

EXHIBIT 11.1 DEMING ’S PROFOUND KNOWLEDGE SYSTEM

Systems Interactions occur among parts of a system, and parts cannot be managed in isolation.

Variation Managers need to understand common and special causes of variation and then work to reduce both.

Knowledge Managers need to learn from the past and understand cause-and-effect relationships to predict future behavior.

Psychology Leaders need to understand what motivates each individual and how different people and groups interact.

Source: Adapted from James R. Evans and William M. Lindsay, The Management and Control of Quality, 8th ed. (Mason, OH: Cengage Learning South-Western, 2011): 94–99.

EXHIBIT 11.2 JURAN ’S QUALITY TRILOGY

Quality Planning Identify all customers and their needs, develop requirements based upon those needs, and develop the methods to satisfy those requirements.

Quality Control Determine what to control, establish measurement systems, establish standards, compare performance to standards, and act on differences.

Quality Improvement Select and support improvement projects, prove causes, select and implement solutions, and maintain control of improved processes.

Source: Adapted from James R. Evans and William M. Lindsay, The Management and Control of Quality, 8th ed. (Mason, OH: Cengage Learning South-Western, 2011): 104–106.

Chapter 11 Project Quality Planning and Project Kickoff 293

EXHIBIT 11.3 OTHER PROJECT QUALITY PIONEERS

THOUGHT LEADER ADDITIONAL KEY PROJECT QUALITY CONTRIBUTIONS

Clifton High-quality organizations encourage individuals to develop their strengths.

Crosby Quality is meeting requirements, not exceeding them. The burden of quality falls on those who do the work. Quality costs least when work is done correctly the first time. Quality improves more by preventing defects rather than fixing them.

Harrington Business processes can be improved using a systematic method.

Ishikawa Quality outputs start with understanding customers and their desires. Work to identify and remove root causes, not just symptoms. All workers at all levels must engage to improve quality. Most quality problems can be solved by using simple tools.

Senge Team learning is necessary to improve quality.

Shiba Societal networking accelerates quality improvement. When continual improvement is not enough, breakthrough is needed.

Taguchi Reducing variation saves money. Project deliverables will be better with a focus on improving methods.

Zeithaml Services pose different challenges from manufacturing when improving quality.

EXHIBIT 11.4 MALCOLM BALDRIGE NATIONAL QUALITY AWARD KEY AREAS

AND SPECIFIC CRITERIA

KEY AREA SPECIFIC CRITERIA

1. Leadership Senior leaders’ personal actions Organization governance system Fulfill responsibilities and support key communities

2. Strategic Planning Develop strategic objectives and action plans Deploy strategic objectives and action plans Measure progress

3. Customer Focus Engage customers Build customer-focused culture Listen to voice of customer and use this information to improve

4. Measurement, Analysis, and Knowledge Management

Select, gather, analyze, manage, and improve data, information, and knowledge assets Manage information technology Reviews and uses reviews for performance improvement

5. Workforce Focus Engage, manage, and develop workforce; assess workforce capability and capacity; build workforce environment conductive to high performance

6. Process Management Design work systems Designs, manages, and improves key processes Readiness for emergencies

Results Performance and improvement in all six key areas; Performance levels relative to competitors

Source: Adapted from Baldrige National Quality Program, “Criteria for Performance Excellence,” http://www.nist.gov/ baldrige/publications/upload/2011_2012_Business_Nonprofit_Criteria.pdf http://www.nist.gov//baldrige/publications/ upload/2009_2010_Business_Nonprofit_Criteria.pdf, accessed August 19, 2010.

294 Part 2 Planning Projects

standard, and the 2008 designation is the latest revision of the standard. When the standards first appeared, they focused largely on documenting work processes. However, over the years the standards have evolved, and the current five quality management areas with specific requirements are shown in Exhibit 11.5. Notice that they contain many of the same ideas as the current Baldrige Award key areas and specific responsibilities.

11-1d Lean Six Sigma Lean evolved from lean manufacturing ideas of eliminating as much waste as possible from work processes. Sigma stands for standard deviation—a statistical term for the amount of variation in data. Six Sigma quality literally means quality problems are mea- sured in parts per million opportunities. Many projects have few routine activities and many unusual activities, so the rigor of the statistics in Six Sigma is not always applicable. However, the ideas behind Six Sigma provide a meaningful framework for project quality. As of this writing, Six Sigma is a popular approach to quality as Motor- ola, General Electric, and many other companies have promoted its usage. General Elec- tric in particular expanded the focus of Six Sigma to include many service processes that people had previously said were too difficult to measure.

Six Sigma uses a disciplined process called the define, measure, analyze, improve, and control (DMAIC) process to plan and manage improvement projects. The DMAIC methodology is a 15-step process broken up into five project phases: define, measure, analyze, improve, and control, as shown in Exhibit 11.6. The DMAIC process is illus- trated to show objectives within each of the five key stages. It is shown as a continuous, circular flow because DMAIC is typically used as a method of implementing continuous improvement and thus can be practiced repeatedly. Lean Six Sigma uses DMAIC and waste elimination together to improve performance.

EXHIBIT 11.5 ISO 9001:2008 AREAS AND SPECIFIC RESPONSIBILITIES

AREA SPECIFIC REQUIREMENT

General Develop quality management system (QMS) Document QMS system including manual and records

Management Focus on customers Develop and support quality policy and objectives Allocate QMS responsibility and authority

Resources Provide competent resources Provide needed infrastructure Provide suitable work environment

Realization Control customer-related processes Control product design and development Control purchasing and production Control monitoring and measuring equipment

Remedial Carry out monitoring and measuring activities Identify and control nonconforming product Collect and analyze quality management data Make improvements and take remedial action

Source: Adapted from International Organization for Standardization, “Quality Management Principles,” http://www.iso.org/iso/ home/standards/management-standards/iso_9000.htm and “ISO 9001 2008 Translated Into Plain English,” http://www.praxiom. com/iso-9001.htm, accessed August 19, 2010.

Chapter 11 Project Quality Planning and Project Kickoff 295

11-2 Core Project Quality Concepts Each of the quality gurus and frameworks provides input into the contemporary under- standing of project quality. As stated in Chapter 1, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) uses a simple definition of project quality: “the degree to which a set of inherent characteristics fulfills requirements.”2 However, to fully understand both the meaning of this definition and how to achieve it, one needs to understand the four contemporary core project quality concepts that have evolved from the sources above. The four core project quality concepts are:

1. Stakeholder satisfaction 2. Process management 3. Fact-based management 4. Empowered performance

11-2a Stakeholder Satisfaction Stakeholder satisfaction consists of identifying all stakeholders, using a structured process to determine relevant quality standards, and understanding the stakeholders’ ultimate quality goals. External stakeholders may include customers, suppliers, the public, and other groups. Internal stakeholders may include shareholders and workers at all levels and all functions within the organization.

DEVELOPING QUALITY STANDARDS BASED UPON STAKEHOLDER REQUIREMENTS The decision process for developing relevant quality standards on a project consists of the following steps:

1. Identify all stakeholders. 2. Prioritize among the stakeholders.

EXHIBIT 11.6 THE DMAIC METHODOLOGY

AnalyzeImprove

MeasureControl

Define • Create Procedures and Documentation • Train Workers and Monitor Performance • Share Learnings

• Develop Possible Solutions for Root Cause • Select and Pilot Solution • Analyze and Confirm Results

• Describe the Process in Detail • Define Needed Data and the Collection Plan • Baseline Current Performance

• Understand Voice of the Customer • Describe the Process at an Overview Level • Charter the Improvement Project

• Identify Possible Root Causes • Collect Data • Confirm Root Causes through Data Analysis

Source: Timothy J. Kloppenborg and Laurence J. Laning, Strategic Leadership of Portfolio and Project Management (New York: Business Expert Press, 2012), p. 122.

296 Part 2 Planning Projects

3. Understand the prioritized stakeholders’ requirements. 4. Develop standards to ensure the requirements are met. 5. Make tradeoff decisions.

Stakeholders actively participate in the process of developing quality standards. There- fore, they make judgments about the quality of a process based on what they see. Thus, stakeholders judge the quality both of project work processes and of deliverables. When making tradeoff decisions, the project manager often facilitates the process, and the stakeholders actually make the decisions. Stakeholders frequently need to be reminded that the relative importance of cost, schedule, scope, and quality can be very helpful in determining sensible standards.

STAKEHOLDER SATISFACTION SAYINGS When satisfying stakeholders, it is helpful to remember a few sayings. One is the old carpenters’ advice of “measure twice, cut once.” This careful planning tends to yield less variation, less cost, and faster delivery—all of which satisfy stakeholders. Another saying is “meet requirements, but exceed expectations.” Contractually, a project must meet the agreed upon specifications, but if stakeholders see excellent work processes and experience clear communications, their expectations will be exceeded, and they will be even happier. This point regarding meeting requirements while exceeding expectations comes from two sources. Good project man- agement practice is to meet requirements without spending extra money or time. Good quality practice is to not only satisfy but also to delight customers. The third saying is “a smart project manager develops capable customers.” That means the customer is able to use the project deliverables to do his or her job better. This often results in opportunities for additional revenue streams by partnering, training, and supporting the customer.

Advice given on agile projects is to communicate often (maybe daily) with the owner and other stakeholders. This is good advice for any project.

11-2b Process Management A process is “a systematic series of activities directed towards causing an end result such that one or more inputs will be acted upon to create one or more outputs.”3 To effec- tively manage project processes, project managers need to understand, control, and improve them.

PROCESS UNDERSTANDING WITH A SIPOC MODEL The first part of understanding a project is to demonstrate that all work flows from suppliers, through the project, to customers. A useful way to envision this is a tool called a supplier-input-process- output-customer (SIPOC) model, as shown in Exhibit 11.7.

In Exhibit 11.7, the process boundaries are clearly defined. This prevents future scope creep from occurring by eliminating previous or later steps in the process. The SIPOC above also begins to identify key stakeholders who both provide inputs into the process (suppliers) and receive benefits from the process (customers) and shows feedback loops that provide useful information.

One way to interpret the SIPOC is to think backward from the project’s customers. As described previously in the stakeholder satisfaction section, it is helpful for a project manager to identify all of the customers for his or her project and the outputs each desires. Since that is usually a far-reaching list, prioritization decisions need to be made. At that point, the project manager can work with the project core team to define the work processes necessary to create those outputs. Then they can identify the inputs they need in order to accomplish those activities and determine who will supply them.

Once the supplier-customer view is understood, it is time to determine whether the process is capable of creating the project deliverables. This discussion should be initiated

A G I L E

Chapter 11 Project Quality Planning and Project Kickoff 297

when the project charter is developed. As people discuss the milestone schedule, risks, and constraints, if there are serious doubts, they should be raised. On some small pro- jects, that may be enough to determine if the proposed methods of creating the project deliverables will work. On others, more detailed analysis of schedule, resources, and risks may yield further insight. When considering if a project process is capable, the project manager needs to understand the conditions in which the project may operate and ensure that the methods can be flexible enough to handle various contingencies that might develop.

Experienced project managers understand that it is far better to design quality into their processes than to find problems only upon inspection. In the first place, it costs more to make junk and then remake to obtain good outputs. Secondly, having to rework anything aggravates time pressure that already exists on many projects. Finally, even the best inspectors do not find every mistake, and some of the mistakes are likely to reach customers.

PROCESS CONTROL The second aspect of process management is process control. Control is “comparing actual performance with planned performance, analyzing variances, assessing trends to effect process improvements, evaluating possible alterna- tives, and recommending appropriate corrective action as needed.”4 The purpose of process control is to have confidence that outputs are predictable. Process control is cov- ered in Chapter 14. If the outputs are not predictable—or if they are predictable but not satisfactory—then a project manager needs to use the third aspect of process manage- ment: process improvement.

PROCESS IMPROVEMENT WITH A PDCA MODEL Processes can be improved in either a continuous or a breakthrough fashion. All project core team members and subject matter experts (SMEs) should be thinking of little ways they can improve at any

EXHIBIT 11.7 PDE DELIVERABLE ANALYSIS FUNCTIONAL MODEL

Input Adjustment Feedback

PDE Deliverable Analysis Functional Model

Input

$

Deliverable

Deliverable Process

Deliverable Adjustment Feedback

Supplier • Upstream Functional Interface

•Qualities •Characteristics •Standards •Localized Items •Timing •Conditional Needs

•Qualities •Characteristics •Standards •Localized Items •Timing •Conditional Needs

Resources •Labor/Skill Sets •Materials/Equipment •Vendors •Applications

Customer • Downstream

Functional Interface

Source: Paul Kling, PMP.

298 Part 2 Planning Projects

time. Slow and steady improvement is a good foundation. However, sometimes substan- tial improvement is necessary, and a breakthrough is in order. Regardless of the size of improvement desired, many models exist to guide the effort. Improvement models such as DMAIC are usually based upon the plan-do-check-act (PDCA) improvement cycle, as displayed in Exhibit 11.8.

When project managers are considering process improvements, they often involve suppliers and/or customers in a partnering arrangement. Often, they need to forecast

changes in their work environment, technology, or customer desires. Organizations that take a balanced view of long-term improvement and short-term results create a culture where project process improvement can thrive. Organizations that focus almost exclusively on short-term results make it hard for project managers to devote much energy to pro- cess improvement.

11-2c Fact-Based Management One challenge many project managers face is making decisions based upon facts. Making decisions using facts sounds like a sensible thing to do, yet it is diffi- cult because:

• Opinions get in the way. • It is hard to know what data need to be collected.

• Projects often operate with so much time pressure that decisions need to be made quickly.

Four aspects of fact-based management are understanding variation, deciding what to measure, working correctly with data, and using the resulting information appropriately.

EXHIBIT 11.8 PLAN-DO-CHECK-ACT MODEL

Plan: Select needed improvement, understand process and reasons for trouble, and create plan

Do: Try the change on a small scale and collect data

Check: Compare the results after the change

with those before to see if there was an improvement

Act: If results are good enough, implement the improvement,

otherwise try again

P

DC

A

© Cr ea ta s Im ag es /J up ite r Im ag es

Evenwith good inspectors, somemistakeswill reach customers if poor quality exists in project processes.

Chapter 11 Project Quality Planning and Project Kickoff 299

UNDERSTANDING VARIATION Project decision makers need to understand the dif- ference between two types of variation. A common cause is variation that is a result of the product design and the method of making it and is exhibited by a random pattern within predictable limits. On the other hand, a special cause is variation that comes from external sources that are not inherent in the process and can be quite unpredictable. It is important to determine when there is variation on a project whether it is within the range of what can be expected for that particular work activity or deliverable (common cause) or whether something unusual is happening (special cause). If the variation is due to a common cause, but the results are still not acceptable, some change needs to be made to the system—the way in which the work is accomplished. However, if the change is due to a particular cause, then the way to improve is to change that particular cause and not the entire system. Many quality proponents estimate that a large majority of var- iation is due to common causes, yet many managers are quick to try to find a person or issue to blame (special cause). The problem is often compounded when a cause is really part of the system, yet individuals are blamed. The problem does not go away, and peo- ple become fearful. Management by facts requires an understanding that variation can be due to either common or special causes, a determination to discover which type, and the resolve to act appropriately upon that discovery.

DETERMINING WHAT TO MEASURE A project manager wants to avoid the extreme of not measuring anything since he or she is in a hurry and there is not enough time, and the other extreme of measuring many things just to be sure. As project managers become more experienced, they develop an understanding of how many data are useful to collect and when they need to move into action regardless of the data they have. A quality metric is “a descrip- tion of a project or product attribute and how to measure it.”5 Measures may include project attributes such as on-time or on-budget performance or product attributes such as defect fre- quency. If a good charter was created, a milestone schedule with acceptance criteria for each milestone was developed. These can be useful measures. Project teams often can seek use- ful measures when they study lessons learned from previous projects. Many lessons either state what worked well and should be repeated on future projects or what worked poorly and should be avoided on future projects. Both often provide ideas for useful measures. The project manager and sponsor should agree on what mea- sures will be taken, when they will be taken, and under what circumstances. While many sponsors can be quite busy, the more specific this agreement becomes, the more useful the data collected are likely to be.

WORKING CORRECTLY WITH DATA A third aspect of management by facts is how the identified data are collected, handled, and stored. Data are simple representations of facts that are collected using a measurement process.6 Generally, the person(s) closest to the situation are best for collecting data. Efforts should be made to ensure that the data are complete, without errors, and timely. Many project teams either use templates from their organization or create their own forms for collecting data. When more than one person is involved, efforts should be made to be consistent. Once the data are collected, they should be analyzed. A great deal can be learned by using simple tools to look for patterns and trends in data. On larger, more complex projects and sophisticated Six Sigma projects, more detailed statistical analysis is often used. The analysis should turn the raw data into information useful to decision makers.

USING THE RESULTING INFORMATION APPROPRIATELY The final aspect of mak- ing fact-based decisions is how the information is used. Information is derived from data and understood in the context of the project.7 Project communications plans often spell out

300 Part 2 Planning Projects

how the information is disseminated. The best project cultures encourage truth and transpar- ency in communication—even when it is inconvenient. People are encouraged to use informa- tion to challenge opinions and decisions. Making decisions based upon facts often requires courage. It also requires judgment because challenges that are of a factual nature are helpful, yet if the challenges become personal and are not fact based, they can be destructive.

11-2d Empowered Performance The fourth and final core project quality concept is empowered performance. The goal of empowered performance is to have capable and willing workers at every level and every function within a company. Corporate leaders set the stage for this by developing the organizational culture. Project sponsors and managers, in turn, develop the project cul- ture. Remember from Chapter 3 that organizational culture includes the formal and in- formal practices utilized, along with the values shared by members of an organization. Part of an empowered performance culture is setting an expectation for managers to en- courage their associates to take appropriate risks and to treat risk events as learning op- portunities, not as a time to punish. Part of it is training and equipping workers so they are willing to take risks. Part is getting managers to let go of some decision-making au- thority so those lower in the organization can make some decisions. Yet another aspect of empowered performance is helping to develop specialists who can aid anyone in the organization. An example is a person trained as a Black Belt in a Six Sigma organization, who becomes an expert in guiding process improvement projects.

RECOGNIZE INDIVIDUALITY One essential understanding in creating capable and willing workers is that everyone is an individual. Leaders at all levels can promote inclusiveness and recognize that diversity is not only accepted, but also very helpful as projects develop.

CAPITALIZE ON INDIVIDUAL STRENGTHS Outstanding project managers not only want to recruit and develop a unique team, they also want to capitalize on each person’s un- ique strengths. Each person has unique talents, and the best opportunity for each person to improve and feel validated is to use their unique talents. When a person feels his boss under- stands him and works to create opportunities for him to do both what he most wants to do and what he has the potential to be best at, he achieves at the highest possible level.

EMPHASIZE INDIVIDUAL RESPONSIBILITIES Empowered performance requires that people understand and accept their responsibilities. Much of the responsibility falls upon the project manager and core team. However, SMEs are responsible for their indi- vidual activities. Functional managers, who are the technical supervisors of the SMEs, are responsible for the methods of work chosen. Sponsors share a high-level responsibility for project completion with project managers. Customer representatives are responsible for understanding the impact of directives they may give a project manager. Ultimately, everyone must understand what they need to do, realize how it fits in the bigger picture, and then commit to both completing their work correctly and accepting the conse- quences of their decisions.

USE APPROPRIATE COLLABORATION Finally, appropriate collaboration is a key to developing empowered performance. This is true both within and beyond the organiza- tional boundaries. A great deal of project work is performed by cross-functional teams. Cross-functional teams are most effective when individual, team, and organizational learning flourishes. One effective method of encouraging this learning in projects is to develop lessons learned at the completion of project milestones and at project closure. These lessons then need to be shared openly with other project teams. Collaboration

Chapter 11 Project Quality Planning and Project Kickoff 301

and learning accelerate when people share outside of their parent organization. Of course, some things cannot be shared, but a surprising number of things can be shared. When the recipients of those lessons reciprocate, the first team learns. This type of exter- nal sharing can be through conferences, company exchanges, or other means. An example of a unique project challenge that needed empowered performance to be successful is the vintage aircraft shipping project in Exhibit 11.9.

11-2e Summary of Core Concepts A summary of project Quality core concepts is shown in Exhibit 11.10.

11-3 Plan Quality Management The quality management plan is “a component of the project management plan that describes how an organization’s quality policies will be implemented.”8 Therefore, a logical place to start is by understanding what a quality policy is and how it governs

EXHIBIT 11.9 VINTAGE AIRCRAFT SHIPPING PROJECT

Global Shipping Company (GSC) was approached by an individual who was interested in selling and shipping an antique $1 mil- lion 1942 Staggered-Wing Beech aircraft from Cincinnati to a buyer in Australia. Since the aircraft was fragile, a plan needed to be developed for moving it as economically as possible while avoiding damage.

One challenge was handling the entire project in-house using only the company’s staff, equipment, and resources, and the other was to devising a custom solution for moving this unusual piece of cargo.

GSC has an organizational culture that encourages cross-training, collaboration among departments, risk-taking, and designing creative approaches to problem solving while minimizing cost. Because of the size and fragility of the aircraft, a strategy was devised to dismantle it and ship via containerized ocean freight. The project was broken down into five distinct segments: pick up, dismantling, packing, loading, and shipping.

To pick up the entire aircraft, the equipment, permits, and escorts had to be arranged to get the aircraft intact from the air- port and move it to the warehouse down a major street on the back of a flatbed truck In order to fit in a standard ocean con- tainer, the aircraft had to be dismantled—under the supervision of the FAA—and documented to meet FAA regulations. To avoid damage, each piece had to be individually packaged. Different types of cloth and foam had to be tested and selected in order to prevent scratching the aircraft. Due to the height restrictions, the warehouse personnel had to design and build a custom

gurney to allow the body of the plane to be wheeled into the container and secured. Once packaged, the individual pieces were then loaded, blocked, and braced into the container to prevent damage while in transit; then the aircraft was shipped. The dismantling, documentation, and packing process was designed in a way that the new owner of the aircraft could replicate it in order to move the plane for air shows and events.

The project’s success was achieved by having the courage to take on the project in the first place, the ability to use the company’s resources creatively and efficiently, and the ability to adapt the plan when unexpected events occurred. The result was a project that was successfully completed, meeting all FAA standards, exceeding stakeholder expectations, and developing a shipping process that can be replicated.

Source: Danny McKee, Global Shipping Company.

© Da nn y M cK ee

302 Part 2 Planning Projects

the actions of a project manager and team. The remainder of this section discusses the components of a project quality management plan and process improvement plan.

11-3a Quality Policy The top management of an organization normally writes a concise statement to guide their company’s quality efforts. This policy reflects top management’s principles of achieving quality and the benefits they hope to achieve with good quality. Project man- agers normally first consider using the quality policy of their parent company—if it is a good fit. If not, or if the project is a partnership between organizations, the project man- ager may need to combine and/or supplement the quality policies. However, the project’s quality policy should never violate the intent of the quality policies of either the parent company or of a major customer.

EXHIBIT 11.10 PROJECT QUALITY CORE CONCEPTS

CONCEPT SPECIFIC GUIDANCE

Stakeholder

Satisfaction

Identify all internal and external stakeholders.

Prioritize among the stakeholders.

Understand the prioritized stakeholders’ requirements.

Develop standards to ensure the requirements are met.

Make tradeoff decisions.

Realize stakeholders will judge quality both of work processes and deliverables.

Measure twice, cut once. (Plan and check the plan.)

Meet requirements, but exceed expectations.

Develop capable customers.

Process Improvement

Learn about process with the supplier-input-process-output-customer model.

Realize designing a quality process is far better than merely trying to find mistakes.

Ensure project processes are capable and flexible.

Control project processes to make them predictable.

Improve project processes using a model based upon the plan-do-check-act concept.

Fact-Based Management

Understand the difference between common and special causes of variation.

Select a few key well-defined items to measure.

Carefully collect data and use appropriate analysis techniques to create useful information.

Encourage truthful, transparent, and challenging communication when making decisions.

Empowered Performance

Develop capable and willing workers at every level and every function.

Develop a risk-taking project culture.

Understand each person is an individual.

To the extent possible, let everyone do what they will enjoy doing and what their strengths support.

Ensure everyone understands and accepts their responsibilities.

Share lessons learned and other information as widely as possible.

Chapter 11 Project Quality Planning and Project Kickoff 303

A study of 25 corporate quality policies in 2013 using an Internet search found that they vary widely. Some are less than 20 words, while others are over 200 words. The content and style can be quite different. The frequency of terms that interest project managers is shown in Exhibit 11.11.

Several interesting patterns can easily be found. First, virtually every policy includes a ref- erence to customers. The vast majority state that customers are the reason for their existence. Next, most quality policies also include improving processes. Many include satisfying requirements, but very few include exceeding requirements. This means that, for most com- panies, quality is measured by how well requirements are met, not exceeded. A large majority of policies mention both products and services—a reminder to project managers that services and information are frequently needed along with products to satisfy a customer’s needs. A majority of firms explicitly include value to customers and/or cost control.

The next tier of responses includes the importance of employees, excellence, commit- ment, meeting standards, and sustainability/reliability/dependability. The lowest tier lists many other words that appeared in 10 to 20 percent of the policies. That does not mean decision makers necessarily feel these terms are unimportant—just that they are not as important as the ones explicitly mentioned. Remember, many of these policies are very short and only include a few key thoughts. They are meant to set direction, not plan detail.

EXHIBIT 11.11 TERMS IN CORPORATE QUALITY POLICIES

TERM PERCENT OF POLICIES

Customer 92

Improve process 84

Product 72

Satisfy requirements 68

Service 64

Value/cost 56

Employees 44

Best/excellence/high quality 44

Commitment/leadership 40

Meet standards/laws 36

Sustainable/reliable/dependable 36

Time/responsiveness 16

Suppliers 16

Safety 16

Exceed requirements 12

Measure 12

Reputation 12

304 Part 2 Planning Projects

11-3b Quality Management Plan Contents In addition to the quality policy, most project quality management plans describe which quality standards the project will use and how the project team will implement them. The quality management plan may include a description of the quality baseline by which the project will be judged, along with methods for quality assurance and control.

The quality management plan is a portion of the overall project management plan. On many small, simple projects, the quality planning is performed concurrently with other plan- ning, and the quality plan is seamlessly incorporated into the project plan. On some large, complex, or unusual projects, the quality planning is handled separately, and the plan, while a portion of the overall project plan, appears as an additional document.

A project quality management plan should describe how to identify some or all of the following:

• The project’s overall quality objectives • Key project deliverables and the standards to evaluate each • Deliverable completeness and correctness criteria from the customer’s viewpoint • Quality control activities • Critical project work processes and standards to review each • Stakeholder expectations for project processes • Quality assurance activities • Quality roles and responsibilities • Quality tools • Quality reporting plan9

On agile projects, a definition of done is explicitly stated. This includes acceptance criteria of features, agreement of what done is for each iteration, and a demonstration to prove the deliverables work.

11-3c Quality Baseline The project work should be clearly defined by this point, in a scope statement and/or a work breakdown structure. Appropriate quality standards are selected for the materials and other inputs, work activities, documentation, and project deliverables. These standards might be industry norms, customer-specific standards, or government regulations. The project manager is ultimately responsible for selecting appropriate standards and developing additional stan- dards that may be needed. However, project managers normally take their cues from func- tional managers and SMEs for many standards dealing with methods and from customers on standards dealing with documentation and deliverables.

The quality baseline reflects the agreed upon quality objectives. It can include metrics that define exactly what will be measured, how each will be measured, and the target value of each.

11-3d Process Improvement Plan A process improvement plan is “a subsidiary plan of the project management plan. It details steps for analyzing processes to identify activities that enhance their value.”10 Pro- cess improvement was discussed earlier in the process management core concept.

11-3e Quality Assurance Perform quality assurance is “the process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards and operational definitions are used.”11 This is a broad set of proactive management activities designed to give key stakeholders confidence that sensible methods and capable people are working on the project. This hopefully yields good project deliverables and

A G I L E

Chapter 11 Project Quality Planning and Project Kickoff 305

documentation. Quality assurance is one way to simultaneously improve quality and manage stakeholder relations.

Perhaps quality assurance is best understood by considering two of its primary meth- ods: the quality audit and process analysis. A quality audit is “a structured, independent process to determine if project activities comply with organizational and project policies, processes, and procedures.”12 It is used to determine what methods are being used (hopefully the methods determined in the quality baseline) and whether they are effec- tive. For audits to be effective, people need to be convinced that the real purpose is to improve work methods and not to punish individuals.

Process analysis “follows the steps outlined in the process improvement plan to identify needed improvements.”13 It can follow an improvement model such as the DMAIC method shown in Exhibit 11.6 or the PDCA model shown in Exhibit 11.8. Process improvement is used to improve both quality and productivity. Process improvement can be of a continuous nature, in which many incremental improvements are made over time, or of a breakthrough nature, in which a substantial change is planned and implemented at once.

11-3f Control Quality Control quality is “the process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes.”14 This detailed set of reactive technical activities verifies whether specific project deliverables meet their quality standards. Quality control may include inspection of inputs, activities, and deliverables. It includes a work performance reporting system. Change requests are an output of quality control. These requests may include recommendations for:

• Preventive actions—“an intentional activity that ensures the future performance of the project work is aligned with the project management plan.”15

• Corrective actions—“an intentional activity that realigns performance of the project with the project management plan.”16

• Defect repair—“an intentional activity to modify a nonconforming product or product component.”17

11-4 Project Quality Tools Literally hundreds of tools have been developed to help organizations manage the quality of their processes. Many of these tools are variations of each other and have multiple names. Many of the quality tools can be applied specifically to managing project quality. Exhibit 11.12 lists some of the more frequently used project quality tools with brief descriptions. Since many of these tools can also be used on projects for areas in addition to quality, the chapter in which each first appears is also listed.

11-5 Develop Project Management Plan Chapters 5 through 11 have all dealt with aspects of project planning. On small, simple projects, the various portions of this planning may be combined to a large extent. On larger, more complex projects, specific methods are often used to plan the various project aspects separately, such as cost, schedule, resources, communications, risk, and quality. If they have not been planned together, they need to be compiled into a unified project management plan. Conflicts need to be resolved. A configuration management system needs to be selected or developed. The project manager should apply a sanity test to all project plans. There is often a formal project kickoff of some sort, and after everything is

306 Part 2 Planning Projects

agreed, the scope, schedule, budget, and so forth are baselined, and the baseline becomes part of the project management plan.

On agile projects the overall plan for the project (called the release plan) is only at a high level, while the detailed plans for each iteration are baselined right before each iteration starts.

11-5a Resolve Conflicts Sometimes, when all parts of the plan come together, it becomes obvious that the overall plan is impractical. If this occurs, the key stakeholders may need to determine their

EXHIBIT 11.12 PROJECT QUALITY TOOLS

TOOL CHAPTER DESCRIPTION

Charter 4 High-level agreement to start project describing authority, scope, expectations, and resources

Lesson learned 4 Knowledge from experience captured and shared

Stakeholder analysis 5 Identification and prioritization of stakeholder desires

Communication manage- ment plan

5 Document that guides and assigns responsibility for communication with stakeholders

Voice of the customer 6 Captured desired benefits and features in customer’s own words

Brainstorming 6 Quick generation of many ideas to identify gaps, issues, roadblocks, or potential solutions

Quality metrics 6 Crisp definition of what and how to measure specific performance

Project risk review 10 Thorough document review to uncover risks

Root cause analysis 10 Technique to discover underlying reason for problem

Cause and effect diagram 10 A visual outline, often resembling a fish skeleton, used to identify and organize possible causes of a stated outcome

Supplier, input, process, output, customer (SIPOC)

11 High-level view of process and stakeholders

Quality audit 11 Structured process to ensure project activities comply with organizational policies

Benchmarking 14 Identifying and analyzing best practices for improvement ideas

Flow chart 14 A visual model used to show inputs, flow of work, and outputs and to identify possible data collection points for process improvement

Check sheet 14 A simple, structured form used to gather and organize data for analysis

Pareto chart 14 A vertical bar graph used to identify and plot problems or defects in descending order of frequency or cost

Histogram 14 A vertical bar chart used to show the average, extent of variation, and shape of measure- ments recorded for a process variable

Run chart 14 A special type of scatter diagram in which one variable is time, used to see how the other variable changes over time

Control chart 14 A run chart with process average and control limits used to distinguish between common and special causes of variation

A G I L E

Chapter 11 Project Quality Planning and Project Kickoff 307

priorities and tradeoffs. What do they really most want and need from the project? Are all of the quality standards truly mandatory, or can one of them be relaxed a bit? Is the imposed deadline really critical, or, seeing the impact it poses for costs and risks, can it be relaxed a bit? Is the budget a true maximum, or can it be adjusted to secure the desired features? These questions and others like them have probably been asked all along, but now they take on added urgency because once the project plan is approved it may be more difficult to make these changes.

11-5b Establish Configuration Management Project planning can be hard work. Once the plan is in place, it still takes hard work to control the project. One last part of planning is to create a configuration management system to aid in that control. A configuration management system is “a collection of formally documented procedures used to… identify and document functional and phys- ical characteristics of a product, result, service or component; control any changes; record and report each change; and support the audit… to verify conformance to requirements.”18

11-5c Apply Sanity Tests to All Project Plans A common saying is appropriate to consider here: “can’t see the forest for the trees.” This means that sometimes a person is so concerned with details that they forget the big picture. During the first project stage (initiating), the primary deliverable the team created was a charter. The charter is a high-level look at a project, so seeing the big pic- ture was easy. During the more detailed planning stage, however, the team looked in great detail at scope, schedule, resources, cost, communications, risks, and quality. Now they need to step back a bit and ask if these all work well together. The project manager and core team should apply a sanity test to their project plans by asking one another questions to be sure that the plan makes sense. Some of these questions could be as follows:

• Does the critical path look reasonable? • Do the milestones look achievable? • Are some resources overallocated? • Does everyone understand what they are supposed to do? • Do we really understand our customers? • Are the customers’ desires likely to change? • How well do we understand the standards we will be judged against? • Are the methods for completing our work really sensible? • Are we confident we can gather and analyze the data we need to control this?

11-6 Kickoff Project Project kickoff meetings are conducted for many reasons. First, everyone should express their legitimate needs and desires and should strive to understand the desires of all the other stakeholders. If the leader charged with accomplishing the project does not have the full authority to direct all of the project work activities, she needs to use her influence to get everyone excited about the project, to feel pride in their participation, to feel they share in the risks and rewards the project offers, and to be motivated to self-manage as much as possible. Many people may have helped with some parts of the project planning. This is their chance to see how all the parts fit together. Since many projects fail because of “touch points” where one worker hands

308 Part 2 Planning Projects

off work to another, it is critical for all parties to understand these potential trouble spots. Kickoff meetings are also helpful in convincing all the project stakeholders that the project leaders (sponsor, project manager, and core team) will be good stewards of the customer’s and the parent organization’s assets. Answering any remaining questions and overcoming lingering concerns helps to accomplish this. Finally, all interested parties (outside customers, top management, functional managers, frontline workers, and any others) should be eager to commit to the project and get on with the work!

11-6a Preconditions to Meeting Success Several preconditions that must be met for project kickoff meetings to be successful are as follows:

• The sponsor and project manager need to set clear direction during the planning. • The core team needs to commit to the project first—it is hard for them to convince

others if they do not believe in it themselves. • An atmosphere of trust and relationship building should be set by all. • Project leaders need to practice active listening to uncover potential problems. • As many people as possible should be included in parts of the planning to enhance

chances so they will buy in to the resulting project plan.

11-6b Meeting Activities The formality of a kickoff meeting can vary considerably depending on the size and type of project. Typical activities that might be included in the kickoff meeting are the following:

• The sponsor and project manager describing the importance of the project • The customer(s) describing their acceptance standards, sense of urgency, and budget

concerns • The project manager outlining the project goals • The project manager and the core team describing work expectations • The project manager unfolding the project plan and its current status (if work has

commenced) • The core team explaining the communications, risk, and quality plans • Everyone asking questions and making suggestions • The project manager authorizing appropriate changes to the project plan • Everyone concurring with the overall plan and to his or her individual action items

On small, simple projects, the charter presentation and signing can take the place of a kickoff meeting. However, on many projects, the team needs to perform much more detailed planning after the charter is signed. Project kickoff meetings are vital for com- munications and commitment on these projects. Exhibit 11.13 is an example of how the information systems and technology division of a major healthcare company kicks off a project.

11-7 Baseline and Communicate Project Management Plan

Once the project plan is complete and accepted by the stakeholders, the plan is baselined. A baseline is the approved plan. Many project plans are developed iteratively as more information comes to light. A project plan is considered to be in draft form until enough

Chapter 11 Project Quality Planning and Project Kickoff 309

information is available for the key stakeholders to commit to all of the details and baseline the plan. At that point, it becomes official, and any changes in the future need to be formally approved and documented.

This is a time of great joy, because this marks the transition between planning and executing the project. In reality, on many projects, some activities that are on the critical path or nearly critical paths are started before the official project kickoff. Planning also continues in the form of replanning to adjust to changing circum- stances. However, the majority of planning is done, and the majority of executing is just starting.

The project management plan needs to be communicated in accordance with the communications plan requirements. Hopefully, many of the key stakeholders are able to attend the kickoff meeting. Regardless of who is present, proper communication needs to be sent to all stakeholders.

EXHIBIT 11.13 IS&T PROJECT LAUNCH ASSESSMENT AGENDA

Purpose: The Project Manager is to illustrate to an executive audience the chartered IS&T project’s readiness to successfully launch. Upon conclusion of the Project Manager’s presentation, the executive audience will determine and document the actions required for the project to launch.

Prerequisite: The Project Manager is required to complete the Project Deliverable Review and receive documented approval from the Project Deliverable Review Board in order to proceed to the Project Launch Assessment.

Standard Participants

• Core Group (CG) (CIO and IS&T Director) PMO Manager • Project Manager • Functional Manager PMO Consult • Quality Consult • Security Consult (Optional) • Test Coordinator • Sponsor

Required Documents: The Project Manager is required to present the PLA materials online. If a paper copy is needed, it should be printed double-sided.

• Project Charter PMO Risk Forms • Project Financial Worksheet • Master Test Plan • Progress Report—PDR

Project Launch Assessment Agenda: The Project Manager is required to present all of the listed deliverables in the provided order, focusing on specifically the identified components and content specified.

1. Project Charter—Discuss Business Need, Purpose, Logical Scope: In-Scope, Out-of-Scope, and Assumptions. 2. Master Test Plan—Discuss Sections 1.3—Test Levels, Objectives, and Deliverables; 3—Test Timeline and Key Events; and

5—Define System Characteristics, Relative Importance, and Subsystems. 3. Privacy and Security—Discuss the Security and HIPAA Template For PMO Projects. 4. Risk Forms—Discuss all populated and scored forms created to date. 5. Project Financial Worksheet—Discuss populated spreadsheet. 6. Progress Report (PDR)—Speak to the current status of all actions provided for each deliverable.

Source: Nancy D’Quila, PMP.

310 Part 2 Planning Projects

11-8 Using MS Project for Project Baselines MS Project can be used as a tool to automate and communicate many facets of a project. However, those involved in the project should be sure that they are ready to use it effec- tively. Before a baseline is created with MS Project, the following should be verified:

• Quality assurance and quality control activities are included. • Risk response plan activities (or duration compensation) are included. • Performance posting activities are included. • All “hard” date constraints are incorporated. • A realistic start date is chosen. • Resource overloads are addressed. • Organizational holidays are entered. • Resource vacations are entered. • Resource allocations are realistic. • A management reserve is in the schedule. • A contingency reserve is in the schedule. • Time and cost tradeoffs are applied to the schedule.

11-8a Baseline the Project Plan Microsoft Project supports three sets of activity metrics, each set having five fields. The sets are used for cross-comparison purposes to better understand impacts, such as prog- ress or requested change. The sets and their field names are shown in Exhibit 11.14.

The first column is often referred to as the scheduled values. These values are based on current project information. They are recalculated if an input to MS Project’s calcula- tion algorithm changes. Inputs include estimated duration, work, and cost. Progress information such as actual start, actual finish, actual duration, actual cost, and actual work causes recalculation. Changing information such as resource assignments, con- straints, working time, lead-lag values, and the project start date can also cause a recal- culation of the scheduled values.

MS Project’s baseline is a set of five activity metrics, sometimes called the planned values. The five are the activity baseline start, activity baseline finish, activity baseline duration, activity baseline cost, and activity baseline work. These values, together with project quality and scope targets, are what the stakeholders agreed to, approved, and expect as key measures of project success. Collectively, these values and targets, along with the risk and communications plans, form the project management plan.

The project manager can use MS Project to compare the baseline with actual sched- ule, work, and cost variance values and display these graphically and in tables. This com- parison can be used to predict future impacts to time and cost targets. With this

EXHIBIT 11.14 MS PROJECT ACTIVITY METRICS

CURRENT SCHEDULE (SCHEDULED)

PLANNED SCHEDULE (BASELINE)

WHAT ACTUALLY HAPPENED (ACTUAL)

Duration Baseline duration Actual duration

Start Baseline start Actual start

Finish Baseline finish Actual finish

Work Baseline work Actual work

Cost Baseline cost Actual cost

Chapter 11 Project Quality Planning and Project Kickoff 311

understanding, project managers can take action to reduce or eliminate undesirable future impacts. This is a powerful capability for the project manager.

11-8b First Time Baseline Once key stakeholders agree to the project plan, the baseline is created by:

1. On the Project tab, Schedule group, click Set Baseline, then click Set Baseline… 2. The defaults should be accepted as shown in Exhibit 11.15; click OK.

11-8c Subsequent Baselines For any number of reasons, it may not be useful to continue to manage to the present baseline. Reasons to change the baseline might include changes to the project scope, project delay or restart, unavailability of planned resources, slower cash flow than planned, occurrence of risk events, and quality problems. Remember, any change to the project baseline must be officially designated as an approved change. If a change has been approved, then the changed material must be re-baselined, as well as the WBS par- ents of the new or changed material (step 3 below):

1. Select the changed or added activities, milestones, and WBS elements. 2. On the Project tab, Schedule group, click Set Baseline, then click Set Baseline… 3. Click Selected tasks, then click To all summary tasks. 4. Click OK.

Summary Deming, Juran, and many other people have contrib- uted to the modern approaches to quality. The Mal- colm Baldrige Award, ISO certification, and Six Sigma

each present a framework with many good points. The contemporary approach to project quality draws upon all of these sources.

EXHIBIT 11.15 SET FIRST TIME BASELINE

Source: Microsoft product screen shots reprinted with permission from Microsoft Corporation.

312 Part 2 Planning Projects

The first concept in contemporary project quality management is stakeholder satisfaction. It is critical to understand project stakeholders, prioritize their needs, manage toward those needs, keep the relationships strong, and always strive to help ensure that the customer is capable of using the project deliverables. The second concept is process management. This includes under- standing both continual and breakthrough forms of improvement, seeking the root cause of problems, and using an appropriate model such as DMAIC to guide improvement efforts. The third concept is fact-based management. This entails understanding variation, mak- ing good decisions regarding what to measure, capturing and analyzing data correctly, and using the information in an open and honest decision-making manner. The final concept is empowered performance. Project man- agers want to have capable and willing workers through- out their project and should treat each person as an individual, ensure people accept responsibility, and strive to get more done through collaboration.

When project managers perform quality manage- ment planning, the first thing they need to do is either adopt the quality policy of their parent organization or supplement it. The policy should broadly guide their efforts. The quality plan should include the quality baseline defining performance expectations. It should also include instructions for how the quality assurance and quality control will be handled.

Many quality tools have been developed over the years, and quite a few of them work well on projects. Many of these tools can be used in additional project management activities.

Once the quality management plan and all of the other subsidiary plans have been developed, it is time to iron out any inconsistencies between the vari- ous plans. The overall project management plan needs to make sense. Quality, cost, schedule, human resources, risk, and communications may have been planned somewhat independently on a large project, and now is the time to make sure they all work well together.

The project core team usually asks themselves a number of questions concerning the practicality of the overall plan and then holds a kickoff meeting with all of the project stakeholders. Hopefully, the out- come of the meeting is commitment and excitement all around. Now, the project officially moves into execu- tion. While some of the project activities may already be under way (or even complete), the approval of the project plan signals the change from primarily plan- ning to primarily execution. Ongoing planning and replanning still occur, but managing the performance of project activities and communicating with various stakeholders consume much of the project manager’s time from this point forward.

Key Terms from the PMBOK® Guide plan quality management, 292 process, 297 control, 298 quality metrics, 300 quality management plan, 302 process improvement plan, 305 perform quality assurance, 305

quality audit, 306 process analysis, 306 control quality, 306 preventive actions, 306 corrective actions, 306 defect repair, 306 configuration management system, 308

Chapter Review Questions 1. What is the name of the process that identifies

which quality standards are relevant to the proj- ect and how to comply with them?

2. Who was the influential thought leader in the area of quality who created the Profound Knowledge System?

3. Who is best known for creating the Quality Trilogy?

4. What does the acronym TQM stand for?

5. What does standard deviation indicate? 6. Define the term project quality. 7. Give some examples of external stakeholders. 8. What are the four core project quality concepts? 9. What are three main reasons it is better to design

quality into a process than to find problems upon inspection?

10. Identify and describe the steps of the PDAC model.

Chapter 11 Project Quality Planning and Project Kickoff 313

11. What is the difference between common and special causes of variation?

12. Define quality assurance and the primary meth- ods that can be used to achieve it.

13. Define quality control and the primary methods that can be used to achieve it.

14. What activities are typically included in a project kickoff meeting?

15. What marks the transition between the planning and executing project phases?

Discussion Questions 1. Describe the four parts of W. Deming’s Profound

Knowledge System. 2. Identify similarities and differences among TQM,

ISO, and Six Sigma. What strengths and weak- nesses are inherent in each of these approaches?

3. Discuss the areas of ISO. Which do you feel is most important and why?

4. Describe the process of achieving stakeholder satisfaction. Why is it important to consider stakeholder satisfaction?

5. Give examples of how a single company might use continuous process improvement and/or breakthrough process improvement.

6. Give some examples of common and special cause variation within business practices. Which

of these causes of variation can be addressed through continuous improvement?

7. Discuss the four areas of fact-based decision making.

8. Describe the three outputs of quality control. 9. List the project quality tools you expect to use on

your project. Tell where you plan to use each tool and why it is important.

10. In your own experience, have you seen compa- nies integrate quality within their project plan- ning processes? If so, how and when have they done so? If not, do you think it would have been more beneficial to address quality in one area of the overall project plan or continuously throughout the plan?

Exercises 1. Create a SIPOC for an everyday activity

(i.e., paying bills, parallel parking, or making cookies).

2. Identify key quality project plan steps that you feel should be included within a typical overall project plan. Be sure to include quality items throughout the project plan life cycle.

3. Create a SIPOC model for a project where your university is modernizing its student center to include space for on-campus, student-run busi- nesses. Be sure to include all relevant stakeholder

groups. Describe how you would use this infor- mation to design quality into your project.

4. Improve a work process using either the DMAIC or the PDCA model to guide your actions. What project quality tools did you use, and why did you select each?

5. Identify the quality policy for a local company. Speculate how the policy focuses the efforts on a project in that company. Find a project manager at that company and ask his or her opinion of the quality policy’s impact.

PMBOK® Guide Questions 1. An important input to the Plan Quality Man-

agement process is requirements documentation. This is because: a. the organization will have a uniform set of

specific quality requirements that must be adhered to by every project.

b. requirements include the schedule and cost information that must be balanced against quality needs for the project.

c. requirements documentation captures the stakeholder expectations that should be met by the project.

d. the sponsor’s directives for the project’s level of quality are expressed in the requirements.

2. All of the following are continuous improvement frameworks that are compatible with ISO quality standards except: a. Inspection over Prevention b. Lean Six Sigma

314 Part 2 Planning Projects

c. Six Sigma (DMAIC) d. Total Quality Management (TQM)

3. What cycle is the basis for quality improvement? a. DMAIC b. PDCA c. DOE d. TQM

4. All of these are components of a work flow dia- gram called the SIPOC model except: a. customer b. process c. input d. solution

5. The PMBOK® Guide defines quality as: a. exceeding customer expectations by delivering

more than they requested. b. achieving the highest possible level of quality

using objective measures. c. the degree to which a set of inherent charac-

teristics fulfills requirements. d. a category used to distinguish items that have

the same functional use. 6. During quality management planning, the proj-

ect manager and team determine what will be measured during the Control Quality process. Project or product attributes such as on-time performance, defect frequency, and costs vs. budget are known as . a. quality metrics. b. quality thresholds. c. quality tolerances. d. quality boundaries.

7. Preventive action is defined as . a. changes to formally controlled project documents. b. an intentional activity that realigns the per-

formance of the project work with the project management plan.

c. an intentional activity that ensures the future performance of the project work is aligned with the project management plan.

d. an intentional activity to modify a noncon- forming product or product subcomponent.

8. The process of “auditing the quality requirements and results from quality control measurements to ensure that appropriate quality standards and operational definitions are used” is called: a. Plan Quality Management b. Develop Project Management Plan c. Perform Quality Assurance d. Control Quality

9. Once the project management plan is complete and accepted by the stakeholders, the approved plan is . a. reviewed b. baselined c. followed d. documented

10. Learning from the past and understanding cause- and-effect relationships to predict future behav- ior pertain to which part of Deming’s Profound Knowledge System? a. Systems b. Variation c. Knowledge d. Psychology

Example Project Talk with your sponsor to determine if the organiza- tion for which you are planning your example project has a quality policy. If it does, determine whether you will adopt it as is or ask to augment it. Tell why you wish to either accept or modify it.

With your sponsor, determine the quality baseline for your project. What standards will you use?

Perform a stakeholder analysis. After completing the tool, are there any stakeholders that you didn’t think of before? Are there any who are opponents? What actions could you take to try to change those who are opponents into enthusiasts?

Create a SIPOC for your project. What did you learn that surprised you? How will your project plan be different because of what you learned?

Create an agenda for a kickoff meeting for your project. Conduct the kickoff meeting and capture min- utes for it. Tell what went as you expected and what went differently from what you expected.

Baseline your project management plan with the activity baseline start, activity baseline finish, activity baseline duration, activity baseline cost, and activity baseline work shown in MS Project. Also show in your project management plan the agreed upon quality and scope targets, risk, and communications plans.

Chapter 11 Project Quality Planning and Project Kickoff 315

Pick one work process related to your example proj- ect. Use the DMAIC model to improve the process. Perform the define and measure steps. Tell what you

learned. Identify what project quality tools you expect to use on the remaining steps and tell why you will use them.

References A Guide to the Project Management Body of Knowledge

(PMBOK® Guide), 5th ed. (Newtown Square, PA: Project Management Institute, 2013).

Baldrige National Quality Program, “Criteria for Per- formance Excellence,” http://www.nist.gov/baldrige/ publications/upload/2011_2012_Business_Nonpro fit_Criteria.pdf, accessed June 10, 2013.

Byrne, Rhonda, The Secret (New York: Attria Books, 2006).

Crawford, Lynn, and Jeanne Dorie, “Quality First,” PM Network 20 (5) (May 2006): 42–47.

Evans, James R., and William M. Lindsay, An Intro- duction to Six Sigma & Process Improvement, 1st ed. (Mason, OH: Thomson South-Western, 2005).

Evans, James R., and William M. Lindsay, The Man- agement and Control of Quality, 8th ed. (Mason, OH: Cengage Learning South-Western, 2011).

International Organization for Standardization, “Qual- ity Management Principles,” http://www.iso.org/iso/ iso_9000, accessed May 3, 2013.

Juran, Joseph M., A History of Managing for Quality: The Evolution, Trends, and Future Directions of Managing for Quality (Madison, WI: ASQC Quality Press, 1995).

Kloppenborg, Timothy J., and Joseph A. Petrick, Managing Project Quality (Vienna, VA: Manage- ment Concepts, Inc., 2002).

Kwak, Young Hoon, John J. Wetter, and Frank T. Anbari, “Business Process Best Practices: Project Management or Six Sigma?” Proceedings, PM1 Research Conference 2006: New Directions in Project Management (Montreal, Canada, 2006).

Milosevic, Dragan Z., Project Management Toolbox: Tools and Techniques for the Practicing Project Manager (Hoboken, NJ: John Wiley & Sons, 2003).

Neuendorf, Steve, Six Sigma for Project Managers (Vienna, VA: Management Concepts, Inc., 2004).

PMI Code of Ethics and Professional Responsibility, http://www.pmi.org/About-Us/Ethics/~/media/ PDF/Ethics/ap_pmicodeofethics.ashx, accessed May 3, 2013.

Rose, Kenneth H., Project Quality Management: Why, What and How (Boca Raton, FL: Ross Publishing, Inc., 2005).

Shiba, Shoji, and David Walden, Breakthrough Man- agement (New Delhi, India: Confederation of Indian Industry, 2006).

Stevens, James D., Timothy J. Kloppenborg, and Charles R Glagola,Quality Performance Measure- ments of the EPC Process: The Blueprint (Austin, TX: Construction Industry Institute, 1994).

Svensson, Richard Berntsson, et al. “Quality Requir- ments in Industrial Practice—An Extended Inter- view Study at Eleven Companies,” IEEE Transactions on Software Engineering 38 (4) (July– August 2012): 923–936.

Swanson, Sandra A. “Winning Pair: Integrating Six Sigma and PMBOK® Guide at an Organizational Level,” PMNetowrk 25 (7) July 2011: 54–58.

Wagner, Rodd, and James K. Harter, 12: The Elements of Great Managing (New York: Gallup Press, 2006).

Zhang, Weiyong, and Xiaobo Xu, “Six Sigma and In- formation Systems Project Management: A Revised Theoretical Model,” Project Management Journal 39 (3) (2008): 59–74.

“ISO 9001 2008 Translated into Plain English,” http:// www.praxiom.com/iso-9001.htm, accessed May 3, 2013.

“ISO 9000 Quality Management,” http://www.iso.org/ iso/home/standards/management-standards/ iso_9000.htm, accessed May 3, 2013.

http://www.pma.doit.wisc.edu/plan/3-2/print.html, accessed May 3, 2013.

Endnotes 1. PMBOK® Guide 550. 2. PMBOK® Guide 556. 3. PMBOK® Guide 551. 4. PMBOK® Guide 533.

5. PMBOK® Guide 557. 6. James R. Evans and William M. Lindsay, The Man-

agement and Control of Quality, 8th ed. (Mason, OH: Thomson South-Western, 2011): 364.

316 Part 2 Planning Projects

7. Ibid. 8. PMBOK® Guide 557. 9. Adapted from, http://www.pma.doit.wisc.edu/plan/

3-2/what.html accessed May 2, 2013. 10. PMBOK® Guide 552. 11. PMBOK® Guide 549. 12. PMBOK® Guide 556.

13. PMBOK® Guide 552. 14. PMBOK® Guide 534. 15. PMBOK® Guide 551. 16. PMBOK® Guide 534. 17. PMBOK® Guide 536. 18. PMBOK® Guide 532.

PROJECT MANAGEMENT I N ACT I ON

Quality Planning at GTC

Every customer-facing project performed by General Tool Company (GTC) has an associated Quality Plan Requirements (QPR) document. The QPR is an output of the technical review process and is performed by the Quality Engineer (QE) during the preliminary planning stages of the project. The QPR is derived from various source documents, including the Purchase Order Agreement, Statement of Work, technical publications, customer flow-down requirements, and drawing notes. Familiarity with the customer’s quality system requirements is an essential element of the review process. It is not uncommon for a customer to mistakenly leave out critical quality requirements when issuing a purchase order or request-for-proposal. However, by being familiar with the customer’s quality systems and manufacturing needs, GTC is able to work with the customer to correct any deficiencies prior to beginning the manufacturing process.

Through the QPR process, the QE may (and often does) uncover project risks previously unknown to the team. Such risks may impact cost, schedule, scope, or any combination thereof. At a minimum, identified risk

must be investigated by the project manager so as to ensure there are no changes to the scope of work, as originally proposed. While many tools exists to identify and address quality related risks (DMIAC, Ishikawa Diagram, 5 Whys, etc.), GTC utilizes the Quality Improvement Action Plan for planning and in-process management of project risks.

Of course, not all risks are uncovered during the planning phase. Unsuspecting performance issues can arise at any point during the project’s lifecycle, and must be dealt with appropriately to ensure cost, schedule, and performance objectives are met. In the example on the following pages, GTC identified, by way of the supplier scorecard in Exhibit 11.16, delivery issues associated with a particular aerospace project. The scorecard led the project team down the continuous improvement path, in an effort to bolster the supplier rating. The relationship between the supplier scorecard and the Quality Improvement Action Plan is clearly indicated (as well as the marked improvement in the subsequent quarter).

By working closely with the customer and the QE, the project manager ensures that the project’s quality

EXHIBIT 11.16 SUPPLIER SCORECARD

Supplier Rating: Quarter 1, 2, 3 & 4 of 2012

General Tool Company

Suppliers will be categorized into one of four tiers; A, B, C or D. A) An A tier supplier has a rating of 85—100. B) A B tier supplier has a rating of 75—84. C) A C tier supplier has a rating of 65—74. D) A D tier supplier has a rating of 64 or less.

Below are the charts and graphs that represent GTC’s performance in the last 4 quarters.

Chapter 11 Project Quality Planning and Project Kickoff 317

and technical requirements are properly identified and integrated into the project plan. In addition, the QPR process provides an opportunity to validate the team’s underlying assumptions from the bid process. Any incongruences can be addressed before the manufacturing process begins, thus giving the project the best opportunity for a successful outcome. Further, it is often during the quality planning process that the

customer comes to realize the significant costs associated with heightened quality and technical requirements. In a firm-fixed-price environment, this is the best time for the subcontractor to negotiate any associated cost impact, as the risk is squarely on the shoulders of the subcontractor once the purchase order agreement is accepted.

Overall Rating: A Tier.

On Time Delivery: Delivery issues due to Quality misses in 3rd Quarter. Process improvements have restored highest rating.

Quality List of defects: Cert accuracy—missing information/incomplete documents delayed product receipt. Machining failure caused decrease in 3rd Quarter Quality rating. GTC implemented Corrective Actions. Reference GTC Quality Action Plans.

Source: Brad Brezinski, Jim Stewart, Korey Bischoff, and Mark Butorac of General Tool Corporation.

0

10

20

30

40

50

60

70

80

90

100

On Time Deliver Quality System Product Quality Overall Rating

GTC 1Q12

GTC 2Q12

GTC 3Q12

GTC 4Q12

318 Part 2 Planning Projects

PART3 PERFORMING PROJECTS organize / plan / perform

Chapter 12 Project Supply Chain Management

Chapter 13 Leading and Managing Project Teams

Chapter 14 Determining Project Progress and Results

Chapter 15 Finishing the Project and Realizing the Benefits

319

CHA P T E R 12 Project Supply ChainManagement

This story was born when I encountered a challenge on another project. The solution to the previous project became a significant independent project called Super Absorbent Polymer Turf (SAPTURF). The problem is synthetic turf systems generate extreme heat of 50 to 60 degrees above the ambient temperature on the surface, which is unpleasant and even dangerous.

I chose a large multinational based in Europe to partner with on the next step in commercializing SAPTURF. The firm uses a major American university as their contract research department. I also set up trials at the University of Cincinnati to provide a control.

I chose this international partner to work with due to the fact that they are the market leaders. I still control the intellectual property (IP) and have entered into an agreement to further test my technology to calibrate the value. I feel the trials will drive great value and at the same time shift product development costs to my partner. At the end of the trial a license agreement will be executed with the appropriate values assigned to up-front

© Fu se /J up ite rIm

ag es

CHAPTER OBJECT I V ES

After completing this chapter, you should be able to:

• Identify the role of supply chain management in project management and its importance for ensuring project success.

• Describe how to plan, conduct, control, and close project procurements.

• Describe the various formats for supply contracts and when each type is appropriate.

• Explain how to utilize the contemporary approach to project partnering and collaboration.

320

Topics:

• Plan procurement management

• Conduct procurements

• Control procurements

payment, annual minimums, and royalties. This license may be with any firm; the only contractual provision is that my commercialization partner gets the opportunity to match any offer.

The SAPTURF project required a strong team. Successful commercialization of IP is a long shot, so room for project management error is slim. I realized I would need to compensate for lack of in-house resources. Lack of in-house resources is an advantage! I was free to look for the best resources including the following:

• Need 1—Significant and skilled legal resources were crucial. Few entre- preneurs can afford to have top legal talent in house.

SAPTURF project solution—Talented and accomplished corporate lawyer John Gierl of Katz, Teller, Brant, and Hild was invited to join the SAPTURF team and be compensated on a percentage-of-yield basis.

• Need 2—Technical validation was very important. The potential end users are busy people who need to evaluate the product’s credibility.

SAPTURF team solution—Well-known polymer scientist Dr. Ray Berard, who owns 30-plus patents and has been recognized for his work with Titleist golf balls and as chief technical officer of Interface Founda- tion also joined the team on a percentage basis.

• Need 3—Small enterprises can hardly afford the technical capability and physical plant required to do R&D and prototyping.

SAPTURF team solution—We identified a capable resource that has a product that can be a component of our finished product. A division of German giant BASF was invited to join the team, and their top technical and sales personnel have been involved in the project on a daily basis.

• Need 4—There existed a critical need for an organized system of com- munication and documentation with a team of independent players.

SAPTURF team solution—I chose to use a hosted project manage- ment tool, Basecamp, to provide the collaborative communication tool for the SAPTURF project. It has the essential functionality and user- friendliness required, and can be used in conjunction with more sophis- ticated project management tools when necessary.

Chris Tetrault, owner and founder, SAPTURF

PMBOK® Guide

Phase: Selecting

Approval: CharterSelection Kickoff Project BenefitsAdministrative Closure

Planning Executing Closing RealizingInitiating

RealizedResultTo Proceed

321

The transition from project planning into project execution is not straightforward. The most visible portion of the transition occurs when the project stakeholders accept the project plan and a project kickoff is conducted. However, a certain amount of project execution often takes place prior to the formal kickoff, and most projects require addi- tional planning. In this text, we use the topic of supply chain management (SCM) to help transition into execution because planning and execution topics under the umbrella of project supply chain management are most easily understood if covered together.

12-1 Introduction to Project Supply Chain Management

As the opening case illustrates, almost no serious projects are completed from scratch by in-house personnel anymore. At the beginning of this chapter, let’s first ask a trivial question: Can you provide a project example that is fully completed by the project orga- nization itself, without using any products or services from outside suppliers? Most likely the answer is no. In fact, outsourcing part of project tasks has been a well-established practice in various industries for a long time. In many cases, companies have to rely on external suppliers for acquiring many of the unique resources they need. In this chapter, we consider the inter-organizational purchasing-related issues (hereafter referred to as supply chain management) in the context of project management.

A supply chain consists of all parties involved, directly or indirectly, in fulfilling a cus- tomer request. In project management, this request can be made by the project team in order to acquire some specific product or service required for completing various stages of the project. The request also can be made by the customer whom the project team serves. As a result, supply chain operations require managerial processes that span func- tional areas within individual organizations and link trading partners and customers across organizational boundaries. In recent years, the topic of supply chain management has evolved into a systematic approach for managing all material and information flows across supply chain partners. With its broader coverage and profound impact, project sup- ply chain management has become a challenge to many firms. Because the ultimate goal of serving project customers hinges on the systematic performance of partners (including suppliers, transporters, etc.), supply chain management becomes a critical project manage- ment activity. However, many companies normally have been concerned with purchasing and procurement, where the goal was to obtain necessary goods and services at the lowest possible price. In this chapter, we cover not only traditional procurement and contractual management topics, but also supplier partnership and collaboration issues.

In this chapter, we define project supply chain management as a system approach to managing the entire flows of physical products, information, and funds from suppliers and producers, through resellers, and finally the project organization for creating cus- tomer satisfaction. A sample project supply chain is shown in Exhibit 12.1.

EXHIBIT 12.1 A PROJECT SUPPLY CHAIN VIEW

Supplier’s Supplier Supplier Project Team Customer Consumer

322 Part 3 Performing Projects

The traditional purchasing perspective is only concerned with the relationship between the project team and its supplier(s)—those who supply the project organization directly. At its most extensive, supply chain management involves strategic and opera- tional issues concerned with all organizational partners involved in projects. Doubtless, all supply chain parties need to work together to complete the project faster, better, and/or cheaper. They all need to remember the tradeoffs determined by the key project stakeholders for better achieving project outcomes.

In traditional project procurement management literature, purchasing, supply manage- ment, and procurement are usually used interchangeably to refer to the integration of related functions to purchase or acquire the needed materials and services for the project team. Thus, procurement management is not only concerned with the standard steps in the purchasing process such as recognizing needs, translating needs into commercially equivalent descriptions, and searching for suppliers. Further responsibilities of a project supply chain may also include receiving, inspection, storage, inbound and outbound transportation, and disposal. Project procurement management can also be extended to cover various stages of the supply chain for providing the necessary goods or services (e.g., the supplier’s supplier). Though supply chain management (SCM) and project management (PM) are traditionally separate business areas, we find that integrating SCM into PM can significantly enhance the effectiveness of project management.

12-1a SCM Components In particular, this chapter focuses on the following project supply chain management components:

• Make-or-buy decisions—which are “decisions made regarding the external purchase or internal manufacture of a product.”1

• Contract types—We introduce the contact types and compare their advantages and disadvantages in case a buy decision is warranted.

• Collaboration and cooperation—As different firms take care of their own interests, it is essential to coordinate their project activities to ensure the deliverables are pro- duced as scheduled.

• System integration—concerning the tradeoffs among project goals such as time, cost, and quality.

12-1b SCM Factors Generally, supply chain management is more important to projects where a large portion of the work is being subcontracted and more company collaboration is needed. Other factors include the following:

• The value of the outsourced products or services relative to the total value of the project

• The timing of the work being purchased • The capability of the project team • The role of the outsourced work in the entire project • The number of suppliers required • The structure of the procurement supply cha