Project Management

Building the Right Product or Building the Product Right: Two Sides of the Same Delivery Coin

From the The Critical Path Blog
by , , ,
Welcome to The Critical Path--the home for community happenings and events on ProjectManagement.com! This is where you'll find community news, updates, upcoming events, featured member posts and more. We'll also be showcasing hot topics in the project management arena and bringing you interviews with industry experts. The Critical Path is our primary way of getting news out to members, so be sure to check back for updates!

About this Blog

RSS

View Posts By:

Marjorie Anderson
Kimberly Whitby
Laura Schofield
Heather McLarnon

Past Contributers:

Carrie Dunn
Danielle Ritter
Kenneth A. Asbury
Craig Dalrymple
Rebecca Braglio
Kristin Jones

Recent Posts

Principles and Performance Domains: The Foundation for Project Management Practitioners

May 2020 Community News You Can Use

Careers in project management – what does the latest research say?

Virtual Learning Opportunity from PMI

New PMI Volunteer Initiative: PMImpact


Categories: standards


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.

Posted by Laura Schofield on: April 15, 2020 09:21 AM | Permalink

Comments (11)

Please login or join to subscribe to this item
I love the final bullet "Customer expectations are understood through requirements elicitation and interpretation." This is a foundational concept that must be understood in any product. Sometimes what the customer "says" is not exactly what they are "expecting" the product or service to be. We must always seek to find the "voice of the customer" to be successful.

Thanks, Nick. Incremental deliveries and feedback loop (check-ins) that ensures the interpretation is as it was meant to be. Words and text are one thing, but less likely for misinterpretation or perceived alignment when shown a tangible asset.

Just one question: As an academician, when will the 7th edition be made available? I need to know which version I should have student purchase in August for the start of our Fall Term. I thought I would find an answer here. Any updates?

Hi Karen, the English version is scheduled to be available in electronic form the end of this year with the printed version following in January 2021. Due to the impact of COVID-19, the translated versions will likely be delayed until the first half of 2021.

The glue between building the right thing and building the thing right is the continuous customer feedback. Good read.

Good post Nick. Thanks for discussing this performance domain.

It would be even better if PMI Standards would publish the market and academic research that led the PMBOK(R) Guide -Seventh Edition Development Team to move away from the Guides previous structure based on the Knowledge Areas. This is a significant change (not wrong but definitely different) that should have sound justification to back up these 8 performance domains. Having the drivers for the change discussed within the PMBOK(R) Guide, or at least in an appendix, would help the users of the Guide to understand the change.

Also, as a Review Team member for the Seventh Edition update, I still see a gap between tying the application of the 12 Project Delivery Principles in the new Standard to the 8 Project Performance Domains in the Guide. Do you know if this gap has been addressed post feedback from Review Team 2?

Again, thanks for the post. Good luck to the Development Team as they finalize the Standard and the Guide.

Interesting change indeed! Albeit it came in time while i am putting my final touches on our training program based on the 6th PMBOOK :)
Best of luck in your endeavors and your efforts to advance the profession!

Karen - not sure how you have incorporated the PMBOK(R) Guide into your curriculum but the 7th Edition is vastly different from the 6th Edition. Unless you have had a chance to see the the draft by some other means (e.g., being a Review Team 1 or 2 Reviewer) you may want to hold off until yous see the published version

Drucker termed a different way.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"I never forget a face, but in your case I'll make an exception."

- Groucho Marx

ADVERTISEMENT

Sponsors