Project Management Metrics, KPIs, and Dashboards E-Book

Harold Kerzner

• Herausgeber: John Wiley & Sons
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 653

Veröffentlichungsjahr: 2023

Beschreibung

Project Management Metrics, KPIs,and Dashboards

Enables readers to easily understand and implement essential strategies on measuring project management performance

Project Management Metrics, KPIs, and Dashboards provides complete coverage of what metrics and KPIs are and how to use them effectively, offering comprehensive coverage of the different dashboard types, design issues, and applications that ­readers may come across during practical application of the concepts. To aid in seamless reader comprehension, the work includes full-color dashboards from some of the most successful project management companies. As a modern resource, the work aligns with PMI’s PMBOK^® Guide and stresses value-driven project management.

Written by the leading authority in the field, sample topics covered in the work are as follows:

• Stakeholder relations management, effective metric measurements, selecting the right project metrics, innovation metrics, and how to become and stay agile
• Comparing traditional and nontraditional projects, defining complexity, decision making, fluid methodologies, global project management, and project management methodologies/frameworks
• Customer relations management, a new look at defining project success, and why customer satisfaction must always be considered
• Scope creep, scope creep dependencies, causes of scope creep, the business side of scope creep, and ways to minimize scope creep

For project managers across all industries, Project Management Metrics, KPIs, and Dashboards is a valuable resource on the subject that will bolster your awareness of what good metrics management really entails and arm you with the important knowledge needed to measure and communicate performance more effectively.

Leseprobe

PROJECT MANAGEMENT METRICS, KPIs, AND DASHBOARDS

A Guide to Measuring and Monitoring Project Performance

Fourth Edition

Harold Kerzner, PhD

Sr. Executive Director for Project Management, The International Institute for Learning

This book is printed on acid-free paper.

Copyright © 2023 by John Wiley & Sons, Inc. All rights reserved

Published by John Wiley & Sons, Inc., Hoboken, New Jersey

Published simultaneously in Canada

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone], or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty:

While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with the respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for damages arising herefrom.

For general information about our other products and services, please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.

Library of Congress Cataloging-in-Publication Data:

Names: Kerzner, Harold, author. Title: Project management metrics, KPIs, and dashboards : a guide to measuring and monitoring project performance / Harold Kerzner, Ph.D., Sr. Executive Director for Project Management The International Institute for Learning. Description: Fourth Edition. | Hoboken, New Jersey : John Wiley & Sons, [2023] | Revised edition of the author’s Project management metrics, KPIs, and dashboards, [2017] | Includes bibliographical references and index. Identifiers: LCCN 2021062269 (print) | LCCN 2021062270 (ebook) | ISBN 9781119851554 (paperback) | ISBN 9781119851578 (pdf) | ISBN 9781119851561 (epub) | ISBN 9781119851592 (obook) Subjects: LCSH: Project management. | Project management–Quality control. | Performance standards. | Work measurement. Classification: LCC HD69.P75 K492 2022 (print) | LCC HD69.P75 (ebook) | DDC 658.4/04–dc23/eng/20220131 LC record available at https://lccn.loc.gov/2021062269LC ebook record available at https://lccn.loc.gov/2021062270

Cover image: Screenshots © Dundas Data Visualization, Inc. Desktop Computer SC2D40 © Cover Action Pro 3.

Cover design: Wiley

Set in 10/12pt ITC Giovanni Std by Integra Software Services Pvt. Ltd, Pondicherry, India

Contents

Cover

Title page

Copyright

PREFACE

ABOUT THE COMPANION WEBSITE

1 THE CHANGING LANDSCAPE OF PROJECT MANAGEMENT

CHAPTER OVERVIEW

1.0 INTRODUCTION

1.1 EXECUTIVE VIEW OF PROJECT MANAGEMENT

1.2 COMPLEX PROJECTS

Comparing Traditional and Nontraditional Projects

Defining Complexity

Trade-offs

Skill Set

Governance

Decision Making

Fluid Methodologies

1.3 GLOBAL PROJECT MANAGEMENT

1.4 PROJECT MANAGEMENT METHODOLOGIES AND FRAMEWORKS

Light Methodologies

Heavy Methodologies

Frameworks

1.5 THE NEED FOR EFFECTIVE GOVERNANCE

1.6 ENGAGEMENT PROJECT MANAGEMENT

1.7 CUSTOMER RELATIONS MANAGEMENT

1.8 OTHER DEVELOPMENTS IN PROJECT MANAGEMENT

1.9 A NEW LOOK AT DEFINING PROJECT SUCCESS

Success Is Measured by the Triple Constraints

Customer Satisfaction Must Be Considered as Well

Other (or Secondary) Factors Must Be Considered as Well

Success Must Include a Business Component

Prioritization of Success Constraints May Be Necessary

The Definition of Success Must Include a “Value” Component

Multiple Components for Success

The Future

1.10 THE GROWTH OF PAPERLESS PROJECT MANAGEMENT

1.11 PROJECT MANAGEMENT MATURITY AND METRICS

1.12 PROJECT MANAGEMENT BENCHMARKING AND METRICS

Best Practice versus Proven Practice

Benchmarking Methodologies

Benchmarking Costs

Types of Benchmarking

Benchmarking Code of Conduct

Benchmarking Mistakes

Points to Remember

1.13 CONCLUSIONS

2 THE DRIVING FORCES FOR BETTER METRICS

CHAPTER OVERVIEW

2.0 INTRODUCTION

2.1 STAKEHOLDER RELATIONS MANAGEMENT

2.2 PROJECT AUDITS AND THE PMO

2.3 INTRODUCTION TO SCOPE CREEP

Defining Scope Creep

Scope Creep Dependencies

Causes of Scope Creep

Need for Business Knowledge

Business Side of Scope Creep

Ways to Minimize Scope Creep

2.4 PROJECT HEALTH CHECKS

Understanding Project Health Checks

Who Performs the Health Check?

Life Cycle Phases

2.5 MANAGING DISTRESSED PROJECTS

Root Causes of Failure

Definition of Failure

Early Warning Signs of Trouble

Selecting the Recovery Project Manager

Recovery Life Cycle Phases

3 METRICS

CHAPTER OVERVIEW

3.0 INTRODUCTION

3.1 PROJECT MANAGEMENT METRICS: THE EARLY YEARS

The Project

Timeline

3.2 PROJECT MANAGEMENT METRICS: CURRENT VIEW

Metrics and Small Companies

3.3 METRICS MANAGEMENT MYTHS

3.4 SELLING EXECUTIVES ON A METRICS MANAGEMENT PROGRAM

3.5 UNDERSTANDING METRICS

3.6 CAUSES FOR LACK OF SUPPORT FOR METRICS MANAGEMENT

