adaptability and resilience
Even with clearly defined requirements, engaged stakeholders, a competent and experienced project team, and sufficient time and budget, you’ll find that projects rarely go exactly as you planned. This isn’t to say that you’ll never come close to your original plan. We are confident that you will, but there will likely be some deviation at some point throughout your project. This is perfectly fine; it is even expected.
Your success as a project manager won’t (at least, it shouldn’t!) be measured by your ability to deliver to the exact plan that you laid out at the outset of your project. This isn’t realistic and, frankly, the purpose of your project isn’t to demonstrate that you can stick to a plan. Your project’s purpose is to deliver value, in the form of your intended outcomes, whatever they may be, as defined by your stakeholders.
Just as no two projects follow the exact same course, rarely are the circumstances around two projects ever identical. If you routinely manage projects to configure, test, and deliver the same software application, your work breakdown structure (WBS) might be very similar, but each of these projects will likely be performed for different clients, or at different times, or with a different project team. At different times of the year, the exact same project may be subject to different resource constraints. For example, you may have more difficulty lining up consistent resources in the summer months when people often go on vacation. You may have similar difficulty during the holidays in December and into the new year.
With different clients come different requirements and expectations. Where one client may want to be hands-off and largely uninvolved until you’re ready to deliver the final product, other clients may want daily meetings to review progress and participate in technical design sessions. All of this boils down to the need to be adaptable when designing your project development approach.
Tailoring is the process of designing your approach based on the context of each project, each set of objectives, each group of stakeholders, and so on. Acknowledging that every project is unique will force you to keep an open mind as you determine the proper approach to each one.
Thinking holistically and enabling change
Projects are fundamentally systems of intertwined and interdependent subsystems or components that must function together and interact as an integrated unit to yield the intended outcomes. Adopting this approach to systems thinking (and helping your team appreciate it) enables the following outcomes:
Flexibility during the project when assumptions and plans need to change
Ability to minimize the overall impact of changing needs and expectations
Better alignment of project objectives with customer and organizational goals and objectives
More comprehensive, informed, and timely risk identification
Ability to realize synergies between aligned projects, project teams, and initiatives
We often discuss change, in the context of project management, as something that needs to be monitored closely and controlled to ensure project success. We do this for multiple reasons, including:
Change in scope can lead to missed milestones and increased costs.
Change that isn’t clearly documented can result in miscommunications and mismanaged expectations.
Change can make people uncomfortable, so we typically strive to maintain the status quo.
The Agile project management methodology, for example, was first conceptualized only slightly more than 20 years ago (see Chapter 18 for more on Agile). This fundamental change to the field of project management eventually required practitioners to evolve or be left behind.
As a principle of project management, change refers to the necessary mindset to ensure the acceptance and adoption of your project’s outcomes. If your project is to develop a new widget, the end users of that widget will need to change how they currently operate to effectively utilize your new widget. Change management is a discipline in and of itself. It’s no longer a nice-to-have, but rather a must-have, when considering the introduction of any substantial organizational, systemic, or otherwise impactful change.
What Happened to Process Groups and Knowledge Areas?
You may be wondering, now that we’ve reviewed the new project management principles, whether the process groups and knowledge areas from prior PMBOK editions have disappeared entirely, never to be mentioned in the context of project management again? Well, of course that isn’t the case! While many terms have changed and concepts have been updated, it is important to retain an appreciation of the way things were, because you never know when it’ll prove valuable to you.
Figure 1-2 is a straightforward and comprehensive mapping of PMBOK 7 performance domains with PMBOK 7 project management principles, PMBOK 6 life cycle phases, and PMBOK 6 knowledge areas. This matrix view shows where each of these concepts intersect.
We won’t go into nearly as much detail on performance domains as we have on project management principles in this chapter. The performance domains are applications of the project management principles over the course of a project. Principles are closely correlated to the performance domains and, in fact, many principles even share similar names as their corresponding performance domains. The principles of project management are intended to guide the behaviors exhibited through each of the project performance domains.
