The Project Work Performance Domain of PMBOK 7 is unlike all the others. The term ‘Project Work’ conjures no clear impression of what the domain contains. The contents the authors allocate to it have little coherence. Most of the content is sketchy at best. This is PMBOK 7’s lost domain. It has failed to find its way.
This is the fifth of our series of eight articles, covering the eight Project Performance Domains in the 7thEdition of the PMI’s 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:
Unlike the other Project Performance Domains in PMBOK 7, the title ‘Project Work’ does not immediately suggest what the domain consists of. Isn’t it all ‘Project Work’?
So, here is how PMBOK 7 descries the Project Work Performance Domain…
‘The Project Work Performance Domain addresses activities and functions associated with establishing project processes, managing physical resources, and fostering a learning environment.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
Well, that’s clear then. Not.
It’s processes, it’s resources, it’s learning. But, what is it that ties them together?
However, there is a sentence a little way into the introduction to the domain that, I think, helps us more…
‘Project work keeps the project team focused and project activities running smoothly.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
Ahh. So, it seems to be a bunch of enabler activities then. It’s about keeping your project running smoothly.
This sort-of makes sense. But there are a lot of activities that keep the project running smoothly. So why these? And why put the others elsewhere? It seems that the others fit in more obviously elsewhere, given the other seven domains defined in PMBOK 7. These do not.
I am not sure I’d want to create an alternative definition of this Performance Domain, because I am not sure I buy-into its broad content as a coherent domain. However, if I were to, I’d label it:
Project Enabling Performance Domain, and adopt a definition like this:
‘Project Enabling activities support the effective and efficient working of your project.’
You know what… I quite liked Project Integration as a concept, in earlier editions of the PMBOK Guide. It may not have worked well as a Knowledge Area (KA), but it did tie together the other KAs and processes pretty well.
PMBOK 7 goes on to define the domain in terms of six desired outcomes, which demonstrate that the project team has executed it effectively:
Let’s take a look at these in turn.
This seems as good a definition of the performance domain as anything. Hence my suggested alternative definition.
Is this not what ‘tailoring’ is about? And isn’t that covered in the Development Approach and Life Cycle Performance Domain? That said I do quite like what PMBOK 7 has to say on this topic.
The first domain is the Stakeholder Performance Domain. And project communication also appears in the Planning Performance Domain. This feels like a mess of overlaps.
I am not suggesting that the domains don’t or should not overlap. But this aspect does seem confused and what the two paragraphs say either:
The section here is focused on waste, so this may meet the ‘efficient and effective’ definition of the domain.
This domain is the only place procurement appears in PMBOK 7. But is procurement really ‘just’ an enabler? It’s a big and important skillset. And selecting a procurement strategy is – for want of a better word – as strategic activity. This feels like short-changing a big and vital discipline.
This feels to me like the real meat of this domain. What a shame the content is so terribly thin us so badly!
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.
If the only check is status reports, as PMBOK 7 suggests, you have a bit of a governance deficit. Not least because status reports usually focus on delivery and threats to delivery, to meet the priorities of readers.
What about more informal oversight by your sponsor or client? And, at the other end of the formality scale, there are Project Assurance activities.
Here, PMBOK 7 mentions process audits and quality assurance, which I like. But it also says that ‘Evidence shows that project processes have been tailored…’ Great. What evidence? For me, the measures of efficiency and effectiveness need to be output measures. Tailoring – though important – is an input activity. You can tailor well, and still get a team that is inefficient and ineffective!
Here, the test is that actual communication follows the plan. That’s okay. But what matters again is the outcomes. The plan needs to articulate the test s of effective communication and the feedback mechanisms. Those offer a more robust check. PMBOK 7 approaches this ideal by going on to refer to levels of additional information requests and misunderstandings. But my concern here is that we need to define how we will assess understanding as we plan, and then make active checks.
This is about wastage. And the checks here are fine as far as they go; focusing on scrap and rework. But, there are other forms of waste, such as movement of materials, delays in accessing them, and so on. The concepts or Muda, Mura, and Muri, and the seven wastes of lean are valuable here, and we have a video about them: What are Muda, Mura, Muri? And, what are the 7 Wastes of Lean?
The solution PMBOK 7 offers is a procurement audit. This is great. But written procedures and checklists provide assurance, before the ‘post-hoc’ check of an audit. And I am not sure that I agree that the role of a procurement audit is to ensure the contractor is performing to plan. That is the role of contract management.
This refers to a heading in the domain section, which does not appear in the list of six desired outcomes. Yet this is the best of the seven checks – indeed the only one to which I have noting of substance to add. It suggests we use:
I quite like the idea that status reports would show faster progress with fewer errors. This is an output measure. Nice.
All of the performance domains offer us a number of useful definitions. None offer sucha quirky selection as this one. It offers us two (of many possible) definitions from the knowledge area of procurement. And it offers useful definitions of tacit and explicit knowledge, to support the continuous learning section.
In the introduction to the Project Work Performance Domain, PMBOK 7 highlights (in a box), four key definitions of jargon terms:
All of the definitions are, to my mind, solid. However, I don’t see the two procurement definitions as core to the domain, so shan’t discuss them.
The definitions of explicit and tacit knowledge recur- almost verbatim, in that section of the domain. So I shall discuss them later.
I think what I would really like to have seen are definitions of ‘effective’ and ‘efficient’. Yes, many people know what they mean. But no, not everyone does. And these two concepts, effectiveness and efficiency, are absolutely central to what this domain seems to be about.
So, here, are my definitions
‘Efficient: able to do an optimum amount of work with minimum use of time and resources.’
‘Effective: causing the desired result, successful, able to deliver what matters.’
Unlike the other Performance Domains in PMBOK 7, there is little in this one that describes basic principles. Aside from the definition I quoted above, all we find is a list of project work topics, that map closely to the eight principal subsections.
So, I will include these in the next section of my description.
This domain has the two standard sections of:
In addition, there are eight principal components. Here are the titles, along with the descriptions offered in the introduction to the domain itself, and my assessments of the content.
Managing the flow of existing work, new work, and changes to work.
Establishing efficient systems and processes
This talks about project tailoring and periodic review. This is such an important area, but the content is sketchy and fails to cover the principles it should. It also fails to integrate well with the chapter on tailoring in the Standard part of PMBOK 7.
I like that the team has included this in the domain. I am concerned however, that what we have does very little more than state the obvious. They fail to define a Project Constraint, which is something that limits the choices you can make, but do give some good examples, like:
Keeping the project team focused
The authors see this as being about:
However, what they say about it in two short paragraphs is little more than stating the obvious.
But you know what? There is a whole Team Performance Domain.
Communicating with stakeholders
Another two short paragraphs. And the first one calls back to the Stakeholder Performance Domain, with little additional value.
We have a wealth of articles on Project Communications and Stakeholder Engagement.
Managing material, equipment, supplies, and logistics
I love that the emphasis of this section is on waste and the need for effective logistics. This shows valuable insight. It refers to four objectives of which three are waste-related:
Our article on Physical Resources is: Project Resource Management: Part 1 of Your Comprehensive Guide
Working with contracting professionals and vendors to plan and manage procurements and contracts
This section is by far the biggest but is a long way from doing justice to even the principles of good procurement and contract management practice. It covers:
And it offers three additional definitions, beyond the two in the introduction to the Domain:
These are all described in our article: Project Procurement Management [All the basics you need to know].
Monitoring changes that can affect the project
The two paragraphs in this sub-section refer, respectively, to adaptive and predictive projects.
The adaptive paragraph is sound and makes the point that evolution and change are built into the approach from the ground up (my interpretation). It also succinctly discusses the schedule, budget, and scope trade off which means that new work stops when the top priority items are complete.
The predictive paragraph is also a nice summary of, in this case, the change control process. We have a comprehensive article: Project Change Control: What You Need to Know to Make it Effective.
Despite its brevity, this subsection is excellent.
Enabling project learning and knowledge transfer
This covers two very interesting topics and shows the MBOK 7 approach at its best. It introduces readers to the ideas of:
Explicit Knowledge can be clearly articulated – usually in words, numbers, tables, and images.
Tacit Knowledge is the hard-to-communicate result of experience and reflection. More like ‘know how’ than ‘know that’. Yet ‘know how’ can be made explicit with checklists and procedures.
Your ability draw inferences and assess situations is based on tacit knowledge. So, transmitting it is all about mentoring, support, guidance, discussion, and shadowing.
We have a thorough article: Project Management: How to Get Better with Knowledge Management and Knowledge Transfer
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:
It is clear from my assessment that this Domain has little coherence that I cannot rate this Good or Excellent. It needs more work than that. There are nuggets of good stuff, as there are in all of the Performance Domains. But there are also some serious deficiencies. This Domain takes me close to a rating of Lacking. But its few strengths lead me to a score of 2, Poor.
So, what are those strengths? I like a number of things the team thought to mention. I’d like it better if they did a better job of covering the ground:
The Project Work Performance Domain seems to me to be a mish-mash of odd topics. They feel like they have been dumped here because the authors could find nowhere else to place them.
There is no coherence to this domain, as defined in PMBOK 7. If a ‘Project Work Performance Domain’ were to make any sense, this is not how we would treat it. Rather, this feels like an afterthought, developed solely to be a home for waifs and strays.
I can only assume that the authors created an eighth domain out of this rag-tag of loose ends for one of two reasons. Either:
However, we should also assess the quality of what is there – irrespective of how it belongs together in this performance domain. And my answer here is that it is adequate (good) at best and very poor (lacking) at worst.
Nothing.
The label ‘Project Work’ conjures no clear meaning that we can use to guide us to a coherent set of ideas, disciplines, or knowledge areas. Rather, PMI should just drop this Performance Domain, and rethink where its content belongs, afresh.
The authors of PMBK 7 write that ‘The Project Work Performance Domain interact and enables other performance domains on the project’ (sic). It’s poor English and bad style, but makes sense. As with most performance domains, this paragraph tells us nothing more that that the performance domains all interact. In this case, the response is: ‘of course!’
Please share what you think of the way PMI has handles the Project Work 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 Project Work 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.
Project Estimating Skills: How to Master Successful Project Estimation
Failing Project: Do You Know When it’s Time to Pause Your Project?
Effective Teamwork: Do You Know How to Make it Happen?
How to do a Basic Agile Project | Video
Session expired
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.