3.7 USING METRICS IN EMPLOYEE PERFORMANCE REVIEWS

3.8 CHARACTERISTICS OF A METRIC

3.9 METRIC CATEGORIES AND TYPES

3.10 SELECTING THE METRICS

3.11 SELECTING A METRIC/KPI OWNER

3.12 METRICS AND INFORMATION SYSTEMS

3.13 CRITICAL SUCCESS FACTORS

3.14 METRICS AND THE PMO

3.15 METRICS AND PROJECT OVERSIGHT/GOVERNANCE

3.16 METRICS TRAPS

3.17 PROMOTING THE METRICS

3.18 CHURCHILL DOWNS INCORPORATED’S PROJECT PERFORMANCE MEASUREMENT APPROACHES

Toll Gates (Project Management—Related Progress and Performance Reporting)

Quad Sections

4 KEY PERFORMANCE INDICATORS

CHAPTER OVERVIEW

4.0 INTRODUCTION

4.1 THE NEED FOR KPIS

4.2 USING THE KPIS

4.3 THE ANATOMY OF A KPI

4.4 KPI CHARACTERISTICS

Accountability

Empowered

Timely

Trigger Points

Easy to Understand

Accurate

Relevant

4.5 CATEGORIES OF KPIS

4.6 KPI SELECTION

4.7 KPI MEASUREMENT

4.8 KPI INTERDEPENDENCIES

4.9 KPIS AND TRAINING

4.10 KPI TARGETS

4.11 UNDERSTANDING STRETCH TARGETS

4.12 KPI FAILURES

4.13 KPIS AND INTELLECTUAL CAPITAL

4.14 KPI BAD HABITS

KPI Bad Habits Causing Your Performance Measurement Struggles

4.15 BRIGHTPOINT CONSULTING, INC.—DASHBOARD DESIGN: KEY PERFORMANCE INDICATORS AND METRICS

Introduction

Metrics and Key Performance Indicators

Scorecards, Dashboards, and Reports

Gathering KPI and Metric Requirements for a Dashboard

Interviewing Business Users

Putting It All Together—the KPI Wheel

Start Anywhere, but Go Everywhere

Wheels Generate Other Wheels

A Word about Gathering Requirements and Business Users

Wrapping It All Up

5 VALUE-BASED PROJECT MANAGEMENT METRICS

CHAPTER OVERVIEW

5.0 INTRODUCTION

5.1 VALUE OVER THE YEARS

5.2 VALUES AND LEADERSHIP

Project Manager

Team Members

Organization

Stakeholders

5.3 COMBINING SUCCESS AND VALUE

Internal Success

Financial Success

Future Success

Customer-related Success

5.4 RECOGNIZING THE NEED FOR VALUE METRICS

5.5 THE NEED FOR EFFECTIVE MEASUREMENT TECHNIQUES

5.6 CUSTOMER/STAKEHOLDER IMPACT ON VALUE METRICS

5.7 CUSTOMER VALUE MANAGEMENT

5.8 THE RELATIONSHIP BETWEEN PROJECT MANAGEMENT AND VALUE

5.9 BACKGROUND OF METRICS

Redefining Success

Growth in the Use of Metrics

5.10 SELECTING THE RIGHT METRICS

5.11 THE FAILURE OF TRADITIONAL METRICS AND KPIS

5.12 THE NEED FOR VALUE METRICS

5.13 CREATING A VALUE METRIC

5.14 PRESENTING THE VALUE METRIC IN A DASHBOARD

5.15 INDUSTRY EXAMPLES OF VALUE METRICS

Aerospace and Defense: Company 1

Aerospace and Defense: Company 2

Capital Projects: Company 2

IT Consulting (External Clients): Company 1 (No Percentages Provided)

IT Consulting (External Clients): Company 2

IT Consulting (External Clients): Company 3

IT Consulting (External Clients): Company 4

IT Consulting (External Clients): Company 5

IT Consulting (External Clients): Company 6

IT Consulting (Internal): Company 1

Software Development: (Internal) (No Percentages Provided)

Telecommunications: Company 1

Telecommunications: Company 2 (No Percentages Provided)

New Product Development

Automotive Suppliers

Global Consulting: Company 1 (Not Industry Specific and No Weights)

Global Consulting: Company 2 (Not Industry specific and No Weights)

5.16 USE OF CRISIS DASHBOARDS FOR OUT-OFRANGE VALUE ATTRIBUTES

5.17 ESTABLISHING A METRICS MANAGEMENT PROGRAM

5.18 USING VALUE METRICS FOR FORECASTING

5.19 METRICS AND JOB DESCRIPTIONS

5.20 GRAPHICAL REPRESENTATION OF METRICS

5.21 CREATING A PROJECT VALUE BASELINE

The Performance Measurement Baseline

Project Value Management

The Value Management Baseline

Selecting the Value Baseline Attributes

Overachievement Trends

Risks of Overachievement

6 DASHBOARDS

CHAPTER OVERVIEW

6.0 INTRODUCTION

6.1 DOES EVERYONE KNOW WHAT A DASHBOARD REALLY IS?

Dashboards

Dashboard Design

Guided Analysis

Data Exploration

More

Not a Dashboard

Conclusion

6.2 HOW WE PROCESS DASHBOARD INFORMATION

6.3 DASHBOARD CORE ATTRIBUTES

6.4 THE MEANING OF INFORMATION

6.5 TRAFFIC LIGHT DASHBOARD REPORTING

6.6 DASHBOARDS AND SCORECARDS

Dashboards

Scorecards

Summary

6.7 CREATING A DASHBOARD IS A LOT LIKE ONLINE DATING

Finding Out the Needs of the Stakeholders

Making a Connection

Choosing Your Key Performance Indicators

Selecting Your Visuals

Building on the Momentum

Maintenance

6.8 BENEFITS OF DASHBOARDS

6.9 IS YOUR BI TOOL FLEXIBLE ENOUGH?

A Flexible BI Tool—What Does It Mean and Why Does It Matter?

Why Is Flexibility So Important?

Stay up to Speed with Your Changing Business Needs

Be Independent (with Fewer Tools and Users Involved to Get Your Job Done)

Adapt to Each and Every User

Be Ready for the Unknown

6.10 FOUR EASY STEPS TO IMPLEMENTING A SUCCESSFUL BUSINESS INTELLIGENCE SOLUTION

Step 1: Understand the Business Needs

Step 2: Keep It SMART

Step 3: Determine Your Deliverables

Step 4: To the Drawing Board

Closing Comments

6.11 RULES FOR DASHBOARDS

6.12 THE SEVEN DEADLY SINS OF DASHBOARD DESIGN AND WHY THEY SHOULD BE AVOIDED

