67,99 €
Comprehensive, on-the-go toolkit for professional project managers, updated to reflect the tools necessary for today’s predictive, adaptive, hybrid work environment
Project Management ToolBox is a go-to reference for on-the-job project managers and advanced students of project management, providing a contemporary set of tools and explaining each tool’s purpose and intention, development, customization and variations. Examples, tips, and variations guide readers through the application of these tools.
The Third Edition, led by bestselling project management author Cynthia Snyder Dionisio, has been updated to offer a contemporary set of tools to reflect changes in project management learning and practice. This edition includes several new chapters that reflect today’s predictive, adaptive, and hybrid work environment. New content includes the project canvas, project roadmap, procurement strategy, risk responses, and more.
The book is structured to follow the flow of projects, starting with project selection, project origination, planning, implementation, monitoring, and closure. Within each section there is a wealth of tools, examples, tips, and variations to tailor the use of the tools.
Sample topics covered in Project Management ToolBox include:
Exploring emerging topics within the world of project management and keeping up to date on the latest, most relevant subject areas, Project Management ToolBox is a must-have resource that enables project managers to improve outcomes, deliver quality products and meet stakeholder expectations.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 564
Veröffentlichungsjahr: 2024
COVER
TABLE OF CONTENTS
TITLE PAGE
COPYRIGHT
PREFACE
ACKNOWLEDGMENTS
PART I: The PM Toolbox
1 INTRODUCTION TO THE PM TOOLBOX
ALIGNING THE PM TOOLBOX
CUSTOMIZING THE TOOLBOX
Reference
PART II: Project Start Up Tools
2 PROJECT SELECTION
BENEFITS MAP
ECONOMIC METHODS
SCORING MODELS
VOTING MODELS
PAIRWISE RANKING
ALIGNMENT MATRIX
PROJECT BUSINESS CASE
References
3 PROJECT ORIGINATION
COMPLEXITY ASSESSMENT
PROJECT CHARTER
PROJECT CANVAS
PROJECT ROADMAP
ASSUMPTION AND CONSTRAINT LOG
References
PART III: Project Planning Tools
4 STAKEHOLDER ENGAGEMENT
STAKEHOLDER REGISTER
STAKEHOLDER ANALYSIS
COMMUNICATION MATRIX
STAKEHOLDER ENGAGEMENT PLAN
CHOOSING YOUR STAKEHOLDER MANAGEMENT TOOLS
References
5 REQUIREMENTS MANAGEMENT
REQUIREMENTS ELICITATION PLAN
REQUIREMENTS MANAGEMENT PLAN
REQUIREMENTS SPECIFICATION
REQUIREMENTS TRACEABILITY MATRIX
References
6 SCOPE PLANNING
SCOPE STATEMENT
WORK BREAKDOWN STRUCTURE
PRODUCT BREAKDOWN STRUCTURE
WBS DICTIONARY
References
7 SCHEDULE DEVELOPMENT
MILESTONE CHART
NETWORK DIAGRAM
CRITICAL PATH METHOD
CRITICAL CHAIN SCHEDULE
CHOOSING YOUR SCHEDULING TOOLS
References
8 COST PLANNING
COST MANAGEMENT PLAN
ANALOGOUS ESTIMATE
PARAMETRIC ESTIMATE
BOTTOM-UP ESTIMATE
COST BASELINE
CHOOSING A COST-PLANNING TOOL
References
9 RESOURCE PLANNING
RESOURCE MANAGEMENT PLAN
RESPONSIBILITY MATRIX
PROCUREMENT MANAGEMENT PLAN
PROCUREMENT STRATEGY
References
10 RISK PLANNING
RISK MANAGEMENT PLAN
RISK IDENTIFICATION CHECKLIST
RISK REGISTER
RISK ASSESSMENT
RISK RESPONSES
CHOOSING RISK MANAGEMENT TOOLS
References
PART IV: Project Implementation Tools
11 ADVANCED RISK MANAGEMENT TOOLS
MONTE CARLO ANALYSIS
DECISION TREE
RISK DASHBOARD
CHOOSING ADVANCED RISK MANAGEMENT TOOLS
References
12 CHANGE MANAGEMENT
CHANGE MANAGEMENT SYSTEM
CHANGE REQUEST
CHANGE LOG
SCOPE CONTROL DECISION CHECKLIST
References
13 AGILE PROJECT EXECUTION
SCRUM BASICS
PRODUCT BACKLOG AND SPRINT BACKLOG
RELEASE PLANNING
DAILY SCRUM MEETING
SPRINT TASK BOARD
SPRINT BURN DOWN CHART
SPRINT RETROSPECTIVE MEETING
References
Note
PART V: Project Monitoring, Reporting and Closure Tools
14 SCHEDULE MANAGEMENT
SLIP CHART
BUFFER CHART
JOGGING LINE
MILESTONE PREDICTION CHART
B–C–F ANALYSIS
SCHEDULE CRASHING
CHOOSING YOUR SCHEDULE MANAGEMENT TOOLS
References
15 COST MANAGEMENT
BUDGET CONSUMPTION CHART
EARNED VALUE ANALYSIS
MILESTONE COST ANALYSIS
CHOOSING YOUR COST MANAGEMENT TOOLS
References
16 PERFORMANCE REPORTING
PROJECT REPORTING CHECKLIST
PROJECT STRIKE ZONE
PROJECT DASHBOARD
SUMMARY STATUS REPORT
PROJECT INDICATOR
CHOOSING YOUR REPORTING TOOLS
References
17 PROJECT CLOSURE
PROJECT CLOSURE PLAN AND CHECKLIST
PROJECT CLOSURE REPORT
LESSONS LEARNED REPORT
POSTMORTEM REVIEW
INDEX
END USER LICENSE AGREEMENT
Chapter 1
Table 1.1: Examples of Project Classification by Size
Table 1.2: Examples of PM Toolbox Customization by Project Size
Table 1.3: Customizing the Toolbox by Project Innovation
Table 1.4: Project Situations and PM Toolbox Customization
Chapter 2
Table 2.1: Project Payback Period Examples
Table 2.2: Project Net Present Value Examples
Table 2.3: Rating a New Product Development Project with a Scoring Model
Table 2.4: Ranking of Projects Using the Scoring Model
Table 2.5: Example Criteria Description and Value Anchors
Table 2.6: Project Preference Tally
Table 2.7: Candidate Project Ranking
Table 2.8: Minimum Elements of a Project Business Case
Chapter 3
Table 3.1: Example Technical, Structural, and Business Complexity Dimensions
Table 3.2: Contents in an Assumption and Constraint Log
Chapter 4
Table 4.1: Sample Stakeholder Sources
Table 4.2: Sample Stakeholder Register
Table 4.3: Example of Qualitative Stakeholder Analysis
Table 4.4: Communication Methods
Table 4.5: Communication Matrix
Table 4.6: The Power/Support Grid
Chapter 5
Table 5.1: Requirements Elicitation Plan
Table 5.2: Inter-Requirements Traceability Matrix
Table 5.3: Requirement–Deliverable Traceability Matrix
Chapter 6
Table 6.1: Methods for Structuring the WBS
Table 6.2: Examples of the Level of Detail of a WBS
Table 6.3: Activity Information for a WBS Dictionary
Chapter 7
Table 7.1: Network Diagram Information
Table 7.2: Network Diagram Information
Table 7.3: A Summary Comparison of Schedule Development Tools
Chapter 8
Table 8.1: Levels of Accuracy
Table 8.2: Example Analogous Estimate for a Software Project
Table 8.3: A Summary Comparison of Cost-Planning Tools
Chapter 9
Table 9.1: Team Resource Requirements
Table 9.2: Example Procurement Activities
Chapter 10
Table 10.1: Sample Probability and Impact Matrix
Table 10.2: Example Five-level Scale of Risk Probability
Table 10.3: Example Five-Level Scale of Risk Impact
Table 10.4: Sample Probability and Impact Matrix with Severity
Table 10.5: Sample Risk Identification Checklist
Table 10.6: Example Project Risk Register
Table 10.7: Modified Schedule Impact Parameters
Table 10.8: Modified Impact Scale
Chapter 12
Table 12.1: Sample Scope Control Decision Checklist
Chapter 13
Table 13.1: Task Tracking Table
Chapter 14
Table 14.1: Crashed Schedule Duration and Cost Amounts
Table 14.2: A Summary Comparison of Schedule Control Tools
Chapter 15
Table 15.1: Fundamentals of Major Earned Value Measurement Methods
Table 15.2: Key Earned Value Analysis Formulas
Table 15.3: Fundamentals of Major Earned Value Measurement Methods
Table 15.4: A Summary Comparison of Cost Control Tools
Chapter 16
Table 16.1: Example Project Reporting Checklist
Table 16.2: Project Reporting Tools
Chapter 17
Table 17.1: Generic Project Closure Checklist
Table 17.2: Project Completion Template
Table 17.3: Project Closure Deliverables Template
Table 17.4: Project Closure Resource Template
Table 17.5: Project Closure Communication Template
Table 17.6: Project Completion Template
Table 17.7: Project Postmortem Checklist Questionnaire
Chapter 1
Figure 1.1: Four Project Types
Figure 1.2: Customizing the PM Toolbox by Project Type
Chapter 2
Figure 2.1: Sample Project Benefits Map
Figure 2.2: Example Objectives Tree
Figure 2.3: Example Voting Model Template
Figure 2.4: Initial Value Voting Assessment Results
Figure 2.5: Ranking of Projects into High, Medium, and Low Priority
Figure 2.6: Pairwise Ranking Comparison Matrix
Figure 2.7: Project-to-Project Comparison
Figure 2.8: Example Alignment Matrix
Figure 2.9: Strategy Alignment Map
Chapter 3
Figure 3.1: Example Project Complexity Assessment
Figure 3.2: Example Project Charter
Figure 3.3: Template for a Project Canvas
Figure 3.4: Sample Project Roadmap
Chapter 4
Figure 4.1: Example of a Simple Stakeholder Matrix
Figure 4.2: Example of a Desired Future State Stakeholder Matrix
Figure 4.3: Example of a Robust Stakeholder Matrix
Figure 4.4: Example Powergram
Figure 4.5: The Power/Support Grid
Chapter 5
Figure 5.1: Town Square Storyboard
Figure 5.2: Town Square Model
Figure 5.3: MoSCoW Analysis
Figure 5.4: Risk-Value Matrix
Chapter 6
Figure 6.1: Simple Scope Statement
Figure 6.2: WBS in Tree Structure Format
Figure 6.3: WBS in Outline Format
Figure 6.4: Example Whole Product Solution Diagram
Figure 6.5: Mind-map PBS Design Example
Chapter 7
Figure 7.1: Example Milestone Chart
Figure 7.2: Example Network Diagram
Figure 7.3: Start-to-Start with a Lag
Figure 7.4: Finish-to-Finish with a Lag
Figure 7.5: Finish-to-Start with a Lead
Figure 7.6: Network Diagram with Multiple Relationships
Figure 7.7: Network Diagram with Durations
Figure 7.8: Task Template for Critical Path Calculations
Figure 7.9: Network Diagram with Forward Pass
Figure 7.10: Network Diagram with Backward Pass
Figure 7.11: Critical Path and Float
Figure 7.12: Example Critical Chain Schedule
Figure 7.13: Productivity of Multi-project Team Members
Chapter 8
Figure 8.1: Basic Features of Analogous Estimates
Figure 8.2: Sample Cost Estimate Relationship for Parametric Estimates
Figure 8.3: Building a Cost Estimating Relationship Model
Figure 8.4: Stratified Cost Estimating Relationships
Figure 8.5: Basic features of Parametric Estimates
Figure 8.6: An example of a Bottom-Up Estimate
Figure 8.7: Basic Features of Bottom-Up Estimates
Figure 8.8: A Sample Cost Baseline
Figure 8.9: A Cost Baseline displayed as an S-curve
Chapter 9
Figure 9.1: Resource Breakdown Structure
Figure 9.2: Initial Responsibility Matrix Structure
Figure 9.3: Completed Project Responsibility Matrix
Figure 9.4: Generic Procurement Lifecycle
Chapter 10
Figure 10.1: The Project Risk Management Continuum
Figure 10.2: Example Risk Map
Figure 10.3: Example Bubble Chart
Chapter 11
Figure 11.1: Cumulative Distribution of Project Duration Produced in Monte C...
Figure 11.2: Monte Carlo Analysis Process for Schedule Risk
Figure 11.3: An Example of a Gantt Chart for Risk Analysis with Monte Carlo...
Figure 11.4: Frequently used Distribution. (a) Triangular Distribution, (b) ...
Figure 11.5: Cumulative Distribution
Figure 11.6: Frequency Distribution Histogram of Project Duration
Figure 11.7: An Example Tornado Chart
4
Figure 11.8: Decision Tree for a Project Situation under Risk
Figure 11.9: Example Risk Dashboard
Chapter 12
Figure 12.1: Example Change Management Process
Figure 12.2: Project Change Request Template
Figure 12.3: Example Change Log
Figure 12.4: The Cascading Effect of Project Scope Change
Chapter 13
Figure 13.1: The Scrum Workflow
Figure 13.2: Example Product Backlog
Figure 13.3: Example Sprint Backlog
Figure 13.4: Product Backlog and Sprint Backlog in Sprint Life Cycle
Figure 13.5: The Release Planning Event
Figure 13.6: Release Plans Developed by Several Scrum Teams
Figure 13.7: The Daily Scrum in the Sprint Lifecycle
Figure 13.8: An example Sprint Task Board
Figure 13.9: A variation of Sprint Task Board
Figure 13.10: Sample Sticky Note for a Task
Figure 13.11: Example Sprint Burn Down Chart
Figure 13.12: Plotting Work in Progress
Figure 13.13: Sprint Retrospective Meeting in Sprint Lifecycle
Figure 13.14: Retrospective Whiteboard
Chapter 14
Figure 14.1: An Example Slip Chart
Figure 14.2: An Example Buffer Chart
Figure 14.3: An Example Jogging Line
Figure 14.4: Project Assessment as Part of the Plan–Do–Study–Act Cycle...
Figure 14.5: An Example Milestone Prediction Chart
Figure 14.6: Example B–C–F Analysis
Figure 14.7: Schedule Crashing Example—Original Schedule
Figure 14.8: Schedule Crashing Example—Crashed Schedule
Chapter 15
Figure 15.1: Example Budget Consumption Chart
Figure 15.2: Budget Consumption Chart with Funding Changes
Figure 15.3: An Example Earned Value Analysis Chart
Figure 15.4: Control Accounts and Work Packages
Figure 15.5: Performing Earned Value Analysis
Figure 15.6: Tracking Cumulative Schedule Performance Index (SPI) and Cost P...
Figure 15.7: Example Cost and Achievement Analysis
Figure 15.8: An example Milestone Cost Analysis
Chapter 16
Figure 16.1: Example Project Strike Zone
Figure 16.2: Sample Project Dashboard
Figure 16.3: Strategy, Outcomes, and KPIs
Figure 16.4: Sample Dashboard Structure Layout
Figure 16.5: Sample Summary Status Report
Figure 16.6: Sample Issue Register
Figure 16.7: Sample Project Indicator
Figure 16.8: Sample Functional Indicator
Chapter 17
Figure 17.1: The Flow of Closure Work
Cover
Table of Contents
Title Page
Copyright
Preface
Acknowledgments
Begin Reading
Index
End User License Agreement
iii
iv
xv
xvii
1
3
4
5
6
7
8
9
10
11
12
13
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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
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
191
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
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
331
332
333
334
335
336
337
338
339
340
341
Third Edition
Cynthia Snyder Dionisio
Russ J. Martinelli
Intel Corporation
USA
Copyright © 2025 by John Wiley & Sons, Inc. All rights reserved, including rights for text and data mining and training of artificial technologies or similar technologies.
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, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission.
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
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 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. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data applied for:
Hardback ISBN: 9781394222063
Cover Design: WileyCover Image: © Jorg Greuel/Getty Images
In the eight years since the second edition of the Project Management Toolbox was published, the practice of project management has changed significantly. Today, more than half of the projects use hybrid approaches to managing projects. Meaning that while predictive (waterfall) tools are still used, adaptive (Agile) tools and techniques are often integrated where applicable. The practice of separating the two ways of performing projects is waning and an attitude of “figure out the best way to deliver value” is taking over.
With that in mind, some of the tools that were predominantly used in the predictive projects of the past, such as a Time-Scaled Network Diagram or a Line of Balance Schedule, are not in the third edition. Several new tools have been introduced. The new tools can be used for predictive, adaptive, or hybrid projects, such as a Project Canvas, Project Roadmap, and Communication Matrix.
Some of the existing topics have been updated. The chapter on requirements has been refreshed. The intent of eliciting and managing requirements hasn’t changed, but the tools used to do so have been updated. You will see a Requirements Management Plan and a Requirements Traceability Matrix rather than a Product Requirements Document and a Requirements Ambiguity Checklist.
There are also new chapters – Resource Planning, Advanced Risk Management, and Change Management. Some of these chapters have new content, and others reorganize content from the second edition.
The third edition of this book maintains the previous effective format of presenting a tool, describing how to develop it and then how to apply it, interspersed with examples and tips where applicable. Rather than having a separate section for the benefits of each tool, the benefits are indicated when introducing the tool.
It must be acknowledged that the world of project management is on the precipice of a huge change with the advent of artificial intelligence (AI). AI can be a tremendous asset when managing a project, but it cannot replace the fundamental understanding of project management and the knowledge of how to use tools to effectively manage projects. Therefore, while acknowledging the benefit of AI, this book does not describe how to use it in project management. After learning how to work with the tools in this Toolbox, you may choose to see how AI applies them, but first, you have to understand the fundamental tools, how to develop them and how to use them.
With thanks to the existing and future readers of this book. May it prove useful throughout your project management journey.
Thank you to the many people who have helped in making this book a reality.
To the team at John Wiley & Sons, who continue to provide outstanding support and guidance. In particular, thanks go out to Margaret Cummins, Senior Editorial Director, and Kallie Schultea, Senior Editor. You are both wonderful women and outstanding professionals. It is an honor to work with you. Isabella Proietti and Jeevaghan Devapal have been helpful and professional in helping to get this book updated and published.
No one can take the time it takes to write a book without the understanding and forbearance of family. Thank you for your continued encouragement.
Finally, a huge thank you to project, program, and portfolio professionals everywhere. Every one of you is an inspiration. Keep uplifting our world!
Project management tools support the practices, methods, and processes used to effectively manage a project. They enable the primary players on a project—the project manager, project team, executive leadership team, and governance body.
For purposes of this book, tools are considered to be processes, techniques, artifacts, software, or other job aids that assist in creating deliverables or project information. PM tools may be qualitative or quantitative in nature.
To illustrate, consider two examples, the Team Charter and a Monte Carlo Analysis. The Team Charter is an artifact that outlines how the team will work together on a project. A Monte Carlo analysis involves analyzing data that is generated from a software tool that uses an algorithm to quantify uncertainty around cost or schedule outcomes.
Note there is no mention of specific software tools here. While many PM tools discussed in this book exist in a software format, the focus is not on tool formats. Rather, the focus is on the use of tools to manage projects more effectively and efficiently.
A project management (PM) toolbox provides a set of tools that serves several purposes, such as:
Increasing the efficiency of the project players
Providing the right information to support problem solving
Providing relevant information for making decisions
Helping to establish and maintain alignment between business strategy, project strategy, and project outcomes.
The design of a PM Toolbox should align with the approach an organization takes for establishing project management methodologies and processes.
Organizations have a host of options when developing their methodologies and processes—they can be more standardized or more flexible. Generally, projects with a high degree of certainty do well with more standardization. Projects that face a high degree of uncertainty require more flexibility. The decision about how much to standardize project management methodologies and processes is driven by business strategy and by the types of projects needed to realize the business strategy.
The rationale behind standardization is to create a predictable process that prevents activities from differing substantially from project to project, and from project manager to project manager. Put simply, standardization saves project players the trouble of reinventing a new method and process for each individual project. As a result, the process is repeatable despite changes in customer expectations or management turnover.
The rationale behind flexibility is to give the project team the ability to explore, experiment, and iterate processes to reduce uncertainty. The players learn and adapt through multiple iterations in order to meet the needs of the project and the stakeholders.
When developing a PM toolbox, organizations should weigh the need for fixed and repeatable processes against the need for flexible and adaptable processes. This need may vary depending on the different departments or functions in an organization. For example, an engineering department may benefit from well-established policies, processes, and tools. In the same organization, the IT department may benefit from a more flexible and adaptable set of processes and tools. Both approaches are fine as long as they support the business strategy and are aligned with the project objectives.
Since the PM Toolbox is aligned with the PM methodology used, it is understandable that the level of standardization of the methodology impacts the standardization level of the PM Toolbox. For example, a methodology that is highly standardized will probably be supported by a highly standardized PM Toolbox.
Developing a PM Toolbox is an evolutionary process. In a practical sense, PM toolboxes will look quite ad hoc at first. The tendency is to begin building the PM Toolbox with existing tools due to a project manager’s familiarity with them. Thus, the early-stage PM Toolbox has more to do with familiarity of use than with standardization. As a firm begins to mature its project management practices, there is a greater understanding of the tools that are needed in the Toolbox.
Often, project managers assume that the PM Toolbox is of a one-size-fits-all nature. This is incorrect. The PM Toolbox reflects the project management methodology and types of projects the methodology serves.
Regardless of whether an organization’s project management methods and processes are standardized, flexible, or semi-flexible, a PM Toolbox needs to be designed so that it aligns with both the PM methods and processes employed as well as the strategy of the project and the business strategies driving the need for the project. To accomplish this, a process for selecting and adapting the PM Toolbox is needed.
There are multiple options for customizing a PM Toolbox. Three of the most common are:
Customization by project size
Customization by project innovation
Customization by project type.
Each option has the purpose of showing which specific project management tools to select and adapt for the PM Toolbox. An in-depth knowledge of individual tools is a prerequisite to each of the options because you need to understand how each tool can support a project deliverable. This section describes the customization options and offers guidelines for selecting one of them for implementation.
Some organizations use project size as the key variable when customizing a PM Toolbox. Their logic is that larger projects are more complex than smaller ones, or the size drives differences in project management methodology complexity. The reasoning here is that as the project size increases, so does the number of project management activities and resulting project deliverables associated with a project, and so does the number of interactions among them.
Since different project sizes require different processes and tools, we first need a way to classify projects by size and then customize their toolboxes. In Table 1.1 you can see examples of how different companies classify small, medium, and large projects.
Based on size, the companies determined the managerial complexity of the project classes and processes. The complexity influences the PM Toolbox make-up. A simplified example is shown in Table 1.2.
As Table 1.2 indicates, some of the tools in the toolboxes for projects of different size are the same, others are different. For example, all use the Lessons Learned (Chapter 17) because all projects need to learn from their performance. Since managerial complexity of the three project classes and their processes calls for different tools, some of the tools differ. For example, Earned Value Management (Chapter 15) is needed in large projects, but not medium or small projects.
Table 1.1: Examples of Project Classification by Size
Project and Company Type
Project Size
Small
Medium
Large
Product development projects in a $1Billion/year high-technology manufacturer
$1–2M
$2–5M
>$5M
Infrastructure technology projects in a $300M/year food processing company
<$50k
$50–150k
>$150k
Software development projects in a $40M/year customer relationship management software company
300–400 person-hours
1000–3000 person-hours
>3000 person-hours
Table 1.2: Examples of PM Toolbox Customization by Project Size
Project Size
Origination
Planning
Development
Closure
Small
Project canvas
Scope statement
Summary status report
Project closure report
WBS
Responsibility matrix
Milestone chart
Medium
Project Charter
Stakeholder registerStakeholder analysisCommunication matrixScope statement
Summary status report
Project closure report
WBS
Change management system
Post mortem review
Responsibility matrix
Change log
Cost estimates
Critical path method
Critical path method
Cost baseline
Risk registerRisk assessmentRisk responses
Risk register
Large
Project charter
Stakeholder registerStakeholder analysisCommunication matrixScope statement
Summary status report
Project closure report
Complexity assessment
WBS
Post mortem review
Responsibility matrix
Change management system
Project closure plan and checklist
Cost estimates
Critical path method
Critical path method
Slip chart
Risk registerRisk assessmentRisk responses
Earned value management
Monte Carlo analysis
Risk registerMonte Carlo analysisRisk dashboard
When customizing the PM Toolbox by project size follow these steps:
Identify a small number of project categories
Define each category by the size parameter
Match the project size with the proper toolbox.
Note that while customization by project size offers advantages of simplicity, it also carries a risk of being generic, disregarding other situational variables. To some, these other variables may be of vital importance, as will be pointed out in the next section on customization by project family.
The amount of innovation influences the tools in the PM Toolbox. For example, companies in the high-technology industry face an environment of dynamic technology change. Because of this, their portfolios have many quick time-to-market projects driven by the desire of their customers to continuously buy the latest and greatest technological products and services. Conversely, facilities management projects don’t often have to contend with innovation and technology risk.
Innovation projects have more uncertainty. Uncertainty generally means more complexity, which requires more flexibility in the project management processes and the supporting toolbox. For example, as innovation grows:
The more scope and requirements evolve
The more the schedule becomes fluid
Cost Estimates follow the fluidity of the schedules and scope.
A simple example reflecting these trends in adapting the toolbox for three levels of innovation could be Derivative Projects, Incremental Projects, and Breakthrough Projects.
Derivative projects are those that have little to no innovation. The organization has done them before, the scope and requirements are well known, and there is little expectation of change.
Incremental projects have some degree of innovation, often improving components or parts of a project. The outputs are mostly known, though there may be a need to iterate on a few aspects of the deliverables.
Breakthrough projects deal with unknown, or evolving technologies. There may be uncertainty associated with requirements, technology, and solutions. These types of projects require a flexible approach to deal with the uncertainty and complexity associated with creating new solutions to problems or opportunities.
Table 1.3 shows an example of customizing the toolbox based on the degree of innovation.
As the table shows, the PM Toolbox for derivative and incremental projects are similar. However, breakthrough projects typically use a more Agile or adaptive approach that allows for evolving and changing scope.
While the previous two approaches to PM Toolbox customization rely on one dimension each—project complexity and project innovation—customization by the project type uses two dimensions.1
Table 1.3: Customizing the Toolbox by Project Innovation
Project Innovation
Origination
Planning
Development
Closure
Derivative projects
Project charter
Milestone chart
Summary status report
Project closure report
Scoring models
Requirements specification
WBS
Incremental projects
Project charter
Stakeholder analysisScope statement
Summary status report
Project closure report
Scoring models
WBS or PWBS
Change log
Change log
Requirements specification
Critical path method
Lessons learned
Cost estimates
Budget consumption chart
Critical path method
Risk register
Risk registerRisks analysisRisk responses
Breakthrough projects
Project roadmap
Stakeholder engagement plan
Backlog
Project closure report
Complexity assessment
Requirements elicitation plan
Requirements traceability matrix
Post mortem review
Backlog
Task board
Lessons learned
Release planning
Release planning
Sprint retrospective meetings
This model shows a grid with each dimension. Each dimension includes two levels: (1) innovation of the capability under development (low, high) and (2) project complexity (low, high). This helps to create a two-by-two matrix that features four types of projects—routine, administrative, technical, unique (see Figure 1.1).
A routine project is one having a low level of capability innovation (less than half of the technologies are new) and low complexity (few cross-project interdependencies). Due to the low levels of innovation and complexity, the project scope can normally be frozen before development begins or early in the development phase. Scope also remains fairly stable with few changes. With scope remaining stable, project scheduling, cost management, and performance management are also quite static.
Typically, routine projects are performed within a single organization or organizational function (for example, infrastructure technology). Examples include the following:
Continuous improvement project in a department
Upgrading an existing product
Developing an updated model in a product line
Expanding an established manufacturing line.
Figure 1.1: Four Project Types
Administrative projects are similar to routine projects in terms of innovation. Business goals and scope are normally well defined, stable, and detailed. The added complexity requires the coordination of multiple organizational functions and the mapping of the many functional interdependencies, but the lack of capability innovation allows for standard scheduling techniques. The same added complexity generally means larger project size, with higher financial exposure, justifying the need for detailed bottom-up cost estimates reconciled with financial targets contained in the project business case. Risk is primarily related to the increased number of interactions between the functions and project team; therefore, additional risk planning and analysis is required.
Some examples of administrative projects are as follows:
Corporate-wide organizational restructuring
Deploying a standard information system for a geographically dispersed organization
Building a traditional manufacturing plant
Upgrading an enterprise computer system.
Technical projects consist of more than 50% of new technologies or features at the time of project origination. This creates a higher degree of uncertainty that requires project flexibility. The goals, scope, and WBS are simple due to the low level of complexity, but they may take longer to fully define. The rolling wave or similar approach can be used, meaning that only the schedule for the following 60–90 days can be planned in detail, while the remainder of the program schedule is represented only by milestones. Similarly, cost estimates are fluid as well. A detailed cost estimate for the next 60–90 days can be developed, while cost estimates for the remainder of the project are at the summary or rough order of magnitude level. The increased technical innovation results in increased technical risk and the need for a more rigorous risk management implementation and tools. Here are some examples:
Reengineering a new product development process in an organization
Developing a new software program
Adding a line with the latest manufacturing technology to a semiconductor fabrication plant
Developing a new model of a computer game.
For unique projects, business goals, detailed scope definition, and WBS development take time to evolve as a result of many new features and cross-project interdependencies. The evolving nature of scope leads to the need for fluid schedules. Project mapping and rolling wave scheduling processes can be used to contend with the fluidity. Similarly, cost estimates for milestones are more detailed in the near term and more summary level for the longer term. A high degree of project complexity exists due to multiple organizational functions required to execute unique projects, requiring integration tools. Combined capability innovation and project complexity push risks to the extreme, making it the single most challenging element to manage. In response, a rigorous risk management plan is needed, as well as a combination of tools such as a Monte Carlo Analysis and a Risk Dashboard (Chapter 11). Example technology projects include:
Building a new light rail train system for a city
Developing a new generation integrated circuit
Developing a new software suite.
Now that we’ve defined the four project types, we can move on to the next step—describe how the two dimensions impact the construction of the PM Toolbox. Taken overall, the growing technical innovation in a project generates more uncertainty, which consequently requires more flexibility in the tools chosen. Figure 1.2 shows examples of several project management tools that are adapted to account for different processes driven by different project type.
A summary comparison of the tools for the four project types reveals that they use similar types of tools. For example, all use the WBS. Still, when the same type of tool is used, there are differences in their structure and how they are used. Consider, for instance, Gantt and Milestone Charts. Both are used in the routine and unique projects, but terms of use are significantly different. This is the situational approach—as the nature of the project management processes change, so does the PM Toolbox.
The three options for customizing the PM Toolbox each has its advantages, disadvantages, and risks. Each option fits some situations better than others. Table 1.4 provides some insight on how to choose the option best suited for your needs. Customization by project size is a good option when an organization has projects of varying size and needs a simple start toward more mature forms of customization. In addition, projects of varying size characterized by mature processes lend themselves well to this customization option. In an organization that has a stream of projects that feature both mature and innovation capabilities and project size is not the main issue, customization by project innovation may be the best option.
Figure 1.2: Customizing the PM Toolbox by Project Type
Table 1.4: Project Situations and PM Toolbox Customization
Situation
Customization by Project Size
Customization by Project Innovation
Customization by Project Type
Simplest start to PM Toolbox customization
✓
Projects of varying size with mature capabilities
✓
Projects with both mature and innovation aspects, size not an issue
✓
Projects with strong industry or professional culture
✓
Projects of varying size with both mature and innovative capabilities
✓
Need for a unifying framework for all organizational projects
✓
Customization of the PM Toolbox by project type is a good option in situations where an organization has a lot of projects that significantly vary in size and in innovation of the solutions, such as a portfolio of government research and procurement projects. Organizations searching for a unifying framework that can provide the customization for all types of projects—from facilities to product development to manufacturing process to customer service to information systems—may find customization by project type an appropriate choice.
Effectively constructing and adapting a PM Toolbox is predicated upon the user’s knowledge of individual project management tools. To help increase your knowledge of individual tools, the remaining chapters detail a multitude of useful tools that can be chosen for inclusion in your own PM Toolbox.
1. Boutros, T. and Purdie, T. (2013).
The Process Improvement Handbook: A Blueprint for Managing Change and Increasing Organizational Performance
. New York, NY: McGraw-Hill.