Delivery Performance Domain: How to be Clear What You Commit to Deliver

The project delivery performance domain is all about what your project will deliver. The twin concerns of the PMBOK 7 Delivery Performance Domain are scope and quality. Scope is about what the project needs to deliver and quality is about the standards or performance levels you need to meet.

This is the sixth of our series of eight articles, covering the eight Project Performance Domains of the 7^thEdition of the PMI’s Guide to the Project Management Body of Knowledge (PMBOK 7). For a general introduction to these domains, check out our article, Project Performance Domains: Do You Know What they Are and Why they Matter?

Structure of this article

In this article, we will examine:

• What is the Delivery Performance Domain?
• Basic Principles of the Delivery Domain
• PMI’s Description of the Components of the Delivery Performance Domain
• Critical Evaluation of the Delivery Domain
• What Else We Should Include in the Delivery Performance Domain?
• How the Delivery Performance Domain Relates to the other Project Management Domains

What is the Delivery Domain?

I don’t think I would have defined a Project Performance Domain called ‘Delivery’ in the way that PMI has in PMBOK 7. It seems to me it should focus on how we deliver projects.

However, we have to accept that this is not how the authors have tackled the topic. They focus on what your project will deliver. It’s impossible to tell (without asking) whether this is because:

• They wanted a performance domain focused on ‘what’ – and this is the best name they could find, or
• The ‘what’ is, indeed, what came to mind when they thought about delivery

This is important to me because, as always, I will assess the content of the Performance Domain. And it seems to me pointless to assess it against a definition that is a complete variance with the one the authors chose. So, without further ado, here is…

The PMBOK Definition of the Delivery Performance Domain

PMBOK 7 defines the Delivery Performance Domain like this:

‘The Delivery Performance Domain addresses activities and functions associated with delivering the scope and quality that the project was undertaken to achieve.’

A Guide to the Project Management Body of Knowledge, 7^th Edition
Project Management Institute, 2021

Happily, the authors go on, in the section, to touch on the critical topics of benefits and value. I’ll discuss how they do so later. 

But it is important to note that what we deliver needs to realize benefits and so deliver value. This would lead me to a slightly modified definition.

Our Expanded Definition of the Delivery Performance Domain

There are two possible directions I could go with this. The difference is subtle but important. 

Option 1

‘The Delivery Performance Domain addresses activities and functions associated with delivering the value that the project was undertaken to achieve.’

Option 2

‘The Delivery Performance Domain addresses activities and functions associated with delivering the benefits that the project was undertaken to achieve.’

The Differences

The difference between my versions and PMI’s is that I have replaced ‘scope and quality’ by:

• in option 1, value, and 
• in option 2, benefits

If I am honest, I prefer Option 1 and the use of ‘value’. Value is about the relationship between cost and benefit. PMI prioritizes value in PMBOK 7 and talks about Delivery of Value in the first major subsection of this Project performance Domain. This is clearly the superior definition.

So, Why Bother with Option 2, and the use of ‘Benefits’?

My big critique of the Delivery Performance Domain as a whole is that it does not touch on the how. As a result, it does not cover Cost Management or Schedule Management. Indeed, whilst the next Performance Domain, Measurement, touches on cost management, it does so only in the context of measuring cost performance. And it also seems to largely neglect schedule monitoring and control.

As a result, it seems to me that the Delivery Performance Domain as PMBOK 7 describes and covers may pay lip service to value, but really talks about benefits.

So, Option 1 is a better definition of what this Performance Domain should be. Option 2 is a better definition of what this Performance Domain is.

Learn More…

• What is Value? …or Project Value? | Video
• Value Delivery: The Driving Force that should Motivate your Projects
• What are Project Benefits? | Video
• Benefits Management: What Every Project Manager Needs to Know [and Do]

The Expected Outcomes for the Delivery Performance Domain

PMBOK 7 goes on to define the domain in terms of five desired outcomes, which demonstrate that the project team has executed it effectively:

1. Projects contribute to business objectives and advancement of strategy
2. Projects realize the outcomes they were intended to deliver
3. Project benefits are realized in the time frame in which they were planned
4. The project team has a clear understanding of requirements
5. Stakeholders accept and are satisfied with project deliverables

Let’s take a look at these in turn.

Projects contribute to business objectives and advancement of strategy

There’s not much to say here. It makes sense.

Projects realize the outcomes they were intended to deliver

This also makes sense. However, I would like a paragraph that relates outcomes to scope and quality. Outcomes are not mentioned anywhere else I can find in this performance domain. 

Project benefits are realized in the time frame in which they were planned

The problem I have with this one is that the Delivery performance Domain does not discuss schedule at all.

The project team has a clear understanding of requirements

There’s not much to say here. It makes sense.

Stakeholders accept and are satisfied with project deliverables

It seems the authors take it as read that if we deliver the right scope to the right quality, our stakeholders will be satisfied. In my experience, this an essential enabler, but far from sufficient to assure stakeholder satisfaction. 

Verifying the Outcomes from the Delivery Performance Domain

For each domain, PMBOK 7 also sets out ‘checks’ by which we can assess project performance against each of the outcomes for the performance domain.

I will interpret these checks in my own words.

Projects contribute to business objectives and advancement of strategy

The check here is the alignment of business objectives and project deliverables. This should be clear from documents like the organization’s business plans and strategy, and the project’s authorizing documents. I’d make it more explicit that the prime project documents here would be things like:

• Business case, project proposal, and investment appraisal
• Benefits case and benefits realization plan

Projects realize the outcomes they were intended to deliver

This one is weak, suggesting that data compared against the business case show the project is on track. Not only does this offer little guidance, but I would want a clear reference for the need for a benefits realization plan.

Project benefits are realized in the time frame in which they were planned

However, here we do see a direct reference to:

• Benefits realization plan
• Business case
• Schedule

I think what this shows up for me is that this and the previous Performance Domain Outcome could sensibly be combined into one.

The project team has a clear understanding of requirements

This check is more of a statement of principle that offers no actual process for checking. It rightly reminds us that:

• Predictive projects see little change from initial requirements statements
• Adaptive projects see an emerging understanding of requirements

But what is the check? To me, it is the Project Manager’s responsibility to ensure clear understanding, by:

1. Crafting clear statements of requirements or a well-ordered backlog of clearly defined user requirements
2. Ensuring team members are aware of and can access these documents
3. Encouraging team members to question what they see here, to clarify either their understanding or the written articulation of requirements

Stakeholders accept and are satisfied with project deliverables

This is the strongest of the checks in this domain. It suggests a combination of:

• Interview
• Observation
• Feedback
• Complaints monitoring

Important Definitions within the Delivery Performance Domain

In the introduction to the Delivery Performance Domain, PMBOK 7 highlights (in a box), five key definitions of jargon terms:

1. Requirement
   A solid definition
2. Work Breakdown Structure (WBS)
   A solid definition
3. Definition of Done (DoD)
   A sound definition weakened by explicit reference to being ready for ‘customer use’. The use of ‘customer’ restricts this definition – I’d add something like ‘or release to the beneficial owner’.
4. Quality
   I find this definition a little surprising in not referring to any standard, level, or grade. However, it is sound.
5. Cost of Quality (CoQ)
   An excellent definition

What appears to be missing are definitions of:

• Scope 
  …because this, along with Quality, are the prime concerns of the Performance Domain
• Deliverable 
  …which has a nice definition on the following page

I don’t think there is anything here that justifies quoting the PMI’s definitions at this point. However, we’ll return to some of these as we discuss the body of the section.

Add my versions, if useful, then any others

Basic Principles of the Delivery Domain

PMBOK 7 is clear on some important principles:

1. Projects support the delivery of business objectives and the realization of strategy
2. Their interpretation of delivery is meeting scope and quality expectations to achieve this – but not the how
3. This delivery of products, services, or remediations provides value to the business
4. Stakeholders may perceive different levels of value from different project outcomes

Point two is my main concern with this Project Performance Domain. However, I must acknowledge that this is largely consistent with the principles-based approach of PMBOK 7.

PMI’s Description of the Components of the Delivery Performance Domain

Aside from the usual subsections of Interactions with other domains (discussed below) and Checking results (discussed above), there are four subsections in this Performance Domain:

1. Delivery of Value
   Short and on point
2. Deliverables
   Excellent
3. Quality
   Mostly excellent
4. Suboptimal Outcomes
   An interesting topic that feels rushed and lacking

Let’s see what each one covers.

Delivery of Value

Value delivery is a central concern of The Standard for Project Management which forms Part 1 of the PMBOK 7 volume. This short section builds on that and the woolly definition of value on page 5 of the Standard:

‘Value. The worth, importance, or usefulness of something.’

The Standard for Project Management, 7^th Edition
Project Management Institute, 2021

Although this is a very short section, which fails to properly define value, it makes four important points in four short paragraphs.

1. Value can be delivered either incrementally, in chunks throughout the lifecycle or in one go (the so-called ‘Big Bang approach’) at the end of the life cycle. I’d really have liked to see a reminder that incrementalism is not the sole preserve of adaptive project management.
2. Product or service life cycles are critical to value delivery, which therefore extends beyond the end of the project.
3. There are many approaches to demonstrating business value, from formal business case documents to lean ‘start-up canvases’.
4. These documents need to allow for outcomes to be assessed against the promises they offer.

Deliverables

This section is excellent and has three parts:

1. Requirements

This clearly sets out the principles for:

• Eliciting requirements
  With a helpful set of criteria
• Evolving and discovering requirements
  Within adaptive projects
• Managing requirements
  That sets out the case for active management and also suggests some basic tools

2. Scope Definition

This covers two core topics very well:

1. Scope decomposition
   There is a simple but clear assessment of the use of Work Breakdown Structures in predictive projects, and roadmaps, epics, and user stories in adaptive projects.
2. Completion off deliverables
   Has helpful (if overlapping) definitions of:
   • Acceptance or completion criteria
   • Technical performance measures
   • Definition of Done 

Learn More…

• The Basics of Scope Management: How to Manage Scope | Video
• Establish Project Scope: How to Master Your Toughest PM Challenge
• Scope Management Plan: Everything You Need to Know

3. Moving Targets of Completion

The last subsection under Deliverables acknowledges that the goal of your project and its Definition of Done may change for one or more of many possible reasons.

Definition of Done, by the way, is the checklist of criteria that your deliverable needs to meet, before you consider it finished. I like the concept in this section – which was new to me – of ‘done drift’.

This part also ends with a decent paragraph about Scope Creep and Change Control.

Learn More…

• How to Prevent Scope Creep | Video
• Project Change Control: What You Need to Know to Make it Effective

Quality

This is also a very strong part of the Domain – especially the first part of this section, on Cost of Quality. This reminds us that:

‘Cost of Quality (CoQ): All costs incurred over the life of the product by investment in preventing nonconformance to requirements, appraisal of product or service for conformance to requirements, and failure to meet requirements.’

A Guide to the Project Management Body of Knowledge, 7^th Edition
Project Management Institute, 2021

The description of Cost of Quality separates this out into the different elements of cost arising from:

1. Prevention
   This is Quality Design and Quality Assurance
2. Appraisal
   This is Quality Control
3. Internal Failure
   Finding and fixing defects before the customer receives the product
4. External Failure
   Finding and fixing defects after the customer receives the product

The second part of this section covers the cost of change. It is not about controlling change, nor even about changes in scope or functionality, but focuses on changes arising from quality deficiencies.

But the gaps here are not my primary concern. PMBOK 7 reproduces Barry Boehm’s Cost of Change Curve. This is a curve showing exponentially rising costs of change. He first published this in a journal article in 1976 and then reproduced it in his 1984 book, Software Engineering Economics.

My concern is that the authors do not state that this curve is only intended to apply to software development and was developed under a predictive (waterfall) paradigm. It is therefore not applicable to either:

• Non-software predictive projects
  For which ‘S-curves’ are more typical
• Modern software development
  Where continuous delivery means that cost of change may oscillate and rise a little towards the end of a project, but remains largely flat through most iterations. This is one of the prime justifications for agile delivery models!

Learn More…

• Project Quality Management: Principles and Practices You Need to Know
• In Praise of Quality: Why it Should Matter to You | Video

Suboptimal Outcomes

This is a short section that helpfully identifies the potential for outcomes to disappoint, and offers a small sample of possible reasons. But it disappoints massively in its closing sentence that merely suggests that effective project management may help minimize this, but that the possibility of suboptimal outcomes is just the result of ‘the uncertainty of attempting to produce a unique deliverable’. 

This isn’t wrong. It just doesn’t do more than state the bleeding obvious!

Critical Evaluation of the Delivery Domain

I’m going to evaluate each of the eight Project Performance Domains in the 7^th edition of the PMBOK Guide on a 5-point scale, of:

1. Lacking
   Little more than a passing mention of what’s important
2. Poor
   A lot of work needed
3. Okay
   Needs Significant work
4. Good
   Would be great but minor tweaks needed
5. Excellent
   Everything I could wish it to be

This one is easier to evaluate than some, but harder than others. The difficulty stems from the limited definition the authors have chosen for this Performance Domain. On the face of it, this is a weakness. However, on its own terms, the definition means it is easy to assess the content against such a simple definition.

And doing that – which seems the fairest approach – leads me to a choice of two options: okay or good. There is work needed. But think there is a lot to like in the Delivery Performance Domain. The three principal subsections are all good, and the one on Deliverables is Excellent. Yes, the authors of the 8^th edition need to fix the cost of change subsection. And I’d really like them to give some value to the part about Suboptimal Outcomes. But I will assess these as minor tweaks.  Think the Delivery Performance Domain is solidly Good and I score it a 4.

Strengths of The PMBOK 7 Delivery Domain

The principal strengths of the Delivery Performance Domain are its discussions of:

• Value
• Deliverables (Excellent)
• Cost of Quality (Excellent)

Weaknesses of The PMBOK 7 Delivery Domain

I’ll list the weaknesses of this performance domain in three categories:

1. What’s missing
   I will discuss this in the next section of this article.
2. What’s weak
   • Value
     I’d really like to see a more in-depth assessment of what value means and how it relates to benefit, ROI, scope, quality, and outcomes
   • Cost of Change
     What’s here is, in part, weak. The other part (see below) just needs to be fixed!
   • Suboptimal outcomes
     This is a nice addition that fails to deliver on its promise
3. What needs fixing
   • Cost of Change
     Really, the use of Boehm’s curve without critical evaluation – nor even clear description – is a big failing. Nothing wrong with the model, but in the 2020s, it needs the context of alternative models.

What Else We Should Include in the Delivery Performance Domain?

As above, I think I’d like to see four things added to the delivery domain:

1. Cost Management 
   Arguably doesn’t fit into the definition, but hard to talk in terms of value without it. However, the checks on outcomes talk only in terms of benefits, so the cost part of value may not be needed.
2. Schedule Management
   I’ll grant that this seems outside the scope of the authors’ definition of the performance domain. But where is this, in the 8 Performance Domains? IT’s not in the Measurement Performance Domain ether – and I’ll complain about that in the next article in this series!
3. Configuration Management
   This topic is less about the how and more about the what. So, I’d really like to see this get a solid mention in a future edition of the PMBOK Guide, if the Performance Domains model remains.
4. Benefits Management
   Benefits are easier to manage than value: if you manage benefits and cost, you manage value. And there is nothing much here about actually delivering that value.

How the Delivery Performance Domain Relates to the other Project Management Domains

I think PMBOK 7 gets this largely right, in focusing on the links:

• From the Planning Performance Domain to the delivery domain
• And the Development Approach and Life Cycle Performance Domain in setting out the delivery cadence
• With the Project Work Performance Domain, which contains much of the ‘how’
• And the Team Performance Domain, because it’s the team that does the delivery

But, as is always the case, it’s only right to see the integration of this project performance domain with all of the others. We:

• Choose our deliverables to meet stakeholders’ needs
• Measure outcomes to control delivery
• Deal with uncertainty throughout delivery

What are your Thoughts about the Delivery Performance Domain?

Please share what you think of the way PMI has handles the Delivery Performance Domain and any comments you have about it. I’ll be sure to respond to any comments you post below.

Project Management Domains eBook Series

This is a Chapter from the Delivery volume of our Kindle Exclusive Project Management Domains ebook series.