Monitoring and Controlling: What is The PMBOK 7 Measurement Performance Domain?

The PMBOK 7 Measurement Performance Domain is a companion to the Delivery Domain. It is an insightful exploration of the monitoring and controlling activities of the Project stage we call Execution, Implementation, or Delivery.

This is the seventh of our series of eight articles, covering the eight Project Performance Domains of the Seventh Edition of 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 Measurement Performance Domain?
• Basic Principles of the Measurement Domain
• PMI’s Description of the Components of the Measurement Performance Domain
• Critical Evaluation of the Measurement Domain
• What Else We Should Include in the Measurement Performance Domain?
• How the Measurement Performance Domain Relates to the other Project Management Domains

Spoiler Alert! The Measurement Performance Domain of the PMBOK Guide 7^th edition is very good indeed. So, let’s get into it!

What is the Measurement Domain?

The Project Measurement Performance Domain is all about monitoring and controlling the delivery of your project. And it combines some thoughtful assessments of the basic principles with helpful discussion of some of the practical measures and tools.

The PMBOK Definition of the Measurement Performance Domain

PMBOK 7 offers us four definitions of the Measurement Performance Domain. 

Definition 1: The Definition

The principal definition is the one presented in the summary box at the start of the Domain section:

‘The Measurement Performance Domain addresses activities and functions associated with assessing project performance and taking appropriate actions to maintain acceptable performance.’

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

That’s good, but a bit of a mouthful. But there are better, clearer articulations.

Definition 2: Defining the Domain by its Expected Outcomes

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

1. ‘A reliable understanding of the status of the project.’
   What a perfect statement of why we collect data – especially when combined with…
2. ‘Actionable data to facilitate decision making.’
   This is, of course, the real value of the data
3. ‘Timely and appropriate actions to keep project performance on track.’
   The very essence of project control
4. ‘Achieving targets and generating business value by making informed and timely decisions based on reliable forecasts and evaluations’
   It’s a bit of a mouthful, but this is why we monitor and control – to generate business value.

Definition 3: The First Line of Text

Perhaps the most succinct definitional statement is the first sentence of text in the body of the section. It’s a paragraph on its own, immediately after the summary box: 

‘Measurement involves assessing project performance and implementing appropriate responses to maintain optimal performance.’

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

I could be pedantic and observe that ‘measurement’ does not include making a response. But in the spirit of defining the Domain, then this statement is great. And there is one more…

Definition 4: The Next Line of Text

The first sentence of the first substantive paragraph offers us a better definition of the ‘measurement’ part of the domain – but omits the control part. However, I like it because it ties this Domain to two others: Planning and Delivery:

‘The Measurement Performance Domain evaluates the degree to which the work done in the Delivery Performance Domain is meeting the metrics identified in the Planning Performance Domain.’

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

Our Expanded Definition of the Measurement Performance Domain

With four such good definitions, it seems, perhaps, invidious to offer a fifth definition of my own. But, maybe my concern is that there are too many definitional statements. I’d like the next edition to streamline them and I offer my own. I believe it combines the best of what is there in the 7^th Edition, and starts with Definition 3:

The Measurement Performance Domain involves assessing project performance and taking appropriate actions to maintain optimal performance and thereby deliver the promised business value.’

Verifying the Outcomes from the Measurement Performance Domain

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

I will interpret these checks in my own words.

A reliable understanding of the status of the project.

The check here is an audit of the measurements and the reports, which is a sound approach.

Actionable data to facilitate decision making.

This is weak. It is to assess project performance, which considers an output measure but one that is, to my mind, too distant from the ‘actionable data’ it is trying to check up on. There are too many influences on project performance to be sure that it is a good basis for assessing the data. 

I would rather see an assessment of decision-makers’ response to the data – do they ask for more? How do they use it? How rich are the discussions?

Timely and appropriate actions to keep project performance on track.

This is about cycle time – from measurements to corrective actions. But the check here is nothing more than a re-wording of the desired outcome, requiring ‘timely decisions and actions’.

The authors need to define timely (and also appropriate). Here, we can look at:

• Turnaround times from collection of data to implementation of corrective action
• the outcomes of interventions for ‘appropriate’

Achieving targets and generating business value by making informed and timely decisions based on reliable forecasts and evaluations

With this one, the authors seem to be on firmer ground. As we’ll see later, implementation of this will lean heavily on the solid grounding of Earned Value Management (EVM). They suggest comparing current performance with past forecasts and original plans.

Important Definitions within the Measurement Performance Domain