Deadly Sin #1: Off the Page, Out of Mind

Deadly Sin #2: And This Means … What?

Deadly Sin #3: Right Data, Wrong Chart

Deadly Sin #4: Not Making the Right Arrangements

Deadly Sin #5: A Lack of Emphasis

Deadly Sin #6: Debilitating Detail

Deadly Sin #7: Not Crunching the Numbers

6.13 BRIGHTPOINT CONSULTING, INC.: DESIGNING EXECUTIVE DASHBOARDS

Introduction

Dashboard Design Goals

Defining Key Performance Indicators

Defining Supporting Analytics

Choosing the Correct KPI Visualization Components

Supporting Analytics

A Word about Labeling Your Charts and Graphs

Putting It All Together: Using Size, Contrast, and Position

Validating Your Design

6.14 ALL THAT GLITTERS IS NOT GOLD

6.15 USING EMOTICONS

6.16 MISLEADING INDICATORS

6.17 AGILE AND SCRUM METRICS

Introduction: Agile Overview

Agile Metrics

General Agile Metrics

Scrum Metrics

Other Sprint Charts

Iteration Metrics

Scaled Agile Metrics

Lean Kanban Metrics

Summary

6.18 DATA WAREHOUSES

The Growth of Business Intelligence Systems

Big Data

6.19 DASHBOARD DESIGN TIPS

Colors

Fonts and Font Size

Use Screen Real Estate

Component Placement

6.20 TEAMQUEST CORPORATION

White Paper #1: Metric Dashboard Design

White Paper #2: Proactive Metrics Management

The Future

Conclusion

6.21 A SIMPLE TEMPLATE

6.22 SUMMARY OF DASHBOARD DESIGN REQUIREMENTS

The Importance of Design to Information Dashboards

The Rules for Color Usage on Your Dashboard

The Rules for Graphic Design of Your Dashboard

The Rules for Placing the Dashboard in Front of Your Users—The Key to User Adoption

The Rules for Accuracy of Information on Your Dashboard

6.23 DASHBOARD LIMITATIONS

6.24 THE DASHBOARD PILOT RUN

6.25 EVALUATING DASHBOARD VENDORS

6.26 NEW DASHBOARD APPLICATIONS

7 DASHBOARD APPLICATIONS

CHAPTER OVERVIEW

7.0 INTRODUCTION

7.1 DASHBOARDS IN ACTION: DUNDAS DATA VISUALIZATION

7.2 DASHBOARDS IN ACTION: PIE

7.3 PIE OVERVIEW

Pie Dashboard

Pie Portfolio Timeline

Pie Project Timeline

Pie People Timeline (Resource Planning)

Pie Project List

Pie on My Plate

Pie Recipes—Flexible Frameworks

7.4 DASHBOARDS IN ACTION: INTERNATIONAL INSTITUTE FOR LEARNING

8 THE PORTFOLIO MANAGEMENT PMO AND METRICS

CHAPTER OVERVIEW

8.0 INTRODUCTION

8.1 CRITICAL QUESTIONS

8.2 VALUE CATEGORIES

8.3 PORTFOLIO METRICS

8.4 MEASUREMENT TECHNIQUES AND METRICS

8.5 THE GROWTH OF PORTFOLIO METRICS

8.6 METRICS FOR MEASURING INTANGIBLES

8.7 THE NEED FOR STRATEGIC METRICS

8.8 CRISIS DASHBOARDS

Defining a Crisis

INDEX

End User License Agreement

List of Tables

CHAPTER 01

TABLE 1.1 EXECUTIVE VIEW...

TABLE 1.2 TRADITIONAL VERSUS...

TABLE 1.3 SUMMARIZED DIFFERENCES...

TABLE 1.4 NONGLOBAL VERSUS...

TABLE 1.5 BEFORE AND...

TABLE 1.6 ENGAGEMENT MANAGER...

TABLE 1.7 COMPETITIVE ADVANTAGES...

CHAPTER 02

TABLE 2.1 CHANGING VIEWS...

TABLE 2.2 AUDITS VERSUS...

CHAPTER 03

TABLE 3.1 BUSINESS VERSUS...

CHAPTER 04

TABLE 4.1 TWELVE CHARACTERISTICS...

TABLE 4.2 CONVERTING A...

TABLE 4.3 POSSIBLE VIEWERS...

TABLE 4.4 TRACKING METRICS...

CHAPTER 05

TABLE 5.1 APPLICATION OF...

TABLE 5.2 CHANGING VALUES...

TABLE 5.3 MEASURING VALUE...

TABLE 5.4 TYPICAL FINANCIAL...

TABLE 5.5 PROBLEMS WITH...

TABLE 5.6 BEFORE AND...

TABLE 5.7 BUSINESS VERSUS...

TABLE 5.8 THE CORE...

TABLE 5.9 AUDIENCES FOR...

TABLE 5.10 SELECTING THE...

TABLE 5.11 VALUE METRIC...

TABLE 5.12 VALUE METRIC...

TABLE 5.13 A VALUE...

TABLE 5.14 CHANGING THE...

TABLE 5.15 WEIGHTING FACTOR...

TABLE 5.16 WEIGHTING FACTORS...

TABLE 5.17 A COMPARISON...

TABLE 5.18 PLACING METRICS...

TABLE 5.19 INTERPRETATION OF...

CHAPTER 06

TABLE 6.1 METRICS AND...

TABLE 6.2 COMPARING FEATURES...

TABLE 6.3 COMPARISON OF...

TABLE 6.4 THREE TYPES...

TABLE 6.5 USER QUESTIONS...

TABLE 6.6 COMMON USER...

TABLE 6.7 KPI TEMPLATE...

TABLE 6.8 POTENTIAL COST...

CHAPTER 08

TABLE 8.1 TYPICAL CATEGORIES...

TABLE 8.2 METRICS FOR...

TABLE 8.3 DIFFERENTIATING BETWEEN...

List of Illustrations

CHAPTER 01

Figure 1.1 Generic Methodology

Figure 1.2 “Engagement” Project...

Figure 1.3 New Developments in Project Management

Figure 1.4 From Triple to Competing Constraints

Figure 1.5 Growth of Information...

Figure 1.6 Growth of Information...

Figure 1.7 Project Management Maturity and Metrics

Figure 1.8 Project Management Competitiveness

Figure 1.9 Metric risks to...

Figure 1.10 Nonsustainable Competitive Advantages

Figure 1.11 Sustainable Competitive Advantages

CHAPTER 02

Figure 2.2 Stakeholder Mapping

Figure 2.3 Project Boundaries

Figure 2.4 Recovery Life Cycle Phases

Figure 2.1 Stakeholder Relations Management

