OnlinePMCourses
Please Share

Project Work Domain: The Processes to Enable Effective Project Management

Project Work Domain: The Processes to Enable Effective Project Management

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?

Project Work Domain: The Processes to Enable Effective Project Management

Structure of this article

In this article, we will examine:

What is the Project Work Domain?

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’?

The PMBOK Definition of the Project Work Performance Domain

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?

A Better Definition?

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.

Our Definition of the Project Work Performance Domain

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.

The Expected Outcomes for the Project Work Performance Domain

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

  1. Efficient and effective project performance
  2. Project processes are appropriate for the project and the environment 
  3. Appropriate Communication with Stakeholders
  4. Efficient management of physical resources
  5. Effective management of procurements
  6. Improved team capability due to continuous learning and process improvement

Let’s take a look at these in turn.

Efficient and effective project performance

This seems as good a definition of the performance domain as anything. Hence my suggested alternative definition.

Project processes are appropriate for the project and the environment 

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.

Appropriate Communication with Stakeholders

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:

  • re-states what PMBOK 7 says elsewhere, or, frankly, 
  • states the obvious

Efficient management of physical resources

The section here is focused on waste, so this may meet the ‘efficient and effective’ definition of the domain.

Effective management of procurements

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.

Improved team capability due to continuous learning and process improvement

This feels to me like the real meat of this domain. What a shame the content is so terribly thin us so badly!

Verifying the Outcomes from the Project Work 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.

Efficient and effective project performance

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.

Project processes are appropriate for the project and the environment 

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!

Appropriate Communication with Stakeholders

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.

Efficient management of physical resources

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?

Effective management of procurements

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.

Effective handling of change

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:

  1. For predictive projects, a change log
    To which, I’d add ‘a robust change process with completed change request documents’.
  2. For adaptive projects, a backlog
    To which I’d add that there needs to be a sound process for prioritizing and selecting draw-down.

Improved team capability due to continuous learning and process improvement

I quite like the idea that status reports would show faster progress with fewer errors. This is an output measure. Nice.

Important Definitions within the Project Work Performance Domain

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:

  1. Bid Documents
  2. Bidder Conference
  3. Explicit Knowledge
  4. Tacit Knowledge

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.’

Basic Principles of the Project Work Domain

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.

PMI’s Description of the Components of the Project Work Performance Domain

This domain has the two standard sections of:

  1. Interactions with other Performance Domains (see below)
  2. Checking Results (see above)

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.

Project Processes

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.

Balancing Competing Constraints

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: 

  • Fixed dates
  • Compliance requirements and policies
  • Fixed budget

Maintaining Project Team Focus

Keeping the project team focused

The authors see this as being about:

  • Workload balancing
  • Work satisfaction and motivation

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.

Project Communications and Engagement

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 Physical Resources

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:

  1. Reduce or eliminate materials handling and storage on site
    There are two things here, handling distances, costs, and risks on the one hand, and storage costs and risks on the other.
  2. Eliminate wait times 
    Would minimize be a more pragmatic word, given 1, above?
  3. Minimize scarp and waste
    Absolutely.
  4. Facilitate a safe working environment
    This is important. Very important. But, it does not fit well here and needs a whole section on Health and Safety – that would be as appropriate in this domain as in any.

Our article on Physical Resources is: Project Resource Management: Part 1 of Your Comprehensive Guide

Working with Procurements

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:

  • The Bid Process
  • Contracting

And it offers three additional definitions, beyond the two in the introduction to the Domain:

  1. RFI: Request for Information
  2. RFP: Request for Proposal
  3. RFQ: Request for Quote

These are all described in our article: Project Procurement Management [All the basics you need to know].

Monitoring New Work and Changes

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.

Learning Throughout the Project

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:

  1. Knowledge Management
    It fails to define what this is, nor give a strong hint of approaches. But it does set out the imperative nicely.
  2. Explicit and Tacit Knowledge
    This part draws a clear distinction. And it is one that, I agree with the author, is useful to Project Managers.

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

Critical Evaluation of the Project Work Domain

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:

  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

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.

Strengths of The PMBOK 7 Project Work Domain

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:

  • Mention of lean production methods and retrospectives or lessons learned in the section on Project Processes
  • The focus on waste (and reference to health and safety) in the section on physical resources
  • The section on procurement is weak, but at least it exists – there is nothing else about the topic in PMBOK 7
  • The section on monitoring new work and changes does articulate the key points very clearly and succinctly
  • Mention of knowledge management and explicit versus tacit knowledge in the section on Learning throughout the Project

Weaknesses of The PMBOK 7 Project Work Domain

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:

  1. They could not discipline themselves to find more logical alternative homes for these ideas
  2. Numerology came to bear… Perhaps they did not like the number 7 – it is, after all, an odd number and sometimes viewed as sinister. And it is also prime. Or maybe they wanted to avoid copying the heavy use of 7 themes, processes, and principles in PRINCE2

The Quality of the Content of the Project Work Performance Domain

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.

What Else We Should Include in the Project Work Performance Domain?

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.

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

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!’

What are your Thoughts about the Project Work Performance Domain?

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.

Project Management Domains eBook Series

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

Project Management Domains - Project Performance Domains

About the Author Mike Clayton

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.

follow me on:
>