In the introduction to the Measurement Performance Domain, PMBOK 7 highlights (in a box), three key definitions of jargon terms. As always, I could ask why these and not some other equally obvious choices like ‘forecast’, but the three chosen are all important. And the definitions are short and effective. 

‘Metric. A description of a project or product attribute and how to measure it.’

‘Baseline. The approved version of a work product used as a basis for comparison to actual results.’

‘Dashboard. A set of charts and graphs showing progress or performance against important measures of the project.’

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

I won’t suggest alternatives to these, as I think they are all good definitions. But I shall add my own definition:

‘Forecast. A prediction of future performance based on calculations from data and assumptions.’

Basic Principles of the Measurement Domain

The commentary at the start of this section is concise and on-point. I tried hard to think of my own additions to the list of reasons for using measures in project delivery, but the PMBOK 7 list seems comprehensive, covering (this is my own version of the list):

• Governance
• Performance to plan
• Resource usage
• Stakeholder information
• Status assessment
• Decision-support
• Quality evaluation

But, best of all is the reminder that the real value of measurement is not in the data itself but in how it informs our discussions and decisions about what we will do.

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

Aside from the usual sections on Interactions with other domains (I’ll discuss that below) and Checking Results (I discussed that above), there are six sections in this Performance Domain:

1. Establishing Effective Measures
2. What to Measure
3. Presenting Information
4. Measurement Pitfalls
5. Troubleshooting Performance
6. Growing and Improving

We will look at each in turn.

Establishing Effective Measures

Effective measures are those that provide the right information to the people who need it, in a timely manner. 

They inform, create accountability, and give the basis for robust decision-making. As a result, effective measures are a vital key to delivering your project to schedule, to budget, and to specification. And, as a result, to creating the value that the organization envisaged when it committed to the project.

PMBOK 7 goes on to discuss two valuable ideas:

1. Key Performance Indicators (KPIs)
   KPI are quantifiable measures that can indicate the status of your project. They can be either leading or lagging indicators:
   1. Leading Indicators give us a measure that predicts future outcomes
   2. Lagging Indicators give us a measure, after the event, of how successful we have been.
2. Effective Metrics, using the SMART criteria
   The PMBOK 7 authors offer a good description of the SART framework. Whilst I believe this tool is over-used, it is a sensible approach to specifying the criteria for effective measures:
   1. Specific
   2. Meaningful (or Measurable)
   3. Achievable (or Agreed)
   4. Relevant (or Realistic, or Reasonable)
   5. Timely (or Time-bound)

I like their explanations of both of these and you can see my short video answering the question ‘What are KPIs? Key Performance Indicators’, below.

I’d perhaps like to have seen a mention of OKRs – Objectives and Key Results – here, too. Although it is easiest to think of this as a Project definition framework, once established, OKRs are a good framework to monitor against. So, I have also put my video, ‘What are OKRs?’, below.

What to Measure

This is a big subsection, with 7 excellent discussions of:

1. Delivery Metrics
   Largely about quality standards.
2. Delivery
   Focused on efficiency measures like Work in Progress, lead and cycle times, queue and batch sizes, and overall efficiency
3. Baseline Performance
   The first of two discussions focused on the use of Earned Value Management (EVM). The two subsections together form a very high-level primer on EVM. For a more thorough introduction, see our full article: Earned Value Primer: The Basics of EVM. And I will put our video, ‘What is Earned Value Management?’, below.
4. Resources
   A brief introduction to comparing actual to planned resource utilization and cost
5. Business Value
   This introduces four different measures of value, crudely:
   1. Cost-benefit ratio: V₁ = B/C
   1. Cost-benefit comparison: V₂ = B-C
   1. Return on Investment (ROI): V₃ = ROI = (B-C)/C
   1. Net Present Value (NPV): the most sophisticated approach that uses the Discounted Cash Flow (DCF) method. I have put a short video answering the question ‘What is a Discounted Cash Flow?’, below.
6. Stakeholders
   A look at some tools that will establish stakeholder perceptions of your project and its performance:
   1. Net Promoter Score (NPS): willingness to commend the project on a scale of -100 to +100
   1. Mood Chart: personal statements using simple emojis
   1. Morale: measured by survey
   1. Turnover: people leaving is an indicator of dissatisfaction
7. Forecasts
   This is the other section that makes use of Earned Value Management Tools – in this case to forecast future performance.

This is a nicely illustrated section that reminds us of the value of:

1. Dashboards
2. Information Radiators 
   Or, ‘Big Visible Charts’ (BVCs), that contain lots of core information in an easy-to-read layout, and are placed in a prominent position where the team will frequently see it.