Figure 2.5 Changes in Relative Importance

CHAPTER 03

Figure 3.1 Determining Project Status

Figure 3.3 Selecting Metrics

Figure 3.4 Metrics Value Spectrum

Figure 3.5 Establishing the Project’s Strategy

Figure 3.6 Postmortem Pyramid

Figure 3.7 Metric Cost versus Value

Figure 3.8 Best-Practices Classification

Figure 3.9 Project Quad

Figure 3.10 Toll Gate Overview

Figure 3.11 Toll Gate 2 Checklist

Figure 3.12 Project Toll Gate Dashboard

CHAPTER 04

Figure 4.1 Typical Stakeholder Classification System

Figure 4.2 Metrics Are Related

Figure 4.3 A Boundary Box for a KPI Target

Figure 4.4 Mahindra Satyam Customer...

Figure 4.5 Setting Stretch Targets

Figure 4.6 Reporting BHAG Progress

Figure 4.8 Project Management Knowledge

Figure 4.7 The PMBOK® Guide and KPIs

Figure 4.9 Components of Intellectual Capital

Figure 4.10 KPI Wheel

CHAPTER 05

Figure 5.1 Project Management Value Conflicts

Figure 5.2 Four Cornerstones of Success

Figure 5.3 Categories of Success Metrics

Figure 5.4 Shortcomings

Figure 5.5 Quantitative versus Qualitative Assessment

Figure 5.6 Boundary Box

Figure 5.7 Growth in the Importance of Value

Figure 5.8 Simplified Product Stages of Development

Figure 5.9 Dimensions of Value

Figure 5.10 Core Components of Project Management Value

Figure 5.11 Traditional Triple Constraints

Figure 5.12 Core Project Health Metrics

Figure 5.13 Typical Steps in the Performance Metrics Process

Figure 5.14 Value Metric/KPI Boundary Box

Figure 5.15 Value Points for a Boundary Box

Figure 5.16 Project Value Attributes

Figure 5.17 Planned versus Assigned Labor

Figure 5.18 Pay Grade of the Assigned Resources

Figure 5.19 Hours Worked on...

Figure 5.20 Work Packages Scheduled...

Figure 5.21 Work Packages with a Critical Risk Designation

Figure 5.22 Work Packages Adhering to the Budget

Figure 5.23 Number of Baseline Revisions

Figure 5.24 Number of Scope...

Figure 5.25 Number of Action...

Figure 5.26 Number of Critical Constraints Each Month

Figure 5.27 Number of Critical...

Figure 5.28 Actual versus Promised...

Figure 5.29 Project Complexity Factor

Figure 5.30 Project Complexity Factor...

Figure 5.31 Total Project Manpower

Figure 5.32 Management Reserve

Figure 5.33 Deliverables on Time or Late

Figure 5.34 Deliverables Accepted or Rejected

Figure 5.35 Cumulative Month-End CPI and SPI Data

Figure 5.36 Color-Coded Unfavorable Variances (Monthly)

Figure 5.37 Color-Coded Favorable Variances (Monthly)

Figure 5.38 Estimate at Completion

Figure 5.39 Risks Including Aging

Figure 5.40 Value-based Resource Application Model

Figure 5.41 Value Metric Attributes

CHAPTER 06

Figure 6.1 The Framework for a Typical Dashboard

Figure 6.2 Dashboard Core Attributes

Figure 6.3 Traffic Light Dashboard Indicators

Figure 6.4 Source: ©2021...

Figure 6.5 Typical Bar Chart...

Figure 6.6 Contrasting Colors Source...

Figure 6.7 Positioning of Icons...

Figure 6.8 Area Chart Source...

Figure 6.9 Area Chart, Stacked...

Figure 6.10 Area Chart, 100...

Figure 6.11 Bar Chart, Clustered...

Figure 6.12 Bar Chart, Stacked...

Figure 6.13 Bar Chart, 100...

Figure 6.14 Bubble Chart Source...

Figure 6.15 Column Chart, Clustered...

Figure 6.16 Column Chart, Stacked...

Figure 6.17 Column Chart, 100...

Figure 6.18 Gauges Source: Nils...

Figure 6.19 Icons Source: Nils...

Figure 6.20 Line Chart Source...

Figure 6.21 Line Chart, Stacked...

Figure 6.22 Line Chart, 100...

Figure 6.23 Tiered Stakeholder Identification...

Figure 6.24 Summarized Milestone Reporting...

Figure 6.25 Breakdown of Labor...

Figure 6.26 Causes of Failure...

Figure 6.27 A Square Pie...

Figure 6.28 A Rotated Square...

Figure 6.29 Total Cost Breakdown...

Figure 6.30 Cost Overrun Data...

Figure 6.31 Cumulative Month End...

Figure 6.32 3-D Column...

Figure 6.33 Possible Colors...

Figure 6.35 Column Chart Using...

Figure 6.36 Column Chart Using...

Figure 6.37 Background Colors with...

Figure 6.38 Concentric Circle Charts...

Figure 6.39 Radar Chart

Figure 6.40 Dashboard with Buttons for Drilling

Figure 6.41 EVMS Status Reporting

Figure 6.42 Learning Curve on a Log-Log Plot

Figure 6.43 Pointers on a Vertical Sliding Scale

Figure 6.44 Cyclical Data

Figure 6.45 Heat Map

Figure 6.46 Using Emoticons

Figure 6.47 Other Emoticons that Can Be Misinterpreted

Figure 6.48 Column Chart Showing Favorable Variances

Figure 6.49 Selecting the Right Areas for a Circle

Figure 6.50 Agile Methods and...

Figure 6.51 Benefits of Adopting...

Figure 6.52 Agile Value Delivery

Figure 6.53 Net Promoter Score

Figure 6.54 Epic Progress Chart

Figure 6.55 Epic Progress Report...

Figure 6.56 Feature Description

Figure 6.57 Feature Kanban Board

Figure 6.58 Work Item Aging

Figure 6.59 Impediment Aging

Figure 6.60 Control Chart

Figure 6.61 Escaped Defects

Figure 6.62 Scrum

Figure 6.63 Sprint Burndown Chart

Figure 6.64 Sprint Burnup Chart

Figure 6.65 Team Capacity

Figure 6.66 Team Velocity

Figure 6.67 Impediment Tracking Chart

Figure 6.68 Task by Status

Figure 6.69 Sprint Bugs by Priority

Figure 6.70 Sprint Tracking Chart

Figure 6.71 Commitment Efficiency

Figure 6.73 Iteration Metrics

Figure 6.74 Value Stream Performance

Figure 6.75 Program (Value) Predictability Measure

Figure 6.76 Program Board

Figure 6.77 SAFe Program Predictability

