Stanley E. Portny - Project Management For Dummies

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.

Tailoring is an iterative process. You may kick off your project with a solid approach, but don’t assume that approach will remain optimal through project closure. As your project progresses, external factors can change that might warrant or even necessitate a revised approach.

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.

Change shouldn’t be feared and its negative connotation is often undeserved. When communicated, socialized, and managed properly, change is necessary for survival (it’s even given a fancy name like “evolution”). Similarly, if you intend to remain relevant in your industry, as a project manager or any other role, you need to adapt and evolve to accommodate the unavoidable and unexpected changes around you.

The Agile project management methodology, for example, was first conceptualized only slightly more than 20 years ago (see Chapter 18for 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.

While change can be good, don’t forget the adage that it’s possible to have too much of a good thing. It is critical to approach change in a controlled and logical manner. Changing too much too quickly can either create excess confusion and chaos or it can elicit anxiety and rigidity among the people you need to adopt the change for you to succeed. As with many things in life, change is best in moderation!

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.

Figure 1-2 indicates the most common intersections between the performance domains along the top row and the principles, phases, and knowledge areas down the first column, but don’t assume that these concepts cannot interact with each other differently for different projects, performed under different circumstances at different times. They most definitely can! We are confident that, after reading this book, you’ll be equipped to assess these interactions and apply them to your projects.

© John Wiley & Sons, Inc.

FIGURE 1-2:Mapping principles, phases, and knowledge areas to performance domains.

You’re reading this book because you want to be a better project manager, right? Well, before you jump in much further, we suggest you do a quick self-evaluation to identify your strengths and weaknesses. By answering the following ten questions, you can get an idea of what subjects you need to spend more time on so you can be as effective as possible. Good luck!

1 Are you more concerned about being everyone’s friend or getting a job done right?

2 Do you prefer to do technical work or manage other people doing technical work?

3 Do you think the best way to get a tough task done is to do it yourself?

4 Do you prefer your work to be predictable or constantly changing?

5 Do you prefer to spend your time developing ideas rather than explaining those ideas to other people?

6 Do you handle crises well?

7 Do you prefer to work by yourself or with others?

8 Do you think you shouldn’t have to monitor people after they’ve promised to do a task for you?

9 Do you believe people should be self-motivated to perform their jobs?