53,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Sprache: Englisch
Hybrid Project Management A how-to guide for leaders of hybrid projects that covers technical and leadership principles across the project delivery spectrum. Hybrid Project Management offers practical guidance for combining waterfall and adaptive (Agile) project management approaches. This helpful guide includes advice on when to use each approach and how various methods can be combined and customized to meet the needs of projects and stakeholders. A sample case study demonstrates how to apply the concepts described throughout the text. An exciting new title from bestselling author Cyndi Snyder Dionisio on a top trending topic in the field, sample topics covered in Hybrid Project Management include: * Variables to consider when choosing a development approach * Project roles such as sponsors, product owners, project managers, scrum masters, and the project team * Launching a hybrid project (vision statements and charters) and structuring the project (development approach, delivery cadence, lifecycle, and roadmap) * Project scope requirements, backlogs, and user stories * Hybrid scheduling that combines Gantt charts and release plans * Leadership in a hybrid project, covering servant leadership, bias, critical thinking, emotional intelligence, motivation, and developing high-performing teams * Managing risk on hybrid projects including estimating reserve and using a risk-adjusted backlog * Identifying metrics and reports for predictive and adaptive project work, such as burn charts, variance analysis, forecasts, and cumulative flow diagrams With over fifty percent of projects today being managed using a hybrid approach, Hybrid Project Management serves as an important guide to hybrid project management methods for project management professionals and academia. It is an invaluable resource for understanding the approach and effectively implementing it for better outcomes.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 444
Veröffentlichungsjahr: 2022
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Acknowledgments
Introduction
1 Introducing Project Management
THE SPECTRUM OF DEVELOPMENT APPROACHES
HYBRID PROJECT MANAGEMENT AND DEVELOPMENT APPROACHES
SUMMARY
2 Choosing a Development Approach
PRODUCT VARIABLES
PROJECT VARIABLES
ORGANIZATION VARIABLES
DEVELOPMENT APPROACH EVALUATION TOOL
CREATING A VISUAL DISPLAY OF THE VARIABLES
SUMMARY
3 Project Roles
PROJECT SPONSOR
PROJECT MANAGER
PRODUCT OWNER
SCRUM MASTER
THE TEAM
HYBRID OPTIONS
SUMMARY
4 Launching a Hybrid Project
VISION STATEMENTS
PROJECT VISION STATEMENTS
PROJECT CHARTER
CASE STUDY
ASSUMPTIONS AND CONSTRAINTS
SUMMARY
NOTE
5 Hybrid Project Planning and Structure
PLANNING FUNDAMENTALS
THE PROJECT MANAGEMENT PLAN
PROJECT LIFE CYCLES
KEY REVIEWS
PROJECT MANAGEMENT PLAN FOR A HYBRID PROJECT
ROADMAP
SUMMARY
6 Defining Scope in Hybrid Projects
PLANNING FOR SCOPE WITH A SCOPE MANAGEMENT PLAN
ELABORATING SCOPE WITH A SCOPE STATEMENT
ORGANIZING SCOPE WITH A WORK BREAKDOWN STRUCTURE
GETTING INTO THE DETAIL WITH A WBS DICTIONARY
WORKING WITH REQUIREMENTS
PRIORITIZING SCOPE WITH A BACKLOG
SUMMARY
7 Building a Predictive Schedule
ORGANIZING WITH A SCHEDULE MANAGEMENT PLAN
PREDICTIVE SCHEDULING
SUMMARY
8 Analyzing and Finalizing a Predictive Schedule
ANALYZING THE SCHEDULE
FINALIZING THE SCHEDULE
SUMMARY
9 Adaptive and Hybrid Scheduling
ADAPTIVE SCHEDULING
HYBRID SCHEDULING
SUMMARY
10 Estimating
ESTIMATING RANGES
ESTIMATING METHODS
ESTIMATING THE BUDGET
SUMMARY
11 Stakeholder Engagement
IDENTIFYING YOUR STAKEHOLDERS
ANALYZING STAKEHOLDERS
STAKEHOLDER REGISTER
PLANNING FOR SUCCESSFUL ENGAGEMENT
PLANNING PROJECT COMMUNICATION
STAKEHOLDER COMMUNICATION PLAN
SUMMARY
12 Maintaining Stakeholder Engagement
ENGAGING STAKEHOLDERS
COMMUNICATION COMPETENCE
PROJECT MEETINGS
SUMMARY
13 Leadership in a Hybrid Environment
EMOTIONAL INTELLIGENCE
MOTIVATORS
AGILE LEADERSHIP PRACTICES
DEVELOPING A HIGH‐PERFORMING TEAM
SUMMARY
14 Planning for Risk
INTRODUCTION TO RISK MANAGEMENT
RISK TOLERANCE AND THRESHOLDS
RISK MANAGEMENT PLAN
SUMMARY
15 Identifying and Prioritizing Risk
IDENTIFYING RISKS
ANALYZING AND PRIORITIZING RISKS
SIMPLE QUANTITATIVE ANALYSIS METHODS
SUMMARY
16 Reducing Risk
RISK RESPONSES
IMPLEMENTING RESPONSES
RISK‐ADJUSTED BACKLOG
RESERVE
SUMMARY
17 Leading the Team
ESTABLISHING A HEALTHY ENVIRONMENT
WAYS OF THINKING
SUPPORTING THE TEAM
CONSIDERATIONS FOR VIRTUAL TEAMS
SUMMARY
18 Maintaining Momentum
WORKING WITH CHANGE
MANAGING CHANGE IN A HYBRID ENVIRONMENT
HELPFUL TOOLS
SUMMARY
19 Metrics for Predictive Deliverables
PREDICTIVE MEASURES
EARNED VALUE MANAGEMENT
FORECASTS
SUMMARY
20 Metrics for Adaptive Deliverables
ADAPTIVE MEASURES
CUMULATIVE FLOW DIAGRAMS
STAKEHOLDER MEASURES
SUMMARY
21 Reporting for Hybrid Projects
REPORTING
VISUAL REPORTS
INFORMATION RADIATORS
HYBRID DASHBOARDS
SUMMARY
22 Corrective Actions and Closure
PREVENTIVE AND CORRECTIVE ACTIONS
PROJECT CLOSURE
SUMMARY
23 Making the Move to a Hybrid Environment
ESTABLISH CRITERIA
ESTABLISH THE RIGHT ENVIRONMENT
PROCESS FIRST
Glossary
Index
End User License Agreement
List of Tables
Chapter 4
TABLE 4-1 Project Charter Elements
TABLE 4-2 Dionysus Winery Assumption Log
Chapter 5
TABLE 5-1 Subsidiary Plans
TABLE 5-2 Life Cycle Phases for Publishing a Book
TABLE 5-3 Development Approaches for Dionysus Winery Project
TABLE 5-4 Life Cycle Phases for Dionysus Winery
Chapter 6
TABLE 6-1 Grand Opening Decision Analysis
Chapter 7
TABLE 7-1 Schedule Management Plan Contents
TABLE 7-2 Scheduling Abbreviations
TABLE 7-3 Resource Chart
TABLE 7-4 Responsibility Assignment Matrix
Chapter 10
TABLE 10-1 Estimating Methods
TABLE 10-2 Analogous Estimate Part 1
TABLE 10-3 Analogous Estimate Part 2
TABLE 10-4 Budget Worksheet for the Foundation
Chapter 11
TABLE 11-1 Stakeholder Register
TABLE 11-2 Formal and Informal Communication
TABLE 11-3 Stakeholder Communication Plan
Chapter 13
TABLE 13-1 Sample Motivation Techniques
Chapter 15
TABLE 15-1 Dionysus Winery Risk Statements and Comments
TABLE 15-2 Dionysus Winery Probability and Impact Analysis
TABLE 15-3 Chart with Probability, Impact, and Urgency
TABLE 15-4 Expected Monetary Value Setup
TABLE 15-5 Expected Monetary Value Path Calculation
Chapter 16
TABLE 16-1 Dionysus Winery Risk Register with Responses
TABLE 16-2 Calculating Risk-Adjusted Estimates—Step 1
TABLE 16-3 Calculating Risk-Adjusted Estimates—Step 2
TABLE 16-4 Calculating Risk-Adjusted Estimates—Step 4
Chapter 17
TABLE 17-1 Conflict Resolution Techniques
Chapter 18
TABLE 18-1 Change Management Plan Contents
TABLE 18-2 Change Log
TABLE 18-3 Requirements Traceability Matrix.
TABLE 18-4 Decision Log
TABLE 18-5 Issue Log
TABLE 18-6 Impediment Log
Chapter 19
TABLE 19-1 Schedule Status Table
TABLE 19-2 Material Variances
TABLE 19-3 Labor Variances
TABLE 19-4 Dionysus Winery Cost Estimates
TABLE 19-5 Performance Measurement Baseline Table
Chapter 20
TABLE 20-1 Burndown Chart Table
TABLE 20-2 Burnup Chart Table
TABLE 20-3 Initial Cumulative Flow Diagram Table
TABLE 20-4 Week 4 Cumulative Flow Diagram Table
Chapter 21
TABLE 21-1 Status Report
TABLE 21-2 Earned Value Analysis Report
TABLE 21-3 Stoplight Chart
TABLE 21-4 Chart Summary
Chapter 22
TABLE 22-1 Final Project Report
List of Illustrations
Chapter 1
FIGURE 1-1 Development approach.
FIGURE 1-2 Waterfall approach.
FIGURE 1-3 Iterative approach.
FIGURE 1-4 Incremental approach.
FIGURE 1-5 Agile approach.
FIGURE 1-6 Hybrid approach 1.
FIGURE 1-7 Hybrid approach 2.
Chapter 2
FIGURE 2-1 Radar chart.
Chapter 3
FIGURE 3-1 T-shaped people.
FIGURE 3-2 I-shaped people.
Chapter 5
FIGURE 5-1 Construction project sample life cycle.
FIGURE 5-2 R&D project sample life cycle.
FIGURE 5-3 Dionysus Winery life cycle phases.
FIGURE 5-4 Dionysus Winery roadmap.
Chapter 6
FIGURE 6-1 Dionysus Winery WBS.
FIGURE 6-2 WBS dictionary template.
FIGURE 6-3 Mind map for the Winery Management System.
FIGURE 6-4 Affinity diagram for the Winery Management System.
FIGURE 6-5 Requirement card.
FIGURE 6-6 Winery management system backlog.
Chapter 7
FIGURE 7-1 Network diagram with sticky notes.
FIGURE 7-2 Network diagram in software.
FIGURE 7-3 Resource breakdown structure.
FIGURE 7-4 Resource histogram with resource needs by skill level.
FIGURE 7-5 Resource histogram with resource needs by month.
Chapter 8
FIGURE 8-1 Network diagram view of convergence and divergence.
FIGURE 8-2 Gantt chart view of convergence and divergence.
FIGURE 8-3 Leveling resources.
FIGURE 8-4 Leveling hours.
FIGURE 8-5 Network diagram view of total float and free float.
FIGURE 8-6 Gantt chart view of total float and free float.
FIGURE 8-7 Gantt chart with buffers.
Chapter 9
FIGURE 9-1 Dionysus Winery system development release plan.
FIGURE 9-2 Winery system development iteration plan.
FIGURE 9-3 Sample task board.
FIGURE 9-4 Predictive schedule with releases.
FIGURE 9-5 Predictive schedule with adaptive schedule inserted.
Chapter 10
FIGURE 10-1 Range estimates over time.
FIGURE 10-2 Prioritized backlog for release 1.
FIGURE 10-3 Updated release 1 plan.
FIGURE 10-4 Wideband Delphi with outlier.
FIGURE 10-5 Wideband Delphi with rough consensus.
FIGURE 10-6 Foundation work package network diagram.
FIGURE 10-7 Budget chart for the foundation.
Chapter 11
FIGURE 11-1 Power/support grid.
FIGURE 11-2 Power/support 2 x 3 matrix.
FIGURE 11-3 Stakeholder cube.
Chapter 12
FIGURE 12-1 Four Ls retrospective board.
FIGURE 12-2 Starfish retrospective board.
Chapter 13
FIGURE 13-1 Team charter.
Chapter 14
FIGURE 14-1 Sample probability and impact matrix.
FIGURE 14-2 Risk averse probability and impact matrix.
Chapter 15
FIGURE 15-1 Probability and impact matrix for performance threats.
FIGURE 15-2 Bubble chart with probability, impact, and urgency.
FIGURE 15-3 Decision tree.
Chapter 16
FIGURE 16-1 Risk-adjusted backlog.
FIGURE 16-2 Calculating risk-adjusted estimates—step 3.
Chapter 17
FIGURE 17-1 Thinking as usual.
FIGURE 17-2 Being a critical thinker.
FIGURE 17-3 Problem-solving process.
Chapter 19
FIGURE 19-1 Schedule status Gantt chart.
FIGURE 19-2 Dionysus Winery WBS.
FIGURE 19-3 Performance measurement baseline chart.
FIGURE 19-4 EVM Measures as of August 31.
Chapter 20
FIGURE 20-1 Burndown chart.
FIGURE 20-2 Burnup chart with change in scope.
FIGURE 20-3 Velocity Chart.
FIGURE 20-4 Cumulative flow diagram for the wine club website.
FIGURE 20-5 Cumulative flow diagram with annotations.
FIGURE 20-6 Initial Task Board.
FIGURE 20-7 Task board at week 4.
FIGURE 20-8 Initial Wine Club Member Website Cumulative Flow Diagram Week 4....
FIGURE 20-9 Updated Wine Club Member Website Cumulative Flow Diagram Week 4....
FIGURE 20-10 Mood chart.
Chapter 21
FIGURE 21-1 Sample dashboard.
FIGURE 21-2 Schedule dashboard.
FIGURE 21-3 Line chart.
FIGURE 21-4 Earned value management line chart.
FIGURE 21-5 Stacked area chart.
FIGURE 21-6 Clustered bar chart.
FIGURE 21-7 Stacked bar chart.
FIGURE 21-8 100% stacked bar chart.
FIGURE 21-9 Gauges.
FIGURE 21-10 Scatter diagram.
FIGURE 21-11 Bubble Chart.
FIGURE 21-12 Pie Chart.
FIGURE 21-13 Radar chart.
FIGURE 21-14 Sample Agile Information Radiators.
Guide
Cover Page
Title Page
Copyright
Acknowledgments
Introduction
Table of Contents
Begin Reading
Glossary
Index
Wiley End User License Agreement
Pages
iii
iv
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
HYBRID PROJECT MANAGEMENT
Cynthia Snyder Dionisio
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, (978) 750‐8400, fax (978) 646‐8600, 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 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 (800) 762‐2974, outside the United States at (317) 572‐3993 or fax (317) 572‐4002.
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 Applied for
Paperback ISBN: 9781119849728
Cover Design: Wiley
Cover Images: © Botond1977/Shutterstock;
BNMK 0819/Shutterstock; iam2mai/Shutterstock
Acknowledgments
How do you express gratitude for all the people over 25+ years who have contributed to your knowledge and skills in project management? In my years of practicing, teaching, and writing about project management I have come across thousands of practitioners and professionals. While there are far too many to note, I would be remiss if I did not acknowledge a few people who have helped me in my career and with this book.
I have learned more about project management by teaching than I did by practicing. It is in the teaching that I have improved my own skills. Thus, I am very grateful for the thousands of students who allowed me to contribute to their knowledge and careers, as it has helped me become a better project leader and course facilitator.
Of course, I could not reach students without the organizations that hired me to teach. In particular I would like to acknowledge my friend and colleague Teidi Tucker at Management Concepts for a personal and professional relationship that has spanned over 20 years. You are such a delight!
I am grateful to Amy Sell, Dianne Starke, and all of the wonderful people at LinkedIn. I learned a lot about hybrid project management by developing a course for LinkedIn Learning. Thank you for that opportunity!
LaVerne Johnson and Amy Gershen with the International Institute for Learning were some of the first people I worked with in a training environment and are wonderfully supportive in my current role as Practice Lead. I appreciate you both.
Over my career I have spent thousands of hours volunteering with the Project Management Institute (PMI). I am so very grateful for the leadership roles PMI has entrusted to me. Past and present friends and colleagues include Stephen Townsend, John Zlockie, Dani Ritter, Kristin Vitello, Marv Nelson, Barbara Walsh, and Roberta Storer. The teams that guided the fourth, sixth, and seventh editions of the PMBOK® Guide are some of the best professionals in the business. Each person expanded my knowledge and understanding of the full range of project management. I have to give a special shout out to Larkland Brown. His willingness to read parts of this book and provide sage advice have definitely improved the quality of the content.
The professionals at Wiley are among the best in the business. I am so grateful to have published numerous books with Wiley and the For Dummies folks over the years. Kalli Schultea and Amy Odum have been a delight to work with on this and many other books.
It would not be possible to thrive in this profession without the support of my loving family. Pad, Mombat, and Bunny, you are all the best and always in my heart.
Introduction
Project managers make progress, change, new ideas, new technologies, and breakthroughs possible. We are a part of every profession and have proven our value through our leadership, ingenuity, courage, and discipline. We have been delivering value to organizations, governments, military, and nonprofits since before there was a profession called project management.
In the 1980s and 1990s project management was primarily linear and process driven. There was a heavy emphasis on planning, managing, and controlling project work. We were process driven and documentation heavy. Staying true to the plan, limiting scope changes, and adhering to baselines were the primary means by which we executed and controlled our projects. This approach has come to be known as a waterfall approach because we managed our projects one phase at a time in a linear fashion.
By the late 1990s it was becoming clear that this approach worked in some situations, such as building a bridge, but was a recipe for failure in other situations, such as developing software. In 2001 a group of 17 software developers met at a mountain resort and came up with a new approach that was based on four values and 12 principles. They recorded the values and principles in a document called the Agile Manifesto.
The Agile Manifesto moved away from heavy up‐front planning and embraced evolving scope, collaborative working relationships, and servant leadership. The practices, mindset, and overall approach to creating deliverables was 180 degrees from the waterfall methods.
As with most new approaches, some people embraced the practices and mindsets wholeheartedly. In fact, some practitioners became rather evangelical about the Agile mindset and were termed Agilistas. Other practitioners were more along the lines of “Agile in name only.” In other words, they used the Agile terminology but did not fully embrace the mindset. Today the majority of the Agile practitioners conform to Agile practices but perhaps aren't as fanatical about their implementation as the Agilistas.
Twenty years after the Agile Manifesto was first developed, there are many practitioners who find value in the waterfall approach and the Agile approach. These practitioners recognize there are many variables that determine which method to use and that there is rarely a need to be on one end of the spectrum or another. They see significant value in embracing both approaches, using waterfall techniques for some deliverables and Agile techniques for other deliverables. We call this “hybrid project management.”
Hybrid project management is about being flexible enough to assess the project, deliverables, environment, and stakeholders to determine the best means to achieve the intended outcomes. Many hybrid projects use a waterfall framework at a high level and apply Agile approaches to specific deliverables as appropriate. It is my opinion that while the servant leadership practice that is a hallmark of Agile is not fully utilized in all hybrid projects, the practice of engagement, collaboration, and facilitation is more prevalent than the command‐and‐control perspective that was common in the 1980s and 1990s. Thus, we see the industry moving away from the far ends of the project management spectrum and more toward a practice that is inclusive of the best practices from each approach.
This book is intended to present a variety of ways to deliver projects. Whether you are a new practitioner or someone with decades of experience, it is my hope that you will find some new ways of practicing our discipline and discover some new techniques you can apply on your projects.
1Introducing Project Management
As professional project managers it is no longer enough to deliver results that conform to requirements and are on time and on budget. Our role in driving change and transformation, developing new products and updating existing products, creating new technologies and finding ever‐better ways of doing things has evolved. Now we need to be more business savvy, market responsive, and aware of how our profession is changing and progressing.
Value: Something of worth or importance.
Deliverable: A component or subcomponent of a product or service. A deliverable can be stand alone, or part of a larger deliverable.
One of the most significant changes in our profession is the recognition that as professionals we must understand and embrace different ways of delivering value. After all, the whole purpose of projects is to bring value to stakeholders, whether that value is via a new product, a new service, or more efficient processes. Different project deliverables require different approaches and techniques. To excel in our role, we need to know our options for delivering value and understand the variables that determine the best fit for each deliverable.
In this chapter we will describe four ways of creating deliverables and define terms associated with each approach. Next, we will identify the variables you need to consider in order to select the best development approach for each deliverable in your project.
THE SPECTRUM OF DEVELOPMENT APPROACHES
A development approach refers to how the project team creates and evolves deliverables. Some development approaches emphasize understanding all the requirements before designing a solution and then creating the deliverables based on the solution design. Other development approaches start with a bare‐bones deliverable and evolve the solution based on feedback. They are different approaches to creating project deliverables.
Development approach: The means by which the project team will create and evolve deliverables.
Warning! A development approach is not a life cycle. We will cover life cycles in Chapter 5.
In this chapter we will describe four development approaches:
Waterfall;
Incremental;
Iterative; and
Agile.
A waterfall development approach is what we call predictive. In other words, we like to be able to predict the schedule and budget based on stable scope. Incremental, iterative, and Agile development approaches are adaptive, which means they are flexible enough to allow changes in requirements and scope.
Adaptive: An approach for creating deliverables that allows for uncertain or changing requirements.
Predictive: An approach for creating deliverables that seeks to define the scope, schedule, and budget toward the beginning of the project and minimize change throughout the project.
FIGURE 1‐1 Development approach.
Waterfall
A waterfall development approach is predictive in nature. In other words, it starts with well‐defined scope, which the project team then progressively elaborates into greater levels of detail. The work is then sequenced, duration and cost estimates are developed, and eventually a baseline is set. Throughout the project, progress will be measured against the baselines. With a waterfall approach the project manager endeavors to keep change to a minimum and follow the project plan.
Waterfall: A predictive approach for creating deliverables that follows a linear pattern of completing one phase of work before starting the next one.
Figure 1‐2 shows a life cycle for a light rail project that would use a waterfall approach. You can see how one phase completes before the next one begins, and the shape of the graphic looks like a waterfall. In the Environmental Impact Analysis phase, studies on expected site impact, materials analysis, geological surveys, life cycle assessment, and similar work would be conducted. In the Plan phase, detailed resource, budget, schedule, communication, risk, and other plans would be developed. At the end of the Plan phase those plans would be baselined. The Engineering phase would be comprised of blueprints, architecture, modeling, and other similar work to ensure the designs meet the needs, are compliant with regulatory requirements, and are minimally disruptive to the environment. The Construction phase is where all the physical work is carried out. It is the most visible, uses the most budget, and likely takes the longest. Progress in the Engineering and Construction phases would be compared to the baselined plans to ensure the project stays on schedule and on budget.
FIGURE 1‐2 Waterfall approach.
A waterfall approach is best when the requirements can be defined up front and when the scope of the project is not expected to change. This approach is often used for projects with large budgets, where detailed planning can help reduce uncertainty and risks. Projects that have high‐risk deliverables or have significant regulatory oversight are also a good fit for a waterfall approach.
Types of projects that use a waterfall approach include:
Construction;
Defense projects such as building a new aircraft, ship, or tank;
Medical devices; and
Infrastructure including roads, bridges, or mass transit.
Iterative
An iterative approach is adaptive in nature. It is used when there is a high‐level understanding of the desired outcome, but the best way to achieve that outcome is not defined. The project team uses a series of iterations to get clarity on the best method to deliver results.
Iterative: An adaptive development approach that begins with delivering something simple and then adapts based on input and feedback.
Iteration: A brief, set time interval in a project where the team performs work. Also known as a timebox or sprint.
An iterative approach could be used for designing a new multipurpose bicycle. It might start with an idea on a drawing board that can be shown to key stakeholders for feedback. Once the stakeholders are happy with the design, the team may use cheap materials to build a cheap frame mock‐up that people can look at and sit on to provide more feedback. Once the frame shape is settled, the next iterations can focus on finding the right materials. The right materials affect the ride, price, weight, handling, and expected life span.
When the frame size and materials are decided on, the team can conduct iterations to determine the best gears, brakes, and other componentry. Only when the team has incorporated all the relevant feedback will they finalize the design, materials, and specifications so they can go into production.
Figure 1‐3 shows a generic example of an iterative approach. Notice that each iteration provides information to the next iteration. The number of iterations depends on the feedback and when the decision makers agree that the final iteration will meet the objectives of the project.
FIGURE 1‐3 Iterative approach.
An iterative approach may be used in conjunction with Agile methodologies, especially for software development; however, there are many other usages in addition to software development. Types of projects that could use an iterative development approach include:
New product development;
Software development; and
Marketing campaigns.
Incremental
An incremental approach is adaptive in nature. It is used when the end product can be decomposed into smaller components and deliverables can be deployed incrementally. Each increment learns from previous deployments and adds or improves features and functionality of the deliverables.
Incremental: An adaptive development approach that begins with a simple deliverable and then progressively adds features and functions.
An incremental approach might start with an idea and build a basic version of the idea and release it. After release, the team would gather feedback, such as how people use the product, which features they use the most, which features they don't use, and the number of calls for support. This feedback informs the next increment for release. Depending on the product, the team may add a new component or might upgrade software.
This approach could be used to develop an online learning course. The first increment could include slides that can be accessed online and a PDF document that can be downloaded. These two elements might be what is called a minimum viable product. In other words, it has just enough features that people will buy it. Some customers may provide explicit feedback on the product. However, because the product is online, customer behavior can be monitored to indicate how much time they spent with each feature, which ones they returned to, and when they logged out.
Minimum viable product: The first release of a product that contains the least number of features or functions in order to be useful.
Based on feedback, the next increment could include built‐in exercises, quizzes, and interactive activities. This would be released, and more data would be collected. The next increment might include videos, audio clips, or threaded discussions. Development and upgrades would continue until a decision was made that the product was complete.
Notice with this incremental approach that the team releases a product that is complete with each increment. They don't have to wait until the whole product is done or integrated before it is released. This allows the team to learn rapidly and update their plans based on stakeholder feedback.
Figure 1‐4 shows a generic example of an incremental approach. This example shows four increments, where each increment would add more functionality.
An incremental approach is often used with Agile methodologies for software development, though that is not the only use for an incremental approach. Types of projects that could use an incremental development approach include:
Customer loyalty programs;
Application development; and
Online learning.
FIGURE 1‐4 Incremental approach.
Agile
As mentioned in the introduction, Agile is a mindset based on values and principles. There are several frameworks or methodologies that incorporate those values and principles. They all include iterative development and continuous feedback. This book won't espouse one methodology over another but rather will address Agile as an approach for developing deliverables.
Agile: An adaptive way of delivering value by following the four values and 12 principles established in the Agile Manifesto.
Iterative and incremental approaches are used with Agile; however, the iterations or timeboxes are very short, usually one, two, or four weeks in duration. At the end of every iteration (sometimes called a timebox or a sprint), the team demonstrates the work they have accomplished to key stakeholders. Stakeholders provide feedback, and a backlog of features and functions is then prioritized for the next iteration.
Agile approaches have several unique aspects to them that will be described throughout this book, such as different roles, meetings, prioritization methods, and scheduling.
An example of using an Agile approach could be a county that wants to understand how its residents are using its parks and open spaces. They could build an application that pulls data from online searches, educational programs, surveys, parking meters, vendors, and other data sources. The application would compile data from these various sources and make it searchable, create tables, charts, dashboards, and other tools. This information could help the county for staffing, planning, and resident satisfaction.
The team would start with this high‐level concept and a list of features and functions the customer has asked for. The customer would prioritize the work, and the team would determine which of the prioritized features they could get done in the coming iteration. At the end of the iteration they would demonstrate their work, receive feedback, and move onto the next iteration. At some point, they would have enough features and functions built that they could release the application for use. If needed, they could add more functionality in later releases.
This example could use iterative practices to evolve the various aspects of the application, such as the dashboard behavior. It could also use incremental practices to release some of the functionality, do more work, release more functionality, and so forth.
Figure 1‐5 shows a generic example of an Agile approach. Each sprint uses feedback from the previous sprint to plan and develop the upcoming sprint.
FIGURE 1‐5 Agile approach.
HYBRID PROJECT MANAGEMENT AND DEVELOPMENT APPROACHES
A hybrid approach uses some predictive and some adaptive approaches. Expanding on the iterative example of developing a new bike, the design of the bike could use an iterative approach and then when preparing for manufacturing and later distribution, they could use a waterfall approach. The design aspect of the bike uses feedback to ensure the bike is meeting the needs of potential customers. The manufacturing and distribution require up‐front planning and a stable set of requirements.
Hybrid project management: A blend of predictive and adaptive approaches to delivering value, determined by product, project, and organizational variables.
FIGURE 1‐6 Hybrid approach 1.
Developing a new sports watch could use an iterative approach for the software part of the watch and waterfall for the hardware part of the watch. As people use the watch, they can make requests for new or modified features, which can be deployed as updates to the watch operating system, but the physical watch itself won't change. Figure 1‐7 shows a waterfall approach that includes outsourcing the manufacture of the watch.
Finding the right contractor and going through the contracting legal work is part of the project. Once it moves to manufacturing, the hardware part of the project will be complete. As the work for the watch hardware is happening, the team can incrementally develop features and functions for the watch. By the time the manufacturing is ready to begin, the software should have gone through a few iterations and be ready for deployment.
The different development approaches usually work well with specific practices and ways of working. This book will point those out, but the beauty of hybrid project management is that you can tailor, mix, and match to meet the needs of your project, environment and stakeholders.
FIGURE 1‐7 Hybrid approach 2.
SUMMARY
In this chapter we introduced key concepts and terminology for hybrid project management. We looked at four different ways to create deliverables:
Waterfall;
Iterative;
Incremental; and
Agile.
We also looked at hybrid project management as a way to combine or mix and match those development approaches to meet the needs of the project.
Key Terms
adaptive
Agile
deliverable
development approach
hybrid project management
incremental
iteration
iterative
minimum viable product
predictive
value
waterfall
2Choosing a Development Approach
Choosing a development approach for deliverables in your project requires familiarity with the various options (waterfall, iterative, incremental, and Agile), an understanding of the product, and contextual information about the project and organization. While there isn't a neat and precise way to come up with the perfect approach for each deliverable, there are some guidelines that can help you evaluate the right approach for your project.
In this chapter we will look at how product variables, project variables, and the performing organization can influence the selection of a development approach.
PRODUCT VARIABLES
It makes sense to start with the product variables since these relate to the scope and outcomes the project will deliver. We'll review eight product variables to consider when evaluating the best development approach for each deliverable:
Innovation;
Scope stability;
Requirements certainty;
Ease of change;
Risk;
Criticality;
Safety; and
Regulatory.
With each variable, I'll describe ways a hybrid approach can be used.
Innovation
Innovation takes into consideration the degree to which the technology and methods you will use on the project are new and untested versus known and standardized. Using methods and processes you are familiar with is conducive to waterfall approaches. Cutting‐edge technology or experimental processes work better with adaptive approaches.
A project to repave eight neighborhoods does not require any innovation. The technology and methods are well known, so a project like this works well with a waterfall approach. Conversely, a project to build a battery that can last for 10 years in 0 gravity requires significant innovation. Therefore, this type of project would work well with iterative and incremental approaches. The team would require a lot of creativity and the ability to experiment and try different ways to achieve the intended result.
Hybrid options: A hybrid approach is good if you have some deliverables that are known and some that are newer. You can also use adaptive methods until you have tested the technology and are comfortable with it and then move to processes that support a known technology.
Scope Stability
How likely is your customer to change their mind, add new features, or request something different? If you are working on a project where the scope is fixed and unlikely to change, such as installing landscaping in a housing development, you can use a waterfall approach. In contrast, if your customer is fickle or has a lot of new ideas they want to try out, such as rebranding a product line, then you should consider one of the adaptive approaches.
Hybrid options: You may be working on a project where some deliverables are stable and some are subject to change. In these circumstances the flexibility of a hybrid approach is a good choice. Another option is to use adaptive methods until the scope has stabilized and then implement more of a waterfall approach.
Requirements Certainty
Requirements certainty is related to scope stability, but it is a bit different. The scope is what you are delivering, the requirements are the capabilities that must be present and conditions that must be met to achieve the project objectives.
Requirement: A capability that must be present or a condition that must be met to achieve the project objectives.
Some projects have very clear requirements from the start, for example, install a three‐story parking garage that can hold 500 cars. Clear requirements lend themselves to waterfall approaches.
Many projects don't know all their requirements at the start. The team expects the requirements to evolve and new requirements to be added throughout the project. A project to establish a concierge service for a high‐end credit card might start out with some high‐level concepts and ideas, but as the service is rolled out, those requirements might evolve and change based on user requests and feedback.
Hybrid options: Using an adaptive approach to test different requirements or requirement sets is a good way to start a project when the requirements are uncertain or subject to change. Once there is more certainty, you can transition to more of a waterfall approach. You can also document and manage requirements that are certain, while using adaptable methods to stay flexible with those that could evolve.
Ease of Change
Change is a way of life, especially on projects. But not all projects absorb change easily. A project to create an electronic performance dashboard can absorb changes in scope or requirements fairly easily. This type of project fits well with an adaptive development approach.
A project to build a bridge does not respond well to change. For this type of project, you want to make sure you have all the specs correct before you start construction because any change could be very time‐consuming and costly! Therefore, you would want to use a waterfall approach where you lock in your scope and designs prior to starting construction.
Hybrid options: To address projects where some deliverables are easy to change and some aren't, you can split out those deliverables that are easy to change and manage them using adaptive approaches and manage those that are not easy to change with a rigorous change control approach that is the hallmark of waterfall approaches. Another option is to make decisions and allow changes as late in the project as possible and then lock down the product so no more changes can occur after a certain point in time.
Risk
The type of risks on a project indicates the most appropriate risk responses. Risk responses for risks associated with product acceptance or new technology can include using an adaptive development approach. An adaptive approach allows the team to experiment and develop prototypes and then evolve the product based on the outcomes and feedback.
Risk: An uncertain event or condition that can have an impact on a project.
For projects with risks associated with safety or where you can't fix something once it is complete, a waterfall approach is best. For example, if you are launching a satellite, once it is launched you can't redo or rework something; therefore, the up‐front planning and robust risk management that is used in a waterfall approach is best.
Hybrid options: Risk management and responses are necessary regardless of the approach used; however, the type of response can vary. Therefore, a hybrid project will have a variety of options for responding to risk. The rigorousness of the risk management process can flex depending on the type of risks that are present in the project.
Criticality
Criticality deals with the relative importance of a component, deliverable, or project. For example, there is a high degree of criticality with maintaining the power for hospitals. A component or deliverable with a high degree of criticality usually indicates a waterfall approach is best. A component that is easy to replace and does not have a significant effect if it fails may work with an adaptive method. For example, a project to implement an online ordering system would have a requirement to send an automated email confirming the order. If this function fails, it is relatively easy to fix, and no one will be harmed if they don't get the confirmation email.
Criticality: The importance of a component, deliverable, or project.
Hybrid options: If you have a variety of deliverables or components and some are critical and some aren't, determine at the outset which deliverables require the degree of planning, testing, and documentation necessary for critical deliverables. For those deliverables that are not critical, you can use less intensive processes.
Safety
When safety issues are involved, most projects rely on a waterfall approach. For example, projects that develop implantable medical devices have significant safety concerns. They require the planning, documentation, and testing that is common in waterfall projects. Conversely, a project to update a gaming application on a smartphone doesn't have a lot of safety issues, and so an adaptive approach would work well.
Hybrid options: Usually not every deliverable for a project has safety impacts. For those deliverables that clearly have no safety impacts, you can use an adaptable approach while maintaining robust planning, documentation, and testing for those deliverables with safety concerns.
Regulatory
Many projects are done to achieve or maintain regulatory compliance. This can include plant inspections for facilities that work with hazardous materials or educational institutions that need to maintain compliance with accreditation requirements. Most regulatory agencies want to see detailed documentation and rigorous policies and procedures that demonstrate compliance. These projects use waterfall approaches. Where there isn't a need to demonstrate compliance or alignment with regulatory agencies, both waterfall and adaptive approaches are valid.
Hybrid options: In the event that only some aspects of a project have regulatory considerations, separate those aspects with regulatory concerns from those without. Invest in the required amount of policy, process, and documentation for those deliverables with regulatory requirements and relax the processes and documentation for deliverables without regulatory requirements.
PROJECT VARIABLES
Project variables that influence the development methods include:
Stakeholders;
Delivery options; and
Funding availability.
Stakeholders
Projects have a wide range of stakeholders, some of which will be well known to the project team, such as the sponsor or product owner, and some that the team will never meet, such as certain end users or members of the public. One of the strengths of Agile methodologies is the access to key stakeholders. In a purely Agile environment, key stakeholders, such as the product owner, are available to the team to answer questions and protect the team from interference. They review work at regularly scheduled intervals, such as demonstrations every two weeks, and they prioritize features in a backlog. Thus, for projects that use Agile methods to develop products, access to key stakeholders is a necessity.
Projects that use waterfall methods usually have less need of and less access to stakeholders. Obviously, there is some interaction, but it is not as consistent or frequent as in Agile projects.
Hybrid options: If you are working on a project where some deliverables are using adaptive methods, you will want to stay in close contact with the appropriate stakeholders on a regular basis. For those aspects of the project that are developed with waterfall approaches, a monthly status report should be sufficient. You can apply hybrid methods by summarizing the adaptive information in the monthly status report that goes to management.
Delivery Options
Does your project have one main deliverable, or can it be decomposed into multiple smaller deliverables? Do all the deliverables have to be released at the same time, or can they be released in batches? The answers to these questions will point you in the right direction for choosing a development approach.
Typically projects with one delivery at the end use a waterfall approach so you can plan the development, testing, and delivery. A project to build a new hotel is an example of a project with one main release. Projects where you can work on several different deliverables but bring them together before release work well with an iterative approach. A project to update a payroll system might have multiple components, but they all have to be integrated before release. Projects that have periodic deliveries, such as a website, work well with incremental approaches.
Hybrid options: For projects with multiple deliveries that are developed using adaptive methods along with some deliverables that use waterfall methods you can support the adaptive development by having a scrum master work with the adaptive team. The scrum master can liaise with the project manager for the overall project and provide status information, milestones, and delivery dates, which can be incorporated into a waterfall framework and schedule.
Funding Availability
Many projects that are involved with new product development, especially digital products, will start with a small budget, and as the product gains market share and becomes profitable, they will add features and functions. This business model essentially uses the profit from the product to fund future upgrades and enhancements. This model is often used with Agile projects or projects that use iterative approaches. The up‐front investment is comparatively minimal, and if the product doesn't do well, the project is cancelled with minimal loss of investment. This model can also be used if there is uncertainty about the amount or timing of funds. An Agile approach allows the team to deliver some value for the investment, even if not all the objectives are realized.
Multiyear projects with large budgets need to consider funding availability. Some projects are constrained by fiscal year funding, necessitating planning around the availability of funds. If there is only one large deliverable at the end, a waterfall approach is often used, and work is planned around funding availability.
Hybrid options: The most common hybrid scenario for this variable is when a new product idea is envisioned and the market is tested using adaptive methods. If/when the decision is made to move forward and more stable funding is available, the development and delivery can be scaled up using waterfall methods.
ORGANIZATION VARIABLES
Organizational variables should match with the preferred development method, or the project will struggle to be successful. Four organizational variables to pay attention to are:
Structure;
Culture;
Project team; and
Experience and commitment.
Structure
There is a broad spectrum of organizational structures that range from hierarchical to matrix to flat. A hierarchical structure has lots of layers of management, and often the functions are siloed. This type of structure usually has a robust set of policies and procedures, and the communication and interaction between functions may be limited. Projects that use a waterfall approach do better in structures like this than Agile projects. The exception is if a particular function, or group of functions, such as IT, employs Agile methods.
Organizations that are flatter and more responsive to change and adaptation are where adaptive project management practices thrive. There are less layers of bureaucracy that require approval, and development is usually more nimble.
Hybrid options: Agile methods don't work well in bureaucratic environments. However, where it makes sense, you can still use some of the methods and techniques found in Agile projects, such as daily stand‐ups and task boards.
There are also some organizations that employ Agile practices in some disciplines (such as IT), and other disciplines are primarily waterfall. If your project has team members that are used to different development approaches, you can blend approaches and educate your team about the benefits of each development approach.
Culture
Company culture is a big determinant in choosing the best way to manage a project. Projects that use Agile methods are based on a climate of trust, where the team is empowered to make many of the decisions about the project. They establish their ways of working, communicating, troubleshooting, and so forth. Agile teams are often self‐managing, without a specific designated leader. This way of working will not work in a highly bureaucratic or “command and control” environment.
Conversely, a project that requires a lot of documentation, sign off on decisions, rigorous processes, and so forth, will do well in a hierarchical environment but will not fit as well in a flatter organization. One of the reasons many organizations struggle or fail in implementing an Agile methodology is that the company culture does not match with Agile ways of working.
Hybrid options: Unless you are working on an organizational transformation initiative, changing the company culture to adopt different ways of working on projects is likely not part of your project scope. However, you can introduce a few techniques from different approaches. For example, in a waterfall environment you can schedule tasks for prototyping and experimentation. In an Agile environment you can include milestones, status reports, and maybe even talk about a critical path for a release. By infusing a few practices from different development methods you can soften resistance to different ways of working and help people see that different approaches can be productive.
Project Team
The size and location of project team members influence the development approach. Agile methods work best with teams that are 5–10 people who are collocated (in the same space). While you can apply Agile methods with larger groups, or with virtual teams, it is more challenging. Agile teams have daily stand‐up meetings, and much of their collaboration takes place in one‐on‐one conversations—preferably with a whiteboard nearby to capture ideas. These practices are more challenging when you have more than 10 team members or if team members are in different locations, especially if they are in different time zones or different countries.
Large teams work better with the structure of a waterfall project. There are fewer meetings, much of the documentation is electronic, and dispersed team members are not uncommon.
Hybrid options: For a large team that wants to use Agile practices, you can adopt one of the Agile at Scale methodologies, such as Scaled Agile Frameworks (SAFe), Large Scale Scrum (LeSS), or Scrum at Scale (SaS). You can also back off some of the practices that are more challenging with a large or dispersed team, such as daily stand‐ups. Another option is to move much of the data that is usually visible in the team room, such as task boards and burn charts to an electronic location.
On large projects with multiple deliverables, you may find it useful to manage the overall project using a waterfall framework, while some team members use adaptive processes and others use waterfall practices.