Figure 6.78 Kanban Practices

Figure 6.79 Kanban Board

Figure 6.80 Cumulative Flow Diagram

Figure 6.81 CFD Analysis.

Figure 6.82 Cycle Time

Figure 6.83 Challenges Experienced when...

Figure 6.84 User Displays to...

Figure 6.85 Using Color to...

Figure 6.86 Maintain Consistent Design...

Figure 6.87 Sample Dashboard with...

Figure 6.88 How Parameters Can...

Figure 6.89 Simple Alert Triggered...

Figure 6.90 Sample TeamQuest Metrics...

Figure 6.91 Data-agnostic Metric...

Figure 6.92 Sample Dashboard with...

Figure 6.93 How Parameters Can...

Figure 6.94 Simple Alert Triggered...

Figure 6.95 Rainbow Colors and...

Figure 6.96 Simple Dashboard Icons...

Figure 6.97 At-a-Glance...

Figure 6.98 Multicolor Status Reporting

Figure 6.99 Color-coded Variance Reporting

CHAPTER 07

Figure 7.1 Financial and Nonfinancial...

Figure 7.2 Overview Dashboard

Figure 7.3 Executive Dashboard

Figure 7.4 Project Support Dashboard

Figure 7.5 Business Intelligence Dashboard

Figure 7.6 IT Monitoring Dashboard

Figure 7.7 Wireless Dashboard

Figure 7.8 Hospital Performance Dashboard

Figure 7.9 Business Intelligence Dashboard

Figure 7.10 Insurance Call Center Dashboard

Figure 7.11 Business Intelligence Dashboard

Figure 7.12 Dashboard Charts

Figure 7.13 Dashboard Table

Figure 7.14 Dashboard Issues Log

Figure 7.15 Portfolio Timeline

Figure 7.16 Project Timeline

Figure 7.17 Project Timeline

Figure 7.18 Project List

Figure 7.20 On My Team’s Plate

Figure 7.21 Timesheet

Figure 7.19 Project List—Stack

Figure 7.22 Recipes Source: Reproduced...

Figure 7.23 Impact upon Strategic...

Figure 7.24 Projects within the...

Figure 7.25 Project Origin Source...

Figure 7.26 Project Status within...

Figure 7.27 Projects by Year...

Figure 7.28 Budget for the...

CHAPTER 08

Figure 8.1 Portfolio Value Categories for Projects

Figure 8.2 High-Level Project Portfolio Status

Figure 8.3 Grouping of Projects

Figure 8.4 Metrics Growth

Figure 8.5 Governance Effectiveness

Figure 8.6 Project Scoring Model

Figure 8.7 Project Scoring Model with Points Assigned

Figure 8.8 Matching Projects to...

Figure 8.9 Periodic Benfits and Value Achieved

Guide

Cover

Title page

Copyright

Table of Contents

Preface

About the Companion Website

Begin Reading

INDEX

End User License Agreement

Pages

i

ii

iii

iv

v

vi

vii

viii

ix

x

xi

xii

xiii

xiv

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

PREFACE

The ultimate purpose of metrics and dashboards is not to provide more information but to provide the right information to the right person at the right time, using the correct media and in a cost-effective manner. This is certainly a challenge. As computer technology has grown, so has the ease with which information can be generated and presented to management and stakeholders. Today, everyone seems concerned about information overload. Unfortunately, the real issue is non-information overload. In other words, there are too many useless reports that cannot easily be read and that provide readers with too much information, much of which may have no relevance. This information simply distracts us from the real issues and accurate performance reporting. Furthermore, the growth in metric measurement techniques has encouraged us to measure everything regardless of its value as part of performance reporting.

The purpose of status reporting is to show us what actions the viewer must consider. Insufficient or ineffective metrics prevent us from understanding what decisions really need to be made. In traditional project review meetings, emphasis is placed on a detailed schedule analysis and a lengthy review of the cost baseline versus actual expenditures. The resulting discussion and explanation of the variances are most frequently pure guesswork. Managers who are upset about the questioning by senior management then make adjustments that do not fix the problems but limit the time they will be grilled by senior management at the next review meeting. They then end up taking actions that may be counterproductive to the timely completion of the project, and real issues are hidden.

You cannot correct or improve something that cannot be effectively identified and measured. Without effective metrics, managers will not respond to situations correctly and will end up reinforcing undesirable actions by the project team. Keeping the project team headed in the right direction cannot be done easily without effective identification and measurement of metrics.

When all is said and done, we wonder why we have studies like the Chaos Report, which has shown us that over a period of 20 years only about 30% of the IT projects were completed successfully. We then identify hundreds of causes as to why projects fail but neglect what is now being recognized as perhaps the single most important cause: a failure in metrics management.

Metrics management should be addressed in all of the areas of knowledge in the PMBOK®Guide,1 especially communications management. We are now struggling to find better ways of communicating on projects. This will become increasingly important as companies compete in a global marketplace. Our focus today is on the unique needs of the receiver of the information. The need to make faster and better decisions mandates better information. Human beings can absorb information in a variety of ways. We must address all of these ways in the selection of the metrics and the design of the dashboards that convey this information. Dashboards and data visualization techniques are now part of information warehouses and business intelligence systems.

The three most important words in a stakeholder’s vocabulary are “making informed decisions.” This is usually the intent of effective stakeholder relations management. Unfortunately, this cannot be accomplished without an effective information system based on meaningful and informative metrics and key performance indicators (KPIs).

All too often, we purchase project management software and reluctantly rely on the report generators, charts, and graphs to provide the necessary information, even when we realize that this information either is not sufficient or has limited value. Even those companies that create their own project management methodologies neglect to consider the metrics and KPIs that are needed for effective stakeholder relations management. Informed decisions require effective information. We all seem to understand this, yet it has only been in recent years that we have tried to do something about it.

For decades we believed that the only information that needed to be passed on to the client and the stakeholders was information related to time and cost. Today we realize that the true project status cannot be determined from time and cost alone. Each project may require its own unique metrics and KPIs. The future of project management may very well be metric-driven project management.

Information design has finally come of age. Effective communications is the essence of information design. Today we have many small companies that are specialists in business information design. Larger companies may maintain their own specialist team and call these people graphic designers, information architects, or interaction designers. These people maintain expertise in the visual display of both quantitative and qualitative information necessary for informed decision making.

Traditional communications and information flow has always been based on tables, charts, and indexes that were, it is hoped, organized properly by the designer. Today information or data graphics combines points, lines, charts, symbols, images, words, numbers, shades, and a symphony of colors necessary to convey the right message easily. What we know with certainty is that dashboards and metrics are never an end in themselves. They go through continuous improvement and are constantly updated. In a project management environment, each receiver of information can have different requirements and may request different information during the life cycle of the project.