3. Visual Controls
   Other forms of monitoring information in graphical formats, such as:
   1. Burndown or Burnup charts
   1. Kanban or Task boards We have a video that answers the question ‘What is Kanban?’

Measurement Pitfalls

I particularly like that the team has created this very important section. And it is done well, with a lot of different ideas listed in the space of one page. They cover:

• The Hawthorn Effect
  People respond to attention, often masking or being the only response to the effects of a specific corrective action
• Vanity metrics 
  Which measure what you want to feel good about, rather than what is useful for good decision making
• Demoralization 
  The impact of measuring against goals and targets you do not believe are achievable
• Misuse of metrics
  There are several good examples, but this is an obvious trap
• Confirmation bias
  Seeing what we expect to see and not noticing as easily what we do not. A related bias that the authors neglect (there are many that are relevant) is our tendency to interpret events according to our expectations, rather than looking for an objective reason.
• Correlation versus Causation
  If two things happen at the same time or one after another, they are correlated. This does not, on its own, mean that one causes the other. Yet, we have a predisposition to infer causation

To this excellent list, I would add the use of proxies. 

You often cannot measure what you know you would ideally measure. There are many reasons, but the solution is to find a proxy – something you can measure, which is a suitable indicator of what you’d like to measure. However, there are pitfalls in choosing a proxy and assuming:

• The link is stronger than it is
• Or that it works in the way you expect
• Correlation is causation (see above)
• Other factors are not involved

Troubleshooting Performance

This section simply illustrates the use of upper and lower variance bounds to indicate acceptable or unacceptable deviations from the plan. It is a worthy section to include, but it feels a little thin against those that came before.

Growing and Improving

On the surface, this very terse section underperforms. It makes the important point that we can use measurement data as the basis for improving our processes and efficiency. It does it well, but I would like to see a link to the ideas of retrospectives and lessons learned reviews.

Critical Evaluation of the Measurement 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

I came very close to awarding the Measurement Performance Domain my top score of 5 (Excellent). But there are a few tweaks I’d like to see in the next edition (if it retains the Project Performance Domains). So, I can’t really rate it 5. 

But, awarding it a 4 (Good) seems too mean-spirited. It is better than the Delivery Domains that I did score 4. And my quibbles with it are very minor indeed. So, I am going for a new rating of 4.5 (Very Good).

Strengths of The PMBOK 7 Measurement Domain

This is a well-thought-out and well-written domain, with a lot of clear illustrations to support the text. Many of the sections have exceptionally good content and some extend the thinking way beyond what the earlier editions of the PMBOK Guide offered. This section holds very true to the ‘Principles’ approach of PMBOK 7, whilst still offering a wealth of practical ideas and advice. The What to Measure section certainly stands out to me.

This whole domain will add huge value to a Project Manager’s learning and understanding. And the deep insights from seasoned practitioners show more here than in any other domain. There is a lot of thought-provoking content for even experienced Project Managers to savor.

Weaknesses of The PMBOK 7 Measurement Domain

There is not much to say about weaknesses. So, in the spirit of ‘when performance is good, you don’t need to look for weaknesses to moan about’, I shall say nothing more.

What Else We Should Include in the Measurement Performance Domain?

My suggestions for additional content are few and none of them are fundamental. I don’t think the authors missed anything important. 

Along the way of this article, I have mentioned a number of bullet point concepts I would add to specific sections:

• Forecasts
• OKRs
• Proxies
• Lessons Learned and Retrospectives

The only substantial thing I would add (and I concede it may fit better in Domain 3: Development Approach and Life Cycle – but it is absent from that too) is the topic of Stage Gates, Gateways, Phase Gates, or Boundary Gates.

I think this topic would work well in the Measurement Domain. For more on the topic:

• What are Stage Gates or Gateways? | Video
• How the Stage Gate Process Will Make You a Better Project Manager
• How to Run an Effective Stage Gate Review | Video

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

As I’d expect, the PMBOK 7 section on Interactions with other Performance Domains focuses on the:

• Planning Performance Domain
• Delivery Performance Domain

It also highlights the Project work Performance Domain. I won’t disagree that there is a strong link to that domain, as PMBOK 7 describes it. I will simply note that when I reviewed that domain, I found it to be (I paraphrase for simplicity) a mess.

The authors also note (and again, I agree) that there is a clear link to the:

• Team Performance Domain
• Stakeholder Performance Domain

[Website]

What are your Thoughts about the Measurement Performance Domain?

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

More to think about…

• The Project Control Paradox | Video
• Project Cost Management and Self Preservation | Video

Project Management Domains eBook Series

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