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:
Understand the intended outcome, not just the desired result. Build the right thing!
Building the product right and building the right product realizes the intended outcomes.
Quality derives from customer expectations being met.
Customer expectations are understood through requirements elicitation and interpretation.