With this in mind, the book is structured as follows:

Chapters 1 and 2 identify how project management has changed over the last few years and how more pressure is being placed on organizations for effective metrics management.

Chapter 3 provides an understanding of what metrics are and how they can be used.

Chapter 4 discusses key performance indications and explains the difference between metrics and KPIs.

Chapter 5 focuses on the value-driven metrics and value-driven KPIs. Stakeholders are asking for more metrics related to the project’s ultimate value. The identification and measurement of value-driven metrics can be difficult.

Chapter 6 describes how dashboards can be used to present the metrics and KPIs to stakeholders. Examples of dashboards are included together with some rules for dashboard design.

Chapter 7 identifies dashboards that are being used by companies.

Chapter 8 provides various business-related metrics that are currently used by portfolio management project management offices to ensure that the business portfolio is delivering the business value expected.

HAROLD KERZNER, PhDSr. Executive Director for Project ManagementThe International Institute for Learning

Note

1

PMBOK is a registered mark of the Project Management Institute, Inc.

ABOUT THE COMPANION WEBSITE

This book is accompanied by a companion website which includes a number of resources created by author that you will find helpful.

www.wiley.com/go/kerznermetrics4e

This is an Instructor website.

Please note that the resources in instructor website are password protected and can only be accessed by instructors who register with the site.

1 THE CHANGING LANDSCAPE OF PROJECT MANAGEMENT

CHAPTER OVERVIEW

The way project managers managed projects in the past will not suffice for many of the projects being managed now or for the projects of the future. The complexity of these projects will place pressure on organizations to better understand how to identify, select, measure, and report project metrics, especially metrics showing value creation. The future of project management may very well be metric-driven project management. In addition, new approaches to project management, such as those with agile and Scrum, have brought with them new sets of metrics.

CHAPTER OBJECTIVES

To understand how project management has changed

To understand the need for project management metrics

To understand the need for better, more complex project management metrics

KEY WORDS

Certification boards

Complex projects

Engagement project management

Frameworks

Governance

Project management methodologies

Project success

1.0 INTRODUCTION

For more than 50 years, project management has been in use but perhaps not on a worldwide basis. What differentiated companies in the early years was whether they used project management or not, not how well they used it. Today, almost every company uses project management, and the differentiation is whether they are simply good at project management or whether they truly excel at project management. The difference between using project management and being good at it is relatively small, and most companies can become good at project management in a relatively short time, especially if they have executive-level support. A well-organized project management office (PMO) can also accelerate the maturation process. The difference, however, between being good and excelling at project management is quite large. One of the critical differences is that excellence in project management on a continuous basis requires more metrics than just time and cost. The success of a project cannot be determined just from the time and cost metrics, yet many companies persist in the belief that this is possible.

The growth of project management applications to nontraditional projects such as those involving strategic issues, innovation, and long-term business investment opportunities have forced companies to rethink how project management can be better utilized. Companies have come to the realization that they must excel at project management rather than just being good at it. This requires the use of flexible methodologies rather than the one-size-fits-all approach, new tools, specialized metrics, creation of information warehouses, new data visualization programs, and packaging all of this into business intelligence systems.

Companies such as IBM, Microsoft, Siemens, Hewlett-Packard (HP), and Deloitte, to name just a few, have come to the realization that they must excel at project management. Doing this requires additional tools and metrics to support project management. IBM has more than 300,000 employees, more than 70 percent of whom are outside of the United States. This includes some 30,000 project managers. HP has more than 8000 project managers and 3500 PMP® credential holders. HP’s goal is 8000 project managers and 8000 PMP® credential holders. These numbers are now much larger with HP’s acquisition of Electronic Data Systems (EDS).

1.1 EXECUTIVE VIEW OF PROJECT MANAGEMENT

Companies today perform strategic planning for project management and are focusing heavily on the future. Several of the things that these companies are doing will be discussed in this chapter, beginning with senior management’s vision of the future. Years ago, senior management paid lip service to project management, reluctantly supporting it to placate the customers. Today, senior management appears to have recognized the value in using project management effectively and maintains a different view of project management, as shown in Table 1.1.

TABLE 1.1 Executive View of Project Management

OLD VIEW

NEW VIEW

Project management is a career path.

Project management is a strategic or core competency necessary for the growth and survival of the company.

We need our people to receive Project Management Professional certifications.

We need our people to undergo multiple certifications and, at a minimum, to be certified in both project management and corporate business processes.

Project managers will be used for project execution only.

Project managers will participate in strategic planning, the portfolio selection of projects, and capacity-planning activities.

Business strategy and project execution are separate activities.

Part of the project manager’s job is to bridge strategy and execution.

Project managers just make project-based decisions.

Project managers make both project and business decisions.

Project management is no longer regarded as a part-time occupation or even a career path position. It is now viewed as a strategic competency needed for the survival of the firm. Superior project management capability can make the difference between winning and losing a contract.

For more than 30 years, becoming a PMP® credential holder was seen as the light at the end of the tunnel. Today, that has changed. Becoming a PMP® credential holder is the light at the entryway to the tunnel. The light at the end of the tunnel may require multiple certifications. As an example, after becoming a PMP® credential holder, a project manager may desire to become certified in

Business Analyst Skills or Business Management

Program Management

Business Processes

Managing Complex Projects

Six Sigma

Risk Management

Agile Project Management

Some companies have certification boards that meet frequently and discuss what certification programs would be of value for their project managers. Certification programs that require specific knowledge of company processes or company intellectual property may be internally developed and taught by the company’s own employees.

Executives have come to realize that there is a return on investment in project management education. Therefore, executives are now investing heavily in customized project management training, especially in behavioral courses. As an example, one executive commented that he felt that presentation skills training was the highest priority for his project managers. If a project manager makes a highly polished presentation before a client, the client believes that the project is being managed the same way. If the project manager makes a poor presentation, then the client might believe the project is managed the same way. Other training programs that executives feel would be beneficial for the future include:

Establishing metrics and key performance indicators (KPIs)

Dashboard design

Managing complex projects

How to perform feasibility studies and cost–benefit analyses

Business analysis

Business case development

How to validate and revalidate project assumptions

How to establish effective project governance

How to manage multiple stakeholders many of whom may be multinational

How to design and implement “fluid” or adaptive enterprise project management (EPM) methodologies

How to develop coping skills and stress management skills

Project managers are now being brought on board projects at the beginning of the initiation phase rather than at its end. To understand the reason for this, consider the following situation:

