Viewing Posts by Laura Schofield
How did you become a project manager? Chances are you “stumbled into it” in the course of your job, but now it’s become your career.
As we move through this uncertain time and into what the future holds, project managers will continue to be in high demand as corporate and government entities plan projects to adapt to new ways of working and living. That’s why its more important than ever to understand how PMs become PMs, and how they progress in their career paths.
The latest issue of the Project Management Journal takes a close look at project management careers. It features research that identifies how project managers enter into, and progress within, the profession. The journal is a peer-reviewed academic journal published by the Project Management Institute (PMI).
The April 2020 issue of the journal opens with what we know about the project management career path, and why we need to know more. Project manager careers are often accidental, cross-occupational, and eclectic. Building our knowledge helps PMs plot more productive and satisfying career paths, and helps organizations foster their talent in order to benefit from more successful projects. This opening editorial is open access, which means it is available for anyone to read.
Articles in the issue investigate: the benefits of integrating project management with career studies; students’ readiness for project work; graduates’ readiness for project work; project manager competencies; factors that predict career success among project managers; and factors that stall careers. If you’re a member of PMI, access to all content in the journal is a benefit of your membership. Many universities and other academic institutions also have subscriptions to the journal.
You can find this special careers issue of the journal at https://journals.sagepub.com/toc/pmxa/51/2
by Nick Clemens, PMBOK® Guide–Seventh Edition Development Team member
Focus is a key part of successfully leading project teams and managing projects. A Guide to the Project Management Body of Knowledge (PMBOK Guide®)–Seventh Edition outlines eight interdependent areas of focus or performance domains that combine to form the project management delivery system. Through this system, projects deliver outputs (products and services) that provide benefits and deliver value to our customers and organizations. These performance domains cover, Stakeholders, Teams, the Life Cycle, Planning, Project Work, Delivery, Uncertainty, and Measurement. Let’s look more closely at the Project Delivery Performance Domain.
The Project Delivery Performance Domain focuses on meeting requirements, defining scope, and quality expectations and driving results to meet intended outcomes. It is the correct elicitation and interpretation of requirements that lead to good scope definition and meeting customer quality expectations. In the next few paragraphs, I will briefly look at each of these elements focusing on requirements.
As project managers, we not only want to “build the product right,” i.e., building our deliverable correctly or according to specification, but we also want to “build the right thing,” i.e., deliver the output that enables the outcome expected by our customer. By building the right thing, we deliver what our customers need, which then drive the benefits to value delivery train. Requirements fall into two broad categories, those dealing with managing the project and those associated with defining the deliverable. Here I will focus on requirements related to the deliverable.
First, every project creates something unique. There are always unknows at the start of any project. The amount of unknows and the deliverable drive the type of project approach used. Under a predictive project approach, most product requirements are defined near the beginning of a design effort. On the other hand, most agile approaches use multiple deliveries over time, where requirements are also defined over time with each iteration. In both cases, the goal is the same, to deliver or build the right thing to meet our customer’s needs and expectations.
Second, building the right thing is the hard part of interpreting requirements. Language and meaning may not always be precise. I may express what I want, but the person I am talking to may not understand precisely what my needs are. For example, I may express to my associate that all effort should be taken to deliver the new product by the end of the quarter if practicable. In this case, complete understanding rests with how my associate interprets the words “if practicable.” I may express what I want, but my associate may interpret those requirements through a different lens than mine. We may think we have a common understanding but find that we mean different things. The same is true of our project teams, and the situation is made more complicated by the fact that we usually deal with multiple individuals and customer teams from different organizations.
Lastly, we need to understand that not all requirements are the same. Some requirements are high-level and relate to the project’s business case. Other requirements are user-level or related to customer needs and wants. Finally, requirements may also be at a lower or design level. These lower-level requirements deal with product design and specification. Building the product right relates to meeting these low-level specifications and standards. Usually, a good design team will get this right. However, a quality control effort should be in place to assure adherence to standards. As outlined above, making sure you build the right thing relates directly back to understanding your customer needs and desires. Here is where user or product level requirements come in. At this level, the project manager and the team deal with customer expectations. The customer’s expectation of our deliverable defines how our product is perceived, and hence it’s level of quality as seen by the customer.
When the overall quality of the product is tied to our customer’s expectations, the strong link between building the thing right and especially building the right thing is clear. A good quality control effort assures quality production or building the product right. However, building the right product or meeting customer expectations may only be achieved thorough a continuous elicitation and cross-checking of customer needs and desires throughout the project. There should be no surprises with delivery, whether that delivery is iterative or singularly based.
If I had to sum up what I believe constitutes the Project Delivery Performance Domain in four bullets, I’d say:
by: Klaus Nielsen, PMBOK® Guide-Seventh Edition Development Team member
Having dabbled with musical instruments, I remember hearing Walter Murphy’s disco version of The Fifth of Beethoven which spurred a whole collection of up-tempo classic works like the Hooked on Classics compilation. All of these recordings took the notes and rhythms of the classical pieces and updated them for a different sound. And properly guiding the orchestration was key to synchronizing the various instruments with the new beat.
Project work is about orchestrating the range of project activities in such a way that the team aligns to produce the desired result. The conductor does not control the musicians or performers. Instead, that role cues individuals so they know their part is coming up, seamlessly integrates them into the current movement, and signals when some players can conclude their part and rest for a bit.
In a project environment, the project manager, team lead, or other “conducting” role keeps the focus on the sheet of music that links the project team together. Team members know their individual parts and look to the conductor to guide the interfaces within the team, between the team and other parts of the organization, and among the project stakeholders. The conductor ensures the team has or secures the necessary resources to keep the musical score on track, such as stands to hold the sheet music, clips to keep the music in place, lighting at the right levels for reading, etc. The conductor is constantly listening to the team—individually and collectively—to ensure that everyone is playing at the right pace and seamlessly helps the team adapt and recover when the harmony and melody are no longer in synch. Throughout the performance, the conductor and the team learn together to improve the next movement or piece that follows.
It is important to note in this analogy that the conductor is not above the team but rather performs a critical role within the team. There are countless videos on YouTube showing what can happen when a random group of individuals try to make music without any organizing force and how that ability changes once a conductor joins the group. The conductor is always listening to and sensing how the performance is advancing. This involves taking the pulse of not just the musicians but also the audience to discern how they are responding to the music. The conductor has a position from which to spot possible pivot points to keep the performance on track. The conductor also understands the work that is coming in the next movement and prepares the team to seamlessly make the shift.
With a large, multi-instrument orchestra, having a formal conductor may represent the best way to organize and structure the team effort to produce harmonious music. But there are often instances where teams come together without any previous rehearsals or practice sessions and find a way to make music together. Many jazz artists can improvise music on the spot with other musicians. One of the players “conducts” by setting the melody. The other band members pick up the beat, and then they all adapt with each other as they play. When major shifts occur, they use calls-outs and other mechanisms to signal the shift so the rest of the band can follow. If one or two musicians need a break, the rest of the band can keep playing without disruption. Thus, the mechanisms and tools for conducting can be highly structured and formal or light enough to keep all of the musicians aligned.
To make the orchestra or the jazz band function effectively, the musicians needs to understand and appreciate each other’s role in achieving the end result. They need a common musical score or initiating beat that sets the path forward. They use language, signals, and other mechanisms to keep the work on track and adapt to changing circumstances. They learn together so they improve individually and as a team. And after each performance, they reflect on where they are now, how much they have accomplished, and what lies ahead.
The PMBOK® Guide–Seventh Edition is organized around eight Project Performance Domains, which are a group of related activities that are critical for the effective delivery of project outcomes. Project Performance Domains are interactive, interrelated, and interdependent areas of focus that work in unison to achieve desired project outcomes, just like making marvelous music.
The Project Work Performance Domain focuses on facilitating the production of fantastic music (project deliverables). It includes the work necessary to support the performers as illustrated above in creating music (products, services, results), and achieving beautiful music (the ultimate outcomes of the project). Project work keeps the team focused and project activities running smoothly—without it, no harmony.
Daily, musicians practice their instruments for many hours, they sometimes teach, and now and then play a concert. Their performance runs continuously throughout the year, just like work throughout a project life cycle. Some musicians might be more experienced than others at aspects of their craft; however, all work to create a unified whole, which is what a performance is all about.
I hope you now understand why I think project work is a Project Performance Domain. Let’s turn the music on and the volume to maximum, and let’s perform the project work as a high-performing team.
by: Nader K. Rad, PMBOK® Guide-Seventh Edition Development Team member
What does product life cycle have to do with project management? Well, let me tell you about that with an example: Let’s say we have a project to build a plant. We will spend some time designing and building it, and then it will be handed over to another team for operations.
Our project is the main investment, and the agent for change – which in this case is the creation of the plant – and then the operations is where value is generated by using the product we have created. Operations continue until many years later when the owner decides to stop using that plant because it’s not justifiable, or for some other reason.
What do you do with the plant when you decide to stop using it? There’s always the option of just abandoning the plant, which may create good opportunities for photographers many years later, like this plant not far away from me in Charleroi, Belgium. In many cases, though, for safety, environmental, or economic reasons, you may want to disassemble useful parts of the plant, demolish the rest, build walls or fences, etc. In this case, these activities form a packaged change, which should be managed properly with a clear purpose. In other words, it can be seen as another project.
Is that everything, then? Hardly so. When the plant is in operation, many things change in the environment; the plant doesn’t stay exactly the same until it’s retired. In many cases, we make changes to the product (the plant) during its operation to adapt to the environment and increase our profits. Some changes are simple, and we just implement them. Some changes are bigger and more challenging, though, and need serious management. Those changes will be managed by a project.
Do we have to stop operations during the project? It depends: Sometimes we have to, and sometimes we don’t. In some cases, the project can be focused on changing one part of the product, while the other parts continue their operations normally. In IT development projects, it’s possible to deliver incrementally during the project: releasing a working version of the product into production while the team is working on the next release.
In some projects, the day-to-day operations and changes are so tightly coupled that they may look like the following and may even be done with mixed teams responsible for both aspects.
When we, as people involved in projects, think about the product life cycle, there are lots of things to consider; for example,
Put simply, there isn’t just one way of managing projects, and we should not force the one approach that we are most used to, or is the most popular at the time, onto all types of projects, regardless of their natures and needs. In other words, we should consider life cycle management as one of our performance domains in project management. The main focus of this performance domain is the project life cycle (the series of phases that a project passes through from its start to its completion), but it should also consider everything that impacts the project life cycle, including the product life cycle, development approach, and delivery cadence.
This is a reminder that the Influence Score has been retired as of today, 30 March 2020. You can read the initial announcement for additional information surrounding this decision here.
There are many ways to engage within the community, take advantage of programming, and share your knowledge and expertise. We appreciate the feedback that all of you have provided so far!
The ProjectManagement.com community will certainly continue to evolve in exciting ways. And we look forward to new avenues through which to recognize community members’ contributions and demonstrate your helpfulness, impact, and leadership within the community. You all make this an engaging, informative, and valuable space for Project Managers! More to come in 2020, so please keep an eye on the Critical Path!