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 7thEdition 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?
In this article, we will examine:
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:
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…
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, 7th 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.
There are two possible directions I could go with this. The difference is subtle but important.
‘The Delivery Performance Domain addresses activities and functions associated with delivering the value that the project was undertaken to achieve.’
‘The Delivery Performance Domain addresses activities and functions associated with delivering the benefits that the project was undertaken to achieve.’
The difference between my versions and PMI’s is that I have replaced ‘scope and quality’ by:
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.
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.
PMBOK 7 goes on to define the domain in terms of five desired outcomes, which demonstrate that the project team has executed it effectively:
Let’s take a look at these in turn.
There’s not much to say here. It makes sense.
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.
The problem I have with this one is that the Delivery performance Domain does not discuss schedule at all.
There’s not much to say here. It makes sense.
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.
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:
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.
However, here we do see a direct reference to:
I think what this shows up for me is that this and the previous Performance Domain Outcome could sensibly be combined into one.
This check is more of a statement of principle that offers no actual process for checking. It rightly reminds us that:
But what is the check? To me, it is the Project Manager’s responsibility to ensure clear understanding, by:
This is the strongest of the checks in this domain. It suggests a combination of:
In the introduction to the Delivery Performance Domain, PMBOK 7 highlights (in a box), five key definitions of jargon terms:
What appears to be missing are definitions of:
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
PMBOK 7 is clear on some important principles:
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.
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:
Let’s see what each one covers.
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, 7th 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.
This section is excellent and has three parts:
This clearly sets out the principles for:
This covers two core topics very well:
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.
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, 7th Edition
Project Management Institute, 2021
The description of Cost of Quality separates this out into the different elements of cost arising from:
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:
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!
I’m going to evaluate each of the eight Project Performance Domains in the 7th edition of the PMBOK Guide on a 5-point scale, of:
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 8th 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.
The principal strengths of the Delivery Performance Domain are its discussions of:
I’ll list the weaknesses of this performance domain in three categories:
As above, I think I’d like to see four things added to the delivery domain:
I think PMBOK 7 gets this largely right, in focusing on the links:
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:
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.
This is a Chapter from the Delivery volume of our Kindle Exclusive Project Management Domains ebook series.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.