SITUATION: A project team is assembled at the end of the initiation phase of a project to develop a new product for the company. The project manager is given the business case for the project together with a listing of the assumptions and constraints. Eventually the project is completed, somewhat late and significantly over budget. When asked by marketing and sales why the project costs were so large, the project manager responds, “According to my team’s interpretation of the requirements and the business case, we had to add in more features than we originally thought.”

Marketing then replies, “The added functionality is more than what our customers actually need. The manufacturing costs for what you developed will be significantly higher than anticipated, and that will force us to raise the selling price. We may no longer be competitive in the market segment we were targeting.”

“That’s not our problem,” responds the project manager. “Our definition of project success is the eventual commercialization of the product. Finding customers is your problem, not our problem.”

Needless to say, we could argue about what the real issues were in this project that created the problems. For the purpose of this book, three issues stand out. First and foremost, project managers today are paid to make business decisions as well as project decisions. Making merely project-type decisions could result in the development of a product that is either too costly to build or overpriced for the market at hand. Second, the traditional metrics used by project managers over the past several decades were designed for project rather than business decision making. Project managers must recognize that, with the added responsibilities of making business decisions, a new set of metrics may need to be included as part of their responsibilities. Likewise, we could argue that marketing was remiss in not establishing and tracking business-related metrics throughout the project and simply waited until the project was completed to see the results. Third, with the growth in the number of projects that companies must work on, executives do not have the time to act as heavily involved sponsors on all the projects without sacrificing some of their required day-to-day responsibilities. Data visualization systems and dashboards will ease some of the pain in knowing when a project requires immediate executive attention. The growth in metric measurement techniques and dashboard designs will allow executives to have customized metrics accompanied by real time updates so that decisions can be made based upon facts and evidence rather than guesses.

1.2 COMPLEX PROJECTS

TIP Today’s project managers see themselves as managing part of a business rather than simply managing a project. Therefore, they may require additional metrics for informed decision making.

For four decades, project management has been used to support traditional projects. Traditional projects are heavily based on linear thinking; there exist well-structured life cycle phases and templates, forms, guidelines, and checklists for each phase. As long as the scope is reasonably well defined, traditional project management works well.

Unfortunately, only a small percentage of all of the projects in a company fall into this category. Most nontraditional or complex projects use seat-of-the-pants management because they are largely based on business scenarios where the outcome or expectations can change from day to day. Project management techniques were neither required nor used on these complex projects that were more business oriented and aligned to 5-year or 10-year strategic plans that were constantly updated.

Project managers have finally realized that project management can be used on these complex projects, but the traditional processes may be inappropriate or must be modified. This includes looking at project management metrics and KPIs in a different light. The leadership style for complex projects may not be the same as that for traditional projects. Risk management is significantly more difficult on complex projects, and the involvement of more participants and stakeholders is necessary.

Now that companies have become good at traditional projects, we are focusing our attention on the nontraditional or complex projects. Unfortunately, there is no clear-cut definition of a complex project. Some of the major differences between traditional and nontraditional or complex projects, in the author’s opinion, are shown in Table 1.2.

TABLE 1.2 Traditional versus Nontraditional Projects

TRADITIONAL PROJECTS

NONTRADITIONAL PROJECTS

Time duration is 6–18 months.

Time duration can be several years.

Assumptions are not expected to change over the project’s duration.

Assumptions can and will change over the project’s duration.

Technology is known and will not change over the project’s duration.

Technology will most certainly change.

People who started on the project will remain through to completion (the team and the project sponsor).

People who approved the project and are part of the governance may not be there at the project’s conclusion.

Statement of work is reasonably well defined.

Statement of work is ill defined and subject to numerous scope changes.

Target is stationary.

Target may be moving.

There are few stakeholders.

There are multiple stakeholders.

There are few metrics and KPIs.

There can be numerous metrics and KPIs.

Comparing Traditional and Nontraditional Projects

The traditional project that most people manage usually lasts less than 18 months. In some companies, the traditional project might last six months or less. The length of the project usually depends on the industry. In the auto industry, for example, a traditional project lasts three years.

With projects that last 18 months or less, it is assumed that technology is known with some degree of assurance and technology may undergo little change over the life of the project. The same holds true for the assumptions. Project managers tend to believe that the assumptions made at the beginning of the project will remain intact for the duration of the project unless a crisis occurs.

People who are assigned to the project will most likely stay on board the project from beginning to end. The people may be full time or part time. This includes the project sponsor as well as the team members.

Because the project lasts 18 months or less, the statement of work is usually reasonably well defined, and the project plan is based on reasonably well-understood and proven estimates. Cost overruns and schedule slippages can occur, but not to the degree that they will happen on complex projects. The objectives of the project, as well as critical milestone or deliverable dates, are reasonably stationary and not expected to change unless a crisis occurs.

In the past, the complexities of nontraditional projects seem to have been driven by time and cost. Some people believe that these are the only two metrics that need to be tracked on a continuous basis. Complex projects may run as long as 10 years or even longer. Because of the long duration, the assumptions made at the initiation of the project will most likely not be valid at the end of the project. The assumptions will have to be revalidated throughout the project. There can be numerous metrics, and the metrics can change over the duration of the project. Likewise, technology can be expected to change throughout the project. Changes in technology can create significant and costly scope changes to the point where the final deliverable does not resemble the initially planned deliverable.

People on the governance committee and in decision-making roles most likely are senior people and may be close to retirement. Based on the actual length of the project, the governance structure can be expected to change throughout the project if the project’s duration is 10 years or longer.

Because of scope changes, the statement of work may undergo several revisions over the life cycle of the project. New governance groups and new stakeholders can have their own hidden agendas and demand that the scope be changed; they might even cancel their financial support for the project. Finally, whenever there is a long-term complex project where continuous scope changes are expected, the final target may move. In other words, the project plan must be constructed to hit a moving target.

SITUATION: A project manager was brought on board a project and provided with a project charter that included all of the assumptions made in the selection and authorization of the project. Partway through the project, some of the business assumptions changed. The project manager assumed that the project sponsor would be monitoring the enterprise environmental factors for changes in the business assumptions. That did not happen. The project was eventually completed, but there was no real market for the product.

Given the premise that project managers are now more actively involved in the business side of projects, the business assumptions must be tracked the same way that budgets and schedules are tracked. If the assumptions are wrong or no longer valid, then either the statement of work may need to be changed or the project may need to be canceled. The expected value at the end of the project also must be tracked because unacceptable changes in the final value may be another reason for project cancellation.

Examples of assumptions that are likely to change over the duration of a project, especially on a long-term project, include these:

The cost of borrowing money and financing the project will remain fixed.

Procurement costs will not increase.

Breakthroughs in technology will take place as scheduled.

The resources with the necessary skills will be available when needed.

The marketplace will readily accept the product.

The customer base is loyal to the company.

Competitors will not catch up to the company.

The risks are low and can be easily mitigated.

The political environment in the host country will not change.

The problem with having faulty assumptions is that they can lead to bad results and unhappy customers. The best defense against poor assumptions is good preparation at project initiation, including the development of risk mitigation strategies and tracking metrics for critical assumptions. However, it may not be possible to establish metrics for the tracking of all assumptions.

Most companies either have or are in the process of developing an enterprise project management (EPM) methodology. EPM systems usually are rigid processes designed around policies and procedures, and they work efficiently when the statement of work is well defined. With the new type of projects currently being used when techniques such as Agile Project Management are applicable, these rigid and inflexible processes may be more of a hindrance and costly to use on small projects.

EPM systems must become more flexible in order to satisfy business needs. The criteria for good systems will lean toward forms, guidelines, templates, and checklists rather than policies and procedures. Project managers will be given more flexibility in order to make the decisions necessary to satisfy the project’s business needs. The situation is further complicated because all active stakeholders may wish to use their own methodology, and having multiple methodologies on the same project is never a good idea. Some host countries may be quite knowledgeable in project management, whereas other may have just cursory knowledge.

TIP Metrics and KPIs must be established for those critical activities that can have a direct impact on project success or failure. This includes the tracking of assumptions and the creation of business value.

Over the next decade, having a fervent belief that the original plan is correct may be a poor assumption. As the project’s business needs change, the need to change the plan will be evident. Also, decision making based entirely on the triple constraints, with little regard for the project’s final value, may result in a poor decision. Simply stated, today’s view of project management is quite different from the views in the past, and this is partially because the benefits of project management have been recognized more over the past two decades.

TIP The more flexibility the methodology contains, the greater the need for additional metrics and KPIs.

Some of the differences between managing traditional and complex projects are summarized in Table 1.3. Perhaps the primary difference is whom the project manager must interface with on a daily basis. With traditional projects, the project manager interfaces with the sponsor and the client, both of whom may provide the only governance on the project. With complex projects, governance is by committee and there can be multiple stakeholders whose concerns need to be addressed.

TABLE 1.3 Summarized Differences between Traditional and Nontraditional Projects

MANAGING TRADITIONAL PROJECTS

MANAGING NONTRADITIONAL PROJECTS

Single-person sponsorship

Governance by committee

Possibly a single stakeholder

Multiple stakeholders

Project decision making

Both project and business decision making

An inflexible project management methodology management methodology

Flexible or “fluid” project

Periodic status reporting

Real-time reporting

Success defined by the triple constraints

Success defined by competing constraints, value, and other factors

Metrics and KPIs derived from the earned value measurement system

Metrics and KPIs may be unique to the particular project and even to a particular stakeholder

Defining Complexity

Complex projects can differ from traditional projects for a multitude of reasons, including:

Size

Dollar value

Uncertain requirements

Uncertain scope

Uncertain deliverables

Complex interactions

Uncertain credentials of the labor pool

Geographical separation across multiple time zones

Use of large virtual teams

Other differences

There are numerous definitions of a “complex” project, based on the interactions of two or more of the preceding elements. Even a small, two-month infrastructure project can be considered complex according to the definition. Project complexity can create havoc when selecting and using metrics. The projects that project managers manage within their own companies can be regarded as complex projects if the scope is large and the statement of work is only partially complete. Some people believe that research and development (R&D) projects are always complex because, if a plan for R&D can be laid out, then there probably is not R&D. R&D is when the project manager is not 100% sure where the company is heading, does not know what it will cost, and does not know if and when the company will get there.

Complexity can be defined according to the number of interactions that must take place for the work to be executed. The greater the number of functional units that must interact, the harder it is to perform the integration. The situation becomes more difficult if the functional units are dispersed across the globe and if cultural differences makes integration difficult. Complexity can also be defined according to size and length. The larger the project is in scope and cost and the greater the time frame, the more likely it is that scope changes will occur, significantly affecting the budget and schedule. Large, complex projects tend to have large cost overruns and schedule slippages. Good examples of this are Denver International Airport, the Channel Tunnel between England and France, and the “Big Dig” in Boston.

Trade-Offs

Project management is an attempt to improve efficiency and effectiveness in the use of resources by getting work to flow multidirectionally through an organization, whether traditional or complex projects. Initially, this flow might seem easy to accomplish, but typically a number of constraints are imposed on projects. The most common constraints are time, cost, and performance (also referred to as scope or quality), which are known as the triple constraints.

TIP Because of the complex interactions of the elements of work, a few simple metrics may not provide a clear picture of project status. The combination of several metrics may be necessary in order to make informed decisions based on evidence and facts.

Historically, from an executive-level perspective, the goal of project management was to meet the triple constraints of time, cost, and performance while maintaining good customer relations. Unfortunately, because most projects have some unique characteristics, highly accurate time and cost estimates were not always possible, and trade-offs between the triple constraints were necessary. As will be discussed later, today we focus on competing constraints and there may be significantly more than three constraints on a project, and metrics may have to be established to track each constraint. There may be as many as 10 or more competing constraints. Metrics provide the basis for informed trade-off decision making. Executive management, functional management, and key stakeholders must be involved in almost all trade-off discussions to ensure that the final decision is made in the best interests of the project, the company, and the stakeholders. If multiple stakeholders are involved, as occurs on complex projects, then agreement from all of the stakeholders may be necessary. Project managers may possess sufficient knowledge for some technical decision making but may not have sufficient business or technical knowledge to adequately determine the best course of action to address the interests of the parent company as well as the individual project stakeholders.

Skill Set

All project managers have skills, but not all project managers may have the right skills for the given job. For projects internal to a company, it may be possible to develop a company-specific skill set or company-specific body of knowledge. Specific training courses can be established to support company-based knowledge requirements.

For complex projects with a multitude of stakeholders, all from different countries with different cultures, finding the perfect project manager may be an impossible task. Today the understanding of complex projects and the accompanying metrics is in its infancy, and it is still difficult to determine the ideal skill set for managing complex projects. Remember that project management existed for several decades before the first Project Management Body of Knowledge (PMBOK® Guide*) was created, and even now with the seventh edition, it is still referred to as a “guide.”

We can, however, conclude that there are certain skills required to manage complex projects. Some of those skills are:

Knowing how to manage virtual teams

Understanding cultural differences

The ability to manage multiple stakeholders, each of whom may have a different agenda

Understanding the impact of politics on project management

How to select and measure project metrics

Governance

Cradle-to-grave user involvement in complex projects is essential. Unfortunately, user involvement can change because of politics and project length. It is not always possible to have the same user community attached to the project from beginning to end. Promotions, changes in power and authority positions because of elections, and retirements can cause shifts in user